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

就是因为没见过所以才发上方案来给大家share。
最开始我对这个方案的信心是0，不过通过最近的一些实践，增加了一点点信心，起码是正数了，正几位就不讲了。
Mysql的热备是通过它的bin-log来实现的，在网上找了许久，也没有找到一些有关他的实现原理方面的文章。bin-log记录下主数据库的数据修改日志，然后由从库去比较自己的更新记录，从而实现了数据的同步。
这个过程中会发生我上一楼所说的那个问题，但数据的完整性我想是可以保证的，因为从库是通过insert语句来实现数据更新的（通过查看错误日志发现的）。
如果是基于这样的方式，网络时好时坏，对数据的破坏性也不会是很大，毕竟插入语句是整句执行的。问题只是一个同步时效性，只要在程序上面做一些时效性的隔离，效果也会还算可以。
像那位朋友说的不敢配置忽略错误，如果按照我这样的分析~~配置也是没有问题的。哈哈。有点风险罢了。

但有一个还是很担心的。bin-log的日志文件mysql默认是10M，其它的服务器是每次一点一点从这10M大的文件中拿数据呢（有个偏移量的说法，但找不到更明确的资料）？还是每次都要去下载10M大的文件？额额。。不懂原理实在太辛苦了。忘JE有DB大牛帮忙解释一下。

另外有一个朋友提到了一个赃读赃写的问题。
这个问题是很严重。但对于我们来讲这个问题不是很严重。我们业务之前的协作性不是很强。流程性的东西比较多，一般是一个流程走过去，其它外届的干扰比较少。
这个问题肯定尽量避免的好，所以会建议让一个业务组里面的用户在同一台服务器上面去做业。

设备这周过完就能架好，到时候希望能有一些有价值的东西到手。

最近想装宽带呢, 留意了一下小区宽带的广告, 与adsl不同, 上行和下行的速度是相同的, 如果是2M带宽并且不会有忙时带宽下降的情况, 感觉还是可以的.

lz，虽然我自己也没有实践过这个方案。但是，看了您对方案的描述，我捏一把冷汗。现在的5M到10M带宽服务器，在有些 IDC 机房，才600元/月不到。为什么还要选择小区或者adsl之类的网络？因为您的方案中，没有把网络通信质量给考虑进去。是个风险。

注：
    我自己表达我自己的理解。请各位勿怪。

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

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

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

非固定IP不可.

建议使用压缩备份,不然sql文本金盾也有枪毙的风险.

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

如果网络断了,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……

支持楼主，可见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下了命令，必须要那么整。
所以你的“未尝不可”基于哪个前提呢？

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

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