oracle的ADG那是自不必多说,用存储圈的话说,现在存储正在从被动被动变为主动,但是总体上是被软件抢,RAID被ASM抢,快照被Flashback抢,DR被ADG抢。
如果这几种方案结合在一起那会是什么结果。这就涉及到一个备库的设计方法。
我也是抛砖引玉。环境都是基于11g的dg来说。
首先基本的,一个主库一个备库是很多系统都在采用的备库设计方式,如果数据库比较关键,这种方案有什么缺点呢。
11g的备库现在也被赋予了更多的责任。
容灾,首先就是容灾如果主库挂掉,备库能够进行failover,这个没有问题,那么11g的备库现在也被赋予了更多的责任。
批量查询。可能会有一些批量查询,报表查询的任务。那么这部分功能就可以放到备库来。
人为操作的防范。如果出现了误操作和人为操作,是否能够及时合理的预防。
所以一主一备的方案就会有几个弊端,
首先批量查询,如果批量任务压力较大,本身对于CPU资源消耗较大,如果长年累月,其实本身硬件消耗就不可忽略,如果长此以往,可能出了问题切过来也不见得保险。
如果出现人为误操作,这种防范怎么来说,如果延时怕丢太多数据,不延时,人为误操作不可避免,一年出一次这样的情况就够我们好好折腾一番了。
那么我们设计一主两备?
如果这样设计,对于关键业务也不错的。不过有几个需要考虑的地方,还是要满足刚刚的几个需求,灾备,支持大查询,人为误操作防范。
那么standby 1就可以设计为在同一个相邻的区域内,而standby2则可以考虑成为异地灾备,异地灾备也是很重要的一个考虑,如果机房掉电,几个备库都在都一个机房,那就很可能受到牵连。
所以异地灾备也很重要。那么怎么满足上面三个需求呢。
首先灾备,一主两备,考虑了异地灾备,这个本身就是一个不错的解决方案。
然后支持大查询,那么可以考虑把大查询的人物分散开来,在两个备库上跑,比如一个60%,一个40%等等,也不要让备库彻底闲着。同时压力也降低了不少。
然后就是人为误操作了。这个怎么防范,如果按照目前的一主两备的环境,也有几种方案,一种就是对另外一个备库开启延迟应用归档。
比如对于异地灾备standby2,设置延时2个小时,那么这种情况下出现了人为误操作,比如truncate就还有可能追回被误删的数据。不过仅仅是可能,因为到底是几个小时谁也说不清楚。万一出现了3个小时前的误操作,大家最后发现是因为误操作导致的,那么这种方案也得掉链子了。
可能有的朋友会说了,如果在2个小时之内,比如切换了20个归档,truncate操作是在最后的归档中,即第20个归档中的操作,那么第20个归档中的数据变化可能类似下面的形式。
那么你怎么保证一定能够严格恢复回来,可能有的朋友说,可以使用logminer,恩,也可以,不过还是需要点功夫。而且不一定能够100%保证吧。
还有什么方案能够继续改进呢。可以试试闪回数据库。
其实在11g中,闪回数据库早已不是什么新鲜特性了。那么他怎么来完成上面的三个需求呢。
灾备自不必说,大查询也可以支持,那么人为误操作呢。那就是下面的绿色箭头所示。
通过在异地灾备2上做闪回,然后穿越之后得到了需要的数据,接着exp导出,然后部署到主库中。然后备库继续开启日志应用即可。
看来这种方法还是能够满足这几个需求了。
那么我们再把这些需求再梳理一下。那么在这种情况下,大查询就可以分担一下了,在备库1上可以多分担一些,备库2上就可以少分担一些。还有就是异地灾备需要额外再加入一些闪回日志的空间了。
那么如果出现了同城机房两台机器奔溃的情况,而且更为严重的是在崩溃的前一分钟,出现了人为误删除操作,那么异地灾备会不会给力呢。
这种情况下,就需要先做闪回数据库,exp出来需要的数据,然后做failover,然后关掉闪回数据库的功能,接着就是重新部署搭建灾备环境了,所以还是依旧可以保证,可能有一点美中不足就是可能闪回,如果表比较大,可能导出数据都需要花费些时间了。
所以一主两备的方式就能玩出这么多花样来,只要保证方案的稳定性,这么来看闪回数据库在一主两备的条件下还是可以考虑采用。
如果这几种方案结合在一起那会是什么结果。这就涉及到一个备库的设计方法。
我也是抛砖引玉。环境都是基于11g的dg来说。
首先基本的,一个主库一个备库是很多系统都在采用的备库设计方式,如果数据库比较关键,这种方案有什么缺点呢。
11g的备库现在也被赋予了更多的责任。
容灾,首先就是容灾如果主库挂掉,备库能够进行failover,这个没有问题,那么11g的备库现在也被赋予了更多的责任。
批量查询。可能会有一些批量查询,报表查询的任务。那么这部分功能就可以放到备库来。
人为操作的防范。如果出现了误操作和人为操作,是否能够及时合理的预防。
所以一主一备的方案就会有几个弊端,
首先批量查询,如果批量任务压力较大,本身对于CPU资源消耗较大,如果长年累月,其实本身硬件消耗就不可忽略,如果长此以往,可能出了问题切过来也不见得保险。
如果出现人为误操作,这种防范怎么来说,如果延时怕丢太多数据,不延时,人为误操作不可避免,一年出一次这样的情况就够我们好好折腾一番了。
那么我们设计一主两备?
如果这样设计,对于关键业务也不错的。不过有几个需要考虑的地方,还是要满足刚刚的几个需求,灾备,支持大查询,人为误操作防范。
那么standby 1就可以设计为在同一个相邻的区域内,而standby2则可以考虑成为异地灾备,异地灾备也是很重要的一个考虑,如果机房掉电,几个备库都在都一个机房,那就很可能受到牵连。
所以异地灾备也很重要。那么怎么满足上面三个需求呢。
首先灾备,一主两备,考虑了异地灾备,这个本身就是一个不错的解决方案。
然后支持大查询,那么可以考虑把大查询的人物分散开来,在两个备库上跑,比如一个60%,一个40%等等,也不要让备库彻底闲着。同时压力也降低了不少。
然后就是人为误操作了。这个怎么防范,如果按照目前的一主两备的环境,也有几种方案,一种就是对另外一个备库开启延迟应用归档。
比如对于异地灾备standby2,设置延时2个小时,那么这种情况下出现了人为误操作,比如truncate就还有可能追回被误删的数据。不过仅仅是可能,因为到底是几个小时谁也说不清楚。万一出现了3个小时前的误操作,大家最后发现是因为误操作导致的,那么这种方案也得掉链子了。
可能有的朋友会说了,如果在2个小时之内,比如切换了20个归档,truncate操作是在最后的归档中,即第20个归档中的操作,那么第20个归档中的数据变化可能类似下面的形式。
transaction 1 |
transaction 2 |
transaction 3 |
transaction 4 |
…. |
transaction 10 |
truncate |
还有什么方案能够继续改进呢。可以试试闪回数据库。
其实在11g中,闪回数据库早已不是什么新鲜特性了。那么他怎么来完成上面的三个需求呢。
灾备自不必说,大查询也可以支持,那么人为误操作呢。那就是下面的绿色箭头所示。
通过在异地灾备2上做闪回,然后穿越之后得到了需要的数据,接着exp导出,然后部署到主库中。然后备库继续开启日志应用即可。
看来这种方法还是能够满足这几个需求了。
那么我们再把这些需求再梳理一下。那么在这种情况下,大查询就可以分担一下了,在备库1上可以多分担一些,备库2上就可以少分担一些。还有就是异地灾备需要额外再加入一些闪回日志的空间了。
那么如果出现了同城机房两台机器奔溃的情况,而且更为严重的是在崩溃的前一分钟,出现了人为误删除操作,那么异地灾备会不会给力呢。
这种情况下,就需要先做闪回数据库,exp出来需要的数据,然后做failover,然后关掉闪回数据库的功能,接着就是重新部署搭建灾备环境了,所以还是依旧可以保证,可能有一点美中不足就是可能闪回,如果表比较大,可能导出数据都需要花费些时间了。
所以一主两备的方式就能玩出这么多花样来,只要保证方案的稳定性,这么来看闪回数据库在一主两备的条件下还是可以考虑采用。