数据库容灾、复制解决方案全分析

eygle

最初由 herycom 发布
[B]
eygle能介绍一下你们的同步复制规模吗？

光纤断了，两边都可以进行查询操作。
如果要恢复修改操作，就要修复网络。
如果短期内不能修复网络，那就切换到单机模式，但不能2台机同时使用，只能使用一台，否则恢复后就不知道以哪台为基准了。

我们这光纤很少出问题，因为有环路保护，即使进行割接或一般的故障，仍然能够保障网络不断。这就是电信级的传输的基本要求。 [/B]

没有任何技术能够满足所有的需求。
我的观点还是，能够满足需求的技术就是值得采用的。

"20多公里远的100M光纤环境"，不是任何企业都能有的。

我们的同步复制主要用于同步用户信息，我自己写了一系列的脚本用于故障处理，一旦发生网络故障，在主体定义站点打破复制关系，这样所有业务可以正常运行，待故障恢复后，再用脚本进行数据纠正，这部分基于对于数据的充分认识，是自己写的脚本，比Oracle的冲突纠正效率要高。

采用基于WAN的同步复制，最初也是有担心的。
但是我的想法是，如果可能出现问题，我们就来看看出问题的概率是多少，是否是可以容忍的。

还好运行至今，没有出现任何问题，WAN并没有想象的那么不稳定。
至少，目前这种方式满足了我们的需求。

boyli

讨论的好热闹
看了大家的讨论，才觉得自己还真是孤陋寡闻啊
前几天替gf写了一点容灾计划，只提到了存储级别和数据级别（standby db和dataguard）

不知道那样的计划让行家看到会笑成什么样：（

herycom

最初由 eygle 发布
[B]

"20多公里远的100M光纤环境"，不是任何企业都能有的。

我们的同步复制主要用于同步用户信息，我自己写了一系列的脚本用于故障处理，一旦发生网络故障，在主体定义站点打破复制关系，这样所有业务可以正常运行，待故障恢复后，再用脚本进行数据纠正，这部分基于对于数据的充分认识，是自己写的脚本，比Oracle的冲突纠正效率要高。

采用基于WAN的同步复制，最初也是有担心的。
但是我的想法是，如果可能出现问题，我们就来看看出问题的概率是多少，是否是可以容忍的。

还好运行至今，没有出现任何问题，WAN并没有想象的那么不稳定。
至少，目前这种方式满足了我们的需求。 [/B]

哈哈，我们马上就要建个100公里的100M光纤网络了，从广州到深圳。设备已经到位，正在调试之中。光纤是155M的，不过设备只支持100M。
随着以后通讯的发展，高带宽的环境会越来越多。
我准备在我们的一个小计费系统上建一个测试环境，该计费系统每5秒就增量处理一次话单文件，不过表不是很多，就话单表增长较快。大家听我的好消息。

zhao_yu

“100公里的100M光纤网络”
看到这个别的不说，以后要少用手机了，看看他们把钱都怎么花了。 @_@

lwxxrq

最初由 zhao_yu 发布
[B]“100公里的100M光纤网络”
看到这个别的不说，以后要少用手机了，看看他们把钱都怎么花了。 @_@ [/B]

呵呵！这个有点同感
高级复制学习ing

yuxuan

学习。。。
我们公司也打算弄

runaway

存储级的同步复制是需要远端确认写操作的结果才会返回，本地的写操作才能完成，由于阵列都配置有大容量的写cache，基本上都是写到cache就算成动，在带宽和时延有保证的情况下，速度可以接受。异步复制是通过保证io的顺序来保证数据库的可用性，不论是单个io还是成组io，结果就是一定数量的数据丢失，但是数据库和系统crash后重启一样，不应该出现打不开的问题，一般这种问题都是数据复制不完整的配置问题导致的。
关于数据库级的复制，可靠性实际上只有oracle自己可以保证，试想一下猜测redo的格式和不同操作的处理方式有多大难度吧，而且oracle明确说明不支持类似shareplex这类的复制数据方式，说严重一点都快够上通过逆向工程侵犯知识产权了：），而且oracle支持的操作很多，应用的要求各不相同，测试很难完全覆盖。
其实不论哪种复制，都是保证应用对数据的访问，开发应用的同志们应该勤快一些，从应用这一级解决问题，只有应用最了解自己的数据，也只有应用才能以合适和高效的方式解决这种问题。把这种问题推给系统只能接受各种不完美的解决方案。

herycom

最初由 zhao_yu 发布
[B]“100公里的100M光纤网络”
看到这个别的不说，以后要少用手机了，看看他们把钱都怎么花了。 @_@ [/B]

其实不用实际去架光纤的，在现有的传输网上调度就行了，通讯本来就是以强大的传输为基础，目前我们的传输容量还是有富余的。具体怎么样调我也不是很清楚，这个不是我的专业。
不过说明我们的光纤传输还是不错的，谁要想远程传输，我们可以提供服务。哈哈，顺便做下广告。
100M 好像太宽了点，调度了几个月还没搞好，有可能要降低带宽。不过这是上级的规划，我们也没有办法。

Drewlee

1.Oracle功能强大，同步复制也好，异步复制也好，都会集中在一台Server的处理上，充其量加个Cluster；为了保证系统的处理能力，都会是短距离的集群；不管怎么rollback，都由一台机器处理勒；容灾能力是有限的。
2.第三方的工具能提供的，我的使用经验不多，理解他们为DB异步复制的Cache的提供者，Cache的大小以及IO的频率取决于DB单位时间处理的数据量，以求达到最佳性能。
3.不要忽略存储的容灾技术。虽然存储的异步镜像等手段不及Oracle的日志这般智能，如EMC的SPA,SPB和Access Node等，对通过专有处理机来控制Cache，来保证远程镜像的准确性有其独到之处。
4.网路的多链路在local环境的容灾中效果明显，虚拟IP，交换机备份等名词，想来大家也不陌生了。


远程的同步复制，个人认为性价比极差；不是烧钱，没人会用。

一点浅见，多指教。


Drew Lee

herycom

哈哈，我将一张500多万记录的详单表进行了同步复制，源数据库是一台pc服务器，有磁盘阵列，目标机为普通的pc机，不过都有1G内存。
就是初始同步有点慢，要1个半小时，可能与目标机没有磁盘整理有关系。
然后的操作就是每5秒钟由应用程序将新增的话单插入表中，
同步前后应用程序性能没有明显的下降，还是2-3秒就能将增量话单处理完成。