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

目前我们计划出来等等成本。非常非常小，小到只有设备是最大开销。

本来昨天是要做测试的，但是因为线路与设备的问题，模拟测试没能够进行。今天情况也是一样...-_-!
不过通过花生壳也测了一下同步的情况。但不知道这样的情况是不是走了宽带，还是说跟普通的局域是一样的。

两台可以上网的电脑（对于我们来讲是多么的珍贵..=_=!），通过一个路由上网。分别使用不同的花生壳，也就是不同域名指向同一个IP啦~~~机器上的数据库端口是让路由去分别做的映射。
然后做了一个 主-从 的备份设备，双向只是反过来做一次而以，所以没做复杂处理了。
这样的情况做的测试效果还可以，稍微有一点延迟，大概1秒左右，日常业务中找了一个最复杂的，数据量最多的一个功能，反复做了测试。没有发生什么异常情况。
不过遇到了一个问题，花生壳在机器闲置一段时间之后同步就停止了.....要重新重启Mysql才能获得数据~~~
换成3322之后这个问题在短时间没有发生。机器在那跑一个晚上，看明天会不会有什么问题。

MySQL 主从备份我原来做过，我当时还是在校园网内，开始运行时确实一点问题都没有，但是后来由于经过了几次停电，网络中断等事故后（一年之内遇到几次这样的事也是正常的），数据同步就出现了问题。后来就不敢再相信 MySQL 的主从备份了。

这样只有DNS走了宽带，以后的操作都没有走电信线路，顶多经过路由器NAT处理就又回来了，测试了路由器的负载能力。
至少要各通过一台不同的路由器出去才行。

顶这位兄弟。如果是无状态的数据，比如与其它记录无相关的insert操作，这样的同步就没有逻辑问题了，可以用增量备份。但是实际系统肯定复杂得的多。
举个简单的例子，张三帐上有100元，现在A地提交一个请求，要把这100元转到李四，B地同时提交一个请求，要把这100元转给王五。如果没有加锁机制，两方的操作都会成功。业务就出乱子了。因此在处理这个请求时，要把所有的数据库中相关记录先加锁，操作成功后解锁，才能保证状态的一致性。考虑到楼主提供的网络条件，操作延时估计很恐怖。

持续关注中~~~

啰嗦几句

这个系统的情况（需求、程序、市场等等）楼主最清楚，怎么测试才是完备的，估计别人也不好确定（比如我，到现在还不知道为什么需要个B地的主机）。
我接触过的系统都是中心式的（树状的），面对分布式的（网状的）还是怕怕的（也不算盲目的怕吧，毕竟所有的书上都会说：相对来说，中心式的优点是好管理）。
“设备是最大的开销”——莫非，人很便宜？（比如：我们不谈钱，只谈激情），或者已经有相似的成功的案例了？

印象中，自己做过的项目，即使做完后，也是一直忙于改进和完善系统，即使系统功能和性能完善了，我们也会做些让日志规范些、加几个监督系统状态的小东东的工作。系统已经满意了，倒会去考虑一下这些花活——它还是很令人血脉喷张的。
想想我有两三个做开发的哥们儿，每个人竟然为了自己做个网站玩玩而去租台服务器（我和朋友需要异地合作开发时，就
管他们某个人借服务器）——真是造孽啊！

应该是很多吧。我很多同事都在用五笔。

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

我很负责任的说，我对硬件部署是门外汉；但也很负责任的对楼主说，这种备份方案，我做IT8年，从没听说有人敢用的。
所谓没吃过猪肉，也看过猪跑。
除非你的数据不是很重要，比如做论坛，除了问题，少两贴子也无所谓（如果这样，也不用备份这么神经了吧）；否则，你的数据同步在网络带宽如此的前提下用数据库的同步，是一定出问题的。
枪毙了吧，免得出了问题，就难看了

能描述一下出了什么问题吗？
这两天的测试(网内，经同一个路由的测试)也发现了一个小问题，有时候日志上会记录数据未被同步，但是其实他是同步过去了，所以当插入数据的时候就会报ID已存在，然后同步就挂了。
加上忽略错误的配置。挂掉的情况就没了。
加上忽略错误的配置也蛮不错，还可以做环型备份~~~~好玩哪~~~

问题跟你说的差不多，就是日志执行到一些错误时同步就挂掉了，后面的数据不同步了。
忽略错误的配置我没敢加，哈哈。如果加上不会出这种问题的话，那你可以再试试，这个我就没再试过了。