如此部署！? 征集点信心 or 判个死刑

让这个帖子为了征集点信心 or 判个死刑~~~
项目接近尾声，最近在准备做项目的部署。

以下说明一下我们老板(解释见“附1”)给我讲解决的部署方式。
如图。~~~~一时在自己电脑上没找到好的工具~~就是PPT画一下啦~~
A地主机　做为我们的主力服务器。就放置在公司的机房，目地在于维护方便，开门就能拆机器，不用跑到客户那边去。
A地备份机　做为A地的一个备用服务器，防止A地主机死翘翘而准备的备份服务器。
B地主机 与A地相隔着90分钟的飞行路程，放置在B地客户公司的服务器。原因是因为A地自然灾害了B地主机还能动，B地自然灾害了A地还能动。
台湾主机 放置在台湾的一台服务器。由于有“金盾”的存在，为了让台湾用户能顺利访问系统而架设的主机。

三台主机分别使用各自安装在机器上的MySql数据库。
其中 A地主机与B地主机使用MySql的热备进行数据同步。而台湾主机则使用老板提供的一种同步方式与A地主机进行“热备”（传说中的传sql角本？没见过，只耳闻过）。
由于固定IP的价格之贵，A地与B地使用花生壳 or 3322之类的东西做为数据同步时的标识。台湾固定IP便宜，所以有固定IP。客户的访问也得通过花生壳之类。

配置情况。
几台主机的配置也就是我们平常的家用机配置，A地主机比较好一点是64位的，7K左右，其它的大概都在5K以下。
网络呢A、B地是小区宽带2M~~台湾也差不多，具体我不清楚。

客户访问时就让客户自己去选，是用A地主机的服务呢还是用B地主机的服务，台湾的就让他们访问台湾的服务。

============================我的分割线=======================
以上都是阐述而以。
这样的部署我很@#$%，不好怎么描述。也好也不好。
我说想架设一台正式点的服务器，不用弄这么“花哨”，但都被红色标出的理由拒绝了。

很是担心两点.

MySql的热备能达到期望的效果吗？可是通过2M的小区宽带+花生壳来同步的呀！

台湾与大陆的数据同步。角本文件？绕开“金盾”？

je这么多大牛，看法如何，这样的部署能成功吗？

附1：
我们项目没有项目经理，没有级别，没有上下级关系，老板一人掌握所有事情的判断权利。老板为人心思细腻，事事要求完美。

评论

84 楼 phoenixup 2009-02-09  

bonny 写道

晕，我现在十分佩服你老板。要么脑子浑浑噩噩，要么有恶搞的才华。

你们的架构考虑都已经到了“担心自然灾害”而ab两地备份的情况了，居然还ip之贵，花生壳。

说真的，我忍住没说。。。。矫枉过正是这套结构的问题，BOSS到底搞清楚没他需要什么不需要什么。。好钢要用到刃上。。。

83 楼 eyeqq 2009-02-05  

最终这一切还是不了了之的收场了。
至少目前是。
按照最开始的方法去做，起码是可以保证系统运行正常，也能达到一些效果。
可后面BOSS又要搞双Wan路由接入，等等一些，搞到现在动弹不得。

82 楼 makefile 2009-01-23  

主机故障是怎么发现的心跳吗?

灾备要根据自己需求来了,恢复时间和数据丢失量是两个重要指标
可能的话做远程数据库冷备,也是灾备策略,这方案好歹还是比较实时的.

81 楼 抛出异常的爱 2009-01-23  

沙箱同步.
A所录入的C数据库时同时存入A沙箱
B所录入的D数据库时同时存入B沙箱

A定时去B上查寻B沙箱
B中数据录入C数据库
当有已录入的就跳过
------------------------------
A再查寻B上的D数据库
把A沙箱的数据与D数据库上的数据进行比较
同步完成的的就清除掉.
---------------------------
每步都作日志.


这个系统开发失败了

80 楼 ztka 2009-01-23  

xidaboy 写道

cocal 写道

xidaboy 写道

这位兄弟的回复,充分说明,根本就不知道MYSQL的主从方案是怎么实现的,你哪来的两天数据同步时间,这边库改了就立即自动要复制到另一库去,所以我一直就感慨,很多人其实根本就没做过,光用嘴说,光用脑子在想,要做!要做!

我说的两天，业务需求，不行吗？

MYSQL的确不了解，但同步就那么点道道，还能弄出花来啊？麻烦这位做过兄弟普及一下，什么叫“这边库改了就立即自动要复制到另一库去”，不能容忍网络中断？不能容忍网络拥塞？网络断了再恢复是什么结果？数据库CRASH？热备损坏？需要手工干预？

我发贴的目的是奇怪这么多人想都没想就去泼冷水，LS说我做都没做就去想...呵呵。咱们还是看LZ的吧..

哎~`早说了.你就没用过.你就是光想

如果网络断了,A库更新了,B库数据没进去.网络再恢复以后,B库的数据是不会自动和A同步的,这样是不是数据就不同步了,无限的人工修改,人工检查,这系统能用???

这个不难的

有Master Log File 和 Read_Maste_LogPos 可以保证数据同步。

79 楼 pipilu 2009-01-20  

cocal 写道

icewubin 写道

这其实是就是把复杂度转嫁到开发中去了，原本不需要考虑这些问题的，但是因为愚蠢的BOSS搞出来的方案，导致系统的业务从设计到编码到测试都得考虑数据同步的可行性，你可以说业务天生就是如此，但是这“天生就是如此”这个结果就是要通过耗费人工评估得出的结果，这些无谓的成本大多是隐含的。

再有，很多人的想法是，同等成本（人力、物力）下，肯定有更好的整体方案，这是前提。
而楼主的大前提是BOSS下了命令，必须要那么整。
所以你的“未尝不可”基于哪个前提呢？

恕我直言，开发者觉得其他人（比如用户、销售、甚至搭档，当然也包括老板）愚蠢是很大的毛病！

其实从业务设计到编码测试本来就要考虑数据同步的可行性，只是技术人员有了一些现成的工具可用而已，系统设计就那几板斧，OO的结果就是大量的框架、模式、结构可以套用，过惯了衣来伸手、饭来张口的懒日子，就觉得永远不用考虑煮饭了。成本不是技术人员应该考虑的东西，这么说的技术人员只是怕麻烦而已。不得不提醒的是，怕麻烦，就没有机会吃更好的，就这么简单，成功不是随便来的。

我说“未尝不可”的前提是，这是一个新思路，LZ如果能证明这个方案可以成功，就做到了别人做不到的事情。你能做到别人做不到，或者你能先于别人做到，换句话说，就是竞争力！竞争力不用解释吧？吃的好些不难理解吧？何蠢之有？

觉得这个BOSS蠢的人，是否问过当年YAHOO和GOOLE创始人是否也蠢？当年Gates，Jobs哪个不蠢？

   

引用

其实从业务设计到编码测试本来就要考虑数据同步的可行性

    不是吧，我所接触过的项目，从设计到编码，考虑的充其量就是数据的单向同步、集中式的。像这种分布的、双向同步的。你们要是从开始就这样考虑了，那除非是系统有特殊的需求。否则，那真是太过了。如果做实习作品，我倒会考虑一下。

    楼主在标题中说了“or 判个死刑”，说明大家也是可以投反对票的。是吧？

   

引用

恕我直言，开发者觉得其他人（比如用户、销售、甚至搭档，当然也包括老板）愚蠢是很大的毛病！

    不是什么毛病，我猜测只有两种人从来没提过其他人“愚蠢”，一种是很油的（滴水不漏），另一种是很“老”的（爱咋的咋的）。
   
    不是懒不懒的事，实施本身相对来说要保守一些，而且楼主也传达了这样一个信息——他们需要保守一些。

    成本一定就低了么？除非你不把人力、时间以及维护成本算进去。我在前面的留言已经说了，业务楼主最清楚，这种双向同步倒底有多麻烦，怎么样的测试才算完备，这得知道业务的人才知道。当然，后来楼主说了，他们两块儿客户的业务的数据相交很小。

    很喜欢楼主的分享精神。
    最后楼主可能测通了，而且系统也好好的跑着。但我认为这只能说明这样做没问题，并不能证明可靠性就一定比单机的高了。成本就一定低了。

78 楼 cocal 2009-01-20  

icewubin 写道

1.愚蠢不愚蠢，这个就不深入了，大家都知道，yahoo和google是不是大家都认为愚蠢自有公论。退一步说，即使boss剥削员工，如果方案和设计的好，员工还是会说好的，即使应该3个人做的事情，压倒一个人身上，也不能否认方案本或设计本身就是好的。

2.我说的愚蠢还包含一层意思就是，楼主的BOSS表面上认为这样做能节省硬件成本，但是间接的是浪费公司的人工。当然BOSS可能知道这点，硬件成本相对是固定的，人工么，可以压榨剥削的啊。

3.愚蠢主要还包括方法论上的问题，低带宽下的实验调研还没有做，就开始实施方案，有这么实施项目的么？

怎么聊到人际关系上去了，再说下去有些跑题了，哈哈。
最后再说几句，如果觉得和老板合不来，找机会换个老板试试，如果换来换取都遇不到好老板，那你绝对是个做老板的材料，创业吧...
（其实哪个老板不是从工仔做起来的？也许等到你当了老板，才会发现原来事情不是那样，但不做老板，又如何能知老板之苦呢？）

给LZ和各位讨论的朋友拜个年吧，祝大家工作开心，新春大吉，牛年牛气冲天。

77 楼 icewubin 2009-01-19  

楼主有条件的话，用蓝牙就能测试了，两台机器用蓝牙对联。

蓝牙理论1Mbps带宽，加上一些无线传输的损耗，差不多就可以模拟512Kbps的真实情况了。

76 楼 icewubin 2009-01-19  

cocal 写道

恕我直言，开发者觉得其他人（比如用户、销售、甚至搭档，当然也包括老板）愚蠢是很大的毛病！

其实从业务设计到编码测试本来就要考虑数据同步的可行性，只是技术人员有了一些现成的工具可用而已，系统设计就那几板斧，OO的结果就是大量的框架、模式、结构可以套用，过惯了衣来伸手、饭来张口的懒日子，就觉得永远不用考虑煮饭了。成本不是技术人员应该考虑的东西，这么说的技术人员只是怕麻烦而已。不得不提醒的是，怕麻烦，就没有机会吃更好的，就这么简单，成功不是随便来的。

我说“未尝不可”的前提是，这是一个新思路，LZ如果能证明这个方案可以成功，就做到了别人做不到的事情。你能做到别人做不到，或者你能先于别人做到，换句话说，就是竞争力！竞争力不用解释吧？吃的好些不难理解吧？何蠢之有？

觉得这个BOSS蠢的人，是否问过当年YAHOO和GOOLE创始人是否也蠢？当年Gates，Jobs哪个不蠢？

1.愚蠢不愚蠢，这个就不深入了，大家都知道，yahoo和google是不是大家都认为愚蠢自有公论。退一步说，即使boss剥削员工，如果方案和设计的好，员工还是会说好的，即使应该3个人做的事情，压倒一个人身上，也不能否认方案本或设计本身就是好的。

2.我说的愚蠢还包含一层意思就是，楼主的BOSS表面上认为这样做能节省硬件成本，但是间接的是浪费公司的人工。当然BOSS可能知道这点，硬件成本相对是固定的，人工么，可以压榨剥削的啊。

3.愚蠢主要还包括方法论上的问题，低带宽下的实验调研还没有做，就开始实施方案，有这么实施项目的么？

75 楼 cocal 2009-01-19  

icewubin 写道

逻辑场景疑问一：

如果用户访问B地主机，并新增业务，熟料刚新增完，B地地震（或其他灾害），但是用户新增的业务刚入库，还没有同步到A地主机。

用户无奈转而访问A地主机，发现先前新增的数据看不到，于是又新增了相同的业务，按楼主的策略，B地主机恢复后，两地一同步，是否会出现两条一模一样的业务数据呢？

在发生灾难的时候，应该在双向热备中做选择一个（例如A）做主，抛弃其中一方（B），通告用户复核特定时间段（如12小时内）的所有业务并补录。恢复时直接通过A->B方式重建B，之后启动双向。

74 楼 cocal 2009-01-19  

eyeqq 写道

但问题就是，我们是小区宽带，两条宽带都是从一个小区的大路由？/集线器？接进来了，那样这样的话跟我之前测试的走我们自己路由的感觉没什么差别。并我们这这一片区的电信服务器就在距离我们机房300多米的地方（宽带小伙跟我们讲的）...-_-!相对来讲，这样的测试还是不能够说明真实的生产环境的效果的。等两天机器在客户那边架起来了再来看最终的结果吧~~~

不了解你的宽带设备是什么，两台MODEM？还是直接是RJ45头直用根网线就能跑？
有没有测过两台机之间真实可用带宽是多少？PING值是多少？
如果能够验证带宽确实只有2M的话，那么现阶段至少可以获得结论：这个方案在指标充足、性能稳定的小区宽带线路上可用，具体性能要拿到A、B地链路性能实测数据之后才可以验证。
网络性能有两个指标，一个是带宽，一个是响应（各种尺寸数据包的ping值），前一个决定最大数据流量，下一个决定响应速度。

这个方案还是有风险，做为技术人员必须把握的是要充分预计风险，如实向BOSS表达进展情况以及风险，不要夸口，这样才不会把自己弄的很难受。

73 楼 cocal 2009-01-19  

icewubin 写道

这其实是就是把复杂度转嫁到开发中去了，原本不需要考虑这些问题的，但是因为愚蠢的BOSS搞出来的方案，导致系统的业务从设计到编码到测试都得考虑数据同步的可行性，你可以说业务天生就是如此，但是这“天生就是如此”这个结果就是要通过耗费人工评估得出的结果，这些无谓的成本大多是隐含的。

再有，很多人的想法是，同等成本（人力、物力）下，肯定有更好的整体方案，这是前提。
而楼主的大前提是BOSS下了命令，必须要那么整。
所以你的“未尝不可”基于哪个前提呢？

恕我直言，开发者觉得其他人（比如用户、销售、甚至搭档，当然也包括老板）愚蠢是很大的毛病！

其实从业务设计到编码测试本来就要考虑数据同步的可行性，只是技术人员有了一些现成的工具可用而已，系统设计就那几板斧，OO的结果就是大量的框架、模式、结构可以套用，过惯了衣来伸手、饭来张口的懒日子，就觉得永远不用考虑煮饭了。成本不是技术人员应该考虑的东西，这么说的技术人员只是怕麻烦而已。不得不提醒的是，怕麻烦，就没有机会吃更好的，就这么简单，成功不是随便来的。

我说“未尝不可”的前提是，这是一个新思路，LZ如果能证明这个方案可以成功，就做到了别人做不到的事情。你能做到别人做不到，或者你能先于别人做到，换句话说，就是竞争力！竞争力不用解释吧？吃的好些不难理解吧？何蠢之有？

觉得这个BOSS蠢的人，是否问过当年YAHOO和GOOLE创始人是否也蠢？当年Gates，Jobs哪个不蠢？

72 楼 icewubin 2009-01-19  

逻辑场景疑问一：

如果用户访问B地主机，并新增业务，熟料刚新增完，B地地震（或其他灾害），但是用户新增的业务刚入库，还没有同步到A地主机。

用户无奈转而访问A地主机，发现先前新增的数据看不到，于是又新增了相同的业务，按楼主的策略，B地主机恢复后，两地一同步，是否会出现两条一模一样的业务数据呢？

71 楼 eyeqq 2009-01-18  

装东西是要有许可的。这个很麻烦。
不过晚上同事在家跑了一下。500并且去操作我们的日常业务。服务器都不卡~~~~
之前在内网有试过是会很卡。
怀疑loadrunner版本有问题，角本没录对。

额额……有空再去处理这些好了。烦哪。
神经病一样，哎。快受不了了。

70 楼 pipilu 2009-01-18  

是要在服务器上安装LoadRunner测试么？(为什么会涉及64位系统安装LoadRunner的问题)
只要在你自己的电脑上安装上loadrunner，跟服务器直连（这样网络延迟方面的影响就很小了），这样测就可以了。

69 楼 eyeqq 2009-01-16  

icewubin 写道

这其实是就是把复杂度转嫁到开发中去了，原本不需要考虑这些问题的，但是因为愚蠢的BOSS搞出来的方案，导致系统的业务从设计到编码到测试都得考虑数据同步的可行性，你可以说业务天生就是如此，但是这“天生就是如此”这个结果就是要通过耗费人工评估得出的结果，这些无谓的成本大多是隐含的。

再有，很多人的想法是，同等成本（人力、物力）下，肯定有更好的整体方案，这是前提。
而楼主的大前提是BOSS下了命令，必须要那么整。
所以你的“未尝不可”基于哪个前提呢？

这个东西确实是上头强加下来的。设备什么的都已经弄好了，客户也忽悠过去了，所以只能这样子弄。
但如果从好的方面去想这也确实是“未尝不可”。毕竟到后面也是我一手搞出来的么....-_-!
在开发中我们没有对这样的部署情况做任何的代码改动。原因是这样的，我们把使用客户分为了两块，一块是在B服务器工作的“业务中心”客户，也就是我们的客户公司的一些工作人员与他们下面的分支机构。另一块是在A服务器上工作的“直接客户”也就是我们客户的客户，他们使用的是我们客户给他们提供的一些服务（也就是寄件人）。所以A服务器主要的操作也就是一些查询以及“在线下单”，B服务器就不同了，业务就比较丰富了。相对的，B服务器上面的人数会比A服务器少很多，但是功能多很多，数据的CRUD也多很多，这些CRUD也只是内部的一些数据，与A服务器上使用都需要读取的数所相交很少。A服务器的使用人数又比B服务器多很多，但它的功能少，对数据的操作也很少。这样子的分配也算是达到了一个负载分散的需求。再者，哪台服务器挂了另一台也是可以接着动~~~~灾也容了....基本上也达到了之前提出的要求。

接着讲测试的情况。
两台主机的配置就是之前讲的那样。对他们进行了热备的一些配置，配置中异常是忽略的。DDNS的话就是使用的甲克虫。
项目也部署上去了，但是测试的时候没有开什么自动化测试的工具(64位系统装loadrunner和QTP这些还蛮有问题的，目前还没解决。有解决了的朋友可以通告一下...谢谢)测试了我们几个模块的功能，都是挑的数据操作很大的很种，同步的数据非常快，当然了，只是我肉眼看到的，操作完了之后另一台机器马上就有了数据。mysql有没有监测状态的那种工具呢？有的话推荐一个。
机器开在那边，这边弄弄操作那边也弄弄操作（很累-_-!），搞了差不多半个多小时，数据还是完整的。开了一个晚上，早上过来，又搞搞系统，运行还是稳定的。如果真的能有这样的效果那这个子部署也还算蛮不错的。
但问题就是，我们是小区宽带，两条宽带都是从一个小区的大路由？/集线器？接进来了，那样这样的话跟我之前测试的走我们自己路由的感觉没什么差别。并我们这这一片区的电信服务器就在距离我们机房300多米的地方（宽带小伙跟我们讲的）...-_-!相对来讲，这样的测试还是不能够说明真实的生产环境的效果的。等两天机器在客户那边架起来了再来看最终的结果吧~~~

68 楼 icewubin 2009-01-16  

cocal 写道

支持楼主，可见xidaboy老兄虽然做过，也未必足够功夫，呵呵。

首先，相信LZ遇到的问题应该是可以解决的，源码级的修改应该不会太大，在中断恢复过程的适当位置执行多一次DNS lookup就是了（也许是操作系统有DNS Cache的问题，倒不一定就赖Mysql），当然，我又是在瞎想，先声明了，避免被拍，哈。

再回xidaboy:

“如果网络断了,A库更新了,B库数据没进去.网络再恢复以后....”，这么简单的状况，如果都不能同步，只能说系统设计太没考虑了。真正复杂的是：“如果网络断了，A库更新了一行，B库更新了同一行”，这才真正在恢复的时候发生的棘手问题，在复杂逻辑下，更隐蔽的麻烦是：“如果网络断了，A库x表更新了一行，B库参照表x那一行数据更新了表y，A库参照y表那一行更新了z表”，恢复时带来深层次逻辑错误。如果系统有这么复杂，没办法中断，恐怕电信级的热备都不够用也不奇怪！

我为什么说并非不可行，是说大家不要理论化的去看问题，要结合实际需求，经过适当的处理，大多数情况下不会有理论上那么复杂。

既然知道LZ是做快递，咱们不妨再假设一下，快递单跟踪这种需求。我们有一张<在途快递单>表，由于快递空表是事先印刷好编码（条形码），自然不会有两地产生同一张编号快递单的可能吧？那么<在途快递单>不管怎么分布，用快递单号做主键，都不会存在两地更改同一行数据的机会，是不是？还有一张表叫<路线追踪>货物每到一个站，都会增加一条记录，我们用<时间+快递单号>做主键，也不会有记录被冲掉，或者同步冲突的可能吧？最多就是某个站的数据迟点上来而已吧？需要考虑的是延迟多少是可以接受的。（当然，还有一个问题，肯定有人会问，中转站输入信息的时候，有可能<在途快递单>还没有更新，如果有关系约束，就卡住了，呵呵，不约束接不接受？问用户，不是问程序员。不约束，会有条码扫描仪准确率的风险，那是十的多少次方之一吧）

对于另外一些自动生成编码的表，也不一定有问题，假如快递单号需要系统自动生成，那么系统设计时约定，A地产生的单据，编号第一个字符是'A'，B地产生的单据，编号第一个字符是'B'，不是又把冲突给避了吗？哈哈.

难办的需求是两地需要更新同一张表的同一行，比如库存，比如账户资金那种情况，典型的事务冲突问题，就不是LZ这种方案能够照顾的了。例如火车票售票，或者机票售票系统，如果要分布就要十分小心了，现在大多数航空公司的售票还都是通过虚拟终端拨号连到主机上去做，类似应用LZ这个方案就绝对不行了，对吧？（其实也不绝对，约定A地出发的班机只能在A地卖，B地出发的班机只能在B卖，跨地区买票，要求A、B服务器必须连起来了，否则只能卖自己的，哈哈）。

这其实是就是把复杂度转嫁到开发中去了，原本不需要考虑这些问题的，但是因为愚蠢的BOSS搞出来的方案，导致系统的业务从设计到编码到测试都得考虑数据同步的可行性，你可以说业务天生就是如此，但是这“天生就是如此”这个结果就是要通过耗费人工评估得出的结果，这些无谓的成本大多是隐含的。

再有，很多人的想法是，同等成本（人力、物力）下，肯定有更好的整体方案，这是前提。
而楼主的大前提是BOSS下了命令，必须要那么整。
所以你的“未尝不可”基于哪个前提呢？

67 楼 cocal 2009-01-16  

支持楼主，可见xidaboy老兄虽然做过，也未必足够功夫，呵呵。

首先，相信LZ遇到的问题应该是可以解决的，源码级的修改应该不会太大，在中断恢复过程的适当位置执行多一次DNS lookup就是了（也许是操作系统有DNS Cache的问题，倒不一定就赖Mysql），当然，我又是在瞎想，先声明了，避免被拍，哈。

再回xidaboy:

“如果网络断了,A库更新了,B库数据没进去.网络再恢复以后....”，这么简单的状况，如果都不能同步，只能说系统设计太没考虑了。真正复杂的是：“如果网络断了，A库更新了一行，B库更新了同一行”，这才真正在恢复的时候发生的棘手问题，在复杂逻辑下，更隐蔽的麻烦是：“如果网络断了，A库x表更新了一行，B库参照表x那一行数据更新了表y，A库参照y表那一行更新了z表”，恢复时带来深层次逻辑错误。如果系统有这么复杂，没办法中断，恐怕电信级的热备都不够用也不奇怪！

我为什么说并非不可行，是说大家不要理论化的去看问题，要结合实际需求，经过适当的处理，大多数情况下不会有理论上那么复杂。

既然知道LZ是做快递，咱们不妨再假设一下，快递单跟踪这种需求。我们有一张<在途快递单>表，由于快递空表是事先印刷好编码（条形码），自然不会有两地产生同一张编号快递单的可能吧？那么<在途快递单>不管怎么分布，用快递单号做主键，都不会存在两地更改同一行数据的机会，是不是？还有一张表叫<路线追踪>货物每到一个站，都会增加一条记录，我们用<时间+快递单号>做主键，也不会有记录被冲掉，或者同步冲突的可能吧？最多就是某个站的数据迟点上来而已吧？需要考虑的是延迟多少是可以接受的。（当然，还有一个问题，肯定有人会问，中转站输入信息的时候，有可能<在途快递单>还没有更新，如果有关系约束，就卡住了，呵呵，不约束接不接受？问用户，不是问程序员。不约束，会有条码扫描仪准确率的风险，那是十的多少次方之一吧）

对于另外一些自动生成编码的表，也不一定有问题，假如快递单号需要系统自动生成，那么系统设计时约定，A地产生的单据，编号第一个字符是'A'，B地产生的单据，编号第一个字符是'B'，不是又把冲突给避了吗？哈哈.

难办的需求是两地需要更新同一张表的同一行，比如库存，比如账户资金那种情况，典型的事务冲突问题，就不是LZ这种方案能够照顾的了。例如火车票售票，或者机票售票系统，如果要分布就要十分小心了，现在大多数航空公司的售票还都是通过虚拟终端拨号连到主机上去做，类似应用LZ这个方案就绝对不行了，对吧？（其实也不绝对，约定A地出发的班机只能在A地卖，B地出发的班机只能在B卖，跨地区买票，要求A、B服务器必须连起来了，否则只能卖自己的，哈哈）。

66 楼 eyeqq 2009-01-15  

xidaboy 写道

cocal 写道

xidaboy 写道

这位兄弟的回复,充分说明,根本就不知道MYSQL的主从方案是怎么实现的,你哪来的两天数据同步时间,这边库改了就立即自动要复制到另一库去,所以我一直就感慨,很多人其实根本就没做过,光用嘴说,光用脑子在想,要做!要做!

我说的两天，业务需求，不行吗？

MYSQL的确不了解，但同步就那么点道道，还能弄出花来啊？麻烦这位做过兄弟普及一下，什么叫“这边库改了就立即自动要复制到另一库去”，不能容忍网络中断？不能容忍网络拥塞？网络断了再恢复是什么结果？数据库CRASH？热备损坏？需要手工干预？

我发贴的目的是奇怪这么多人想都没想就去泼冷水，LS说我做都没做就去想...呵呵。咱们还是看LZ的吧..

哎~`早说了.你就没用过.你就是光想

如果网络断了,A库更新了,B库数据没进去.网络再恢复以后,B库的数据是不会自动和A同步的,这样是不是数据就不同步了,无限的人工修改,人工检查,这系统能用???

额……
好像我比较能拿出点证据来说话~~~~
先感谢一下cocal同学能对这个方案提出比较理智分析，并没有一开始就否定。
其它的朋友也非常感谢，提出了很多疑问。
这个方案也是我们老板瞎搞出来的，我们这群做手下的只好尽最大的弄力去实现他老人家的心愿了。尽量使这东本能跑起来像那么回事。一顿乱搞之下，这两天有了一些成果。可以公布一下。但并不是最终的运行效果，这个还要等几天。

首先回答一下这个问题“如果网络断了,A库更新了,B库数据没进去.网络再恢复以后,B库的数据是不会自动和A同步的,这样是不是数据就不同步了”
这样的情况mysql是会根据偏移量去做数据的同步，只要从服务器得知道主服务器上面的自己没有同步的数据，它就会去把数据抓下来进行同步。我测试过2天2夜的断网情况。当网络连通之后数据同样可以同步。这个测试的数据量大约在5K条(没花太多时间去造数据)。
这样的情况即使是IP突然改变，mysql也可以把数据同步过去，但这里存在一个时间问题，通过域名重新定位服务器的IP要通过一段时间（mysql内部问题）。虽然已经知道新IP，但是同步还是会停止，需要等上一段时间，20分钟左右。这个问题发给了mysql的技术支持~~~等他们的答复。

OK。讲一下大概的。
这次的测试我用了两条不同的宽带线路，都是家用型的~~~上传下载1.5M左右。也就是10M的小区宽带。
配置CPU Q6600 系统xp 64bit Mysql5.1 64bit tocmat 6 64bit  JDK1.5 64bit
DDNS用过：花生壳、3322、甲壳虫

DDNS搞来搞去的，从3322的5分钟刷新一次，到花生壳的30秒刷新一次，到甲壳虫的5秒刷新一次，最终还是选择了最后一个。
花生壳30秒本来也是可以接受的，但是免费的不稳定，给钱的又太贵，而且还没甲壳虫好用。
并且在切换IP的时候，如果花生壳的30秒刷新一次IP，那么客户端如果就在原来的IE上操作系统，IE就会卡在那边，重新输URL也不行，IE就是死活不让进，重新开一个IE就OK了~~~汗....同志们经验哪...换成甲壳虫的5秒刷新一次就不会有这个问题。(我不是托.....-_-!)
太晚了，明天有空补上…………
to be continue……

65 楼 xidaboy 2009-01-15  

cocal 写道

xidaboy 写道

这位兄弟的回复,充分说明,根本就不知道MYSQL的主从方案是怎么实现的,你哪来的两天数据同步时间,这边库改了就立即自动要复制到另一库去,所以我一直就感慨,很多人其实根本就没做过,光用嘴说,光用脑子在想,要做!要做!

我说的两天，业务需求，不行吗？

MYSQL的确不了解，但同步就那么点道道，还能弄出花来啊？麻烦这位做过兄弟普及一下，什么叫“这边库改了就立即自动要复制到另一库去”，不能容忍网络中断？不能容忍网络拥塞？网络断了再恢复是什么结果？数据库CRASH？热备损坏？需要手工干预？

我发贴的目的是奇怪这么多人想都没想就去泼冷水，LS说我做都没做就去想...呵呵。咱们还是看LZ的吧..

哎~`早说了.你就没用过.你就是光想

如果网络断了,A库更新了,B库数据没进去.网络再恢复以后,B库的数据是不会自动和A同步的,这样是不是数据就不同步了,无限的人工修改,人工检查,这系统能用???