如此部署！? 征集点信心 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：
我们项目没有项目经理，没有级别，没有上下级关系，老板一人掌握所有事情的判断权利。老板为人心思细腻，事事要求完美。
。 79 楼 pipilu 2009-01-20 cocal 写道icewubin 写道这其实是就是把复杂度转嫁到开发中去了，原本不需要考虑这些问题的，但是因为愚蠢的BOSS搞出来的方案，导致系统的业务从设计到编码到测试都得考虑数据同步的可行性，你可以说业务天生就是如此，但是这“天生就是如此”这个结果就是要通过耗费人工评估得出的结果，这些无谓的成本大多是隐含的。
再有，很多人的想法是，同等成本（人力、物力）下，肯定有更好的整体方案，这是前提。
而楼主的大前提是BOSS下了命令，必须要那么整。
所以你的“未尝不可”基于哪个前提呢？
恕我直言，开发者觉得其他人（比如用户、销售、甚至搭档，当然也包括老板）愚蠢是很大的毛病！
其实从业务设计到编码测试本来就要考虑数据同步的可行性，只是技术人员有了一些现成的工具可用而已，系统设计就那几板斧，OO的结果就是大量的框架、模式、结构可以套用，过惯了衣来伸手、饭来张口的懒日子，就觉得永远不用考虑煮饭了。成本不是技术人员应该考虑的东西，这么说的技术人员只是怕麻烦而已。不得不提醒的是，怕麻烦，就没有机会吃更好的，就这么简单，成功不是随便来的。
我说“未尝不可”的前提是，这是一个新思路，LZ如果能证明这个方案可以成功，就做到了别人做不到的事情。你能做到别人做不到，或者你能先于别人做到，换句话说，就是竞争力！竞争力不用解释吧？吃的好些不难理解吧？何蠢之有？
觉得这个BOSS蠢的人，是否问过当年YAHOO和GOOLE创始人是否也蠢？当年Gates，Jobs哪个不蠢？
引用其实从业务设计到编码测试本来就要考虑数据同步的可行性
不是吧，我所接触过的项目，从设计到编码，考虑的充其量就是数据的单向同步、集中式的。像这种分布的、双向同步的。你们要是从开始就这样考虑了，那除非是系统有特殊的需求。否则，那真是太过了。如果做实习作品，我倒会考虑一下。
楼主在标题中说了“or 判个死刑”，说明大家也是可以投反对票的。是吧？
引用恕我直言，开发者觉得其他人（比如用户、销售、甚至搭档，当然也包括老板）愚蠢是很大的毛病！
不是什么毛病，我猜测只有两种人从来没提过其他人“愚蠢”，一种是很油的（滴水不漏），另一种是很“老”的（爱咋的咋的）。
不是懒不懒的事，实施本身相对来说要保守一些，而且楼主也传达了这样一个信息——他们需要保守一些。
成本一定就低了么？除非你不把人力、时间以及维护成本算进去。我在前面的留言已经说了，业务楼主最清楚，这种双向同步倒底有多麻烦，怎么样的测试才算完备，这得知道业务的人才知道。当然，后来楼主说了，他们两块儿客户的业务的数据相交很小。
很喜欢楼主的分享精神。
最后楼主可能测通了，而且系统也好好的跑着。但我认为这只能说明这样做没问题，并不能证明可靠性就一定比单机的高了。成本就一定低了。 80 楼 ztka 2009-01-23 xidaboy 写道cocal 写道xidaboy 写道
这位兄弟的回复,充分说明,根本就不知道MYSQL的主从方案是怎么实现的,你哪来的两天数据同步时间,这边库改了就立即自动要复制到另一库去,所以我一直就感慨,很多人其实根本就没做过,光用嘴说,光用脑子在想,要做!要做!
我说的两天，业务需求，不行吗？
MYSQL的确不了解，但同步就那么点道道，还能弄出花来啊？麻烦这位做过兄弟普及一下，什么叫“这边库改了就立即自动要复制到另一库去”，不能容忍网络中断？不能容忍网络拥塞？网络断了再恢复是什么结果？数据库CRASH？热备损坏？需要手工干预？
我发贴的目的是奇怪这么多人想都没想就去泼冷水，LS说我做都没做就去想...呵呵。咱们还是看LZ的吧..
哎~`早说了.你就没用过.你就是光想
如果网络断了,A库更新了,B库数据没进去.网络再恢复以后,B库的数据是不会自动和A同步的,这样是不是数据就不同步了,无限的人工修改,人工检查,这系统能用???
这个不难的
有Master Log File 和 Read_Maste_LogPos 可以保证数据同步。
81 楼 抛出异常的爱 2009-01-23 沙箱同步.
A所录入的C数据库时同时存入A沙箱
B所录入的D数据库时同时存入B沙箱
A定时去B上查寻B沙箱
B中数据录入C数据库
当有已录入的就跳过
------------------------------
A再查寻B上的D数据库
把A沙箱的数据与D数据库上的数据进行比较
同步完成的的就清除掉.
---------------------------
每步都作日志.
这个系统开发失败了 82 楼 makefile 2009-01-23 主机故障是怎么发现的心跳吗?
灾备要根据自己需求来了,恢复时间和数据丢失量是两个重要指标
可能的话做远程数据库冷备,也是灾备策略,这方案好歹还是比较实时的. 83 楼 eyeqq 2009-02-05 最终这一切还是不了了之的收场了。
至少目前是。
按照最开始的方法去做，起码是可以保证系统运行正常，也能达到一些效果。
可后面BOSS又要搞双Wan路由接入，等等一些，搞到现在动弹不得。 84 楼 phoenixup 2009-02-09 bonny 写道晕，我现在十分佩服你老板。要么脑子浑浑噩噩，要么有恶搞的才华。
你们的架构考虑都已经到了“担心自然灾害”而ab两地备份的情况了，居然还ip之贵，花生壳。
说真的，我忍住没说。。。。矫枉过正是这套结构的问题，BOSS到底搞清楚没他需要什么不需要什么。。好钢要用到刃上。。。
