hadr清理大量历史数据的问题?

db2 10.1.3hadr 架构,由于系统最初设计和规划,并没有合理及时的数据清理策略,在数据量达到一定程度后,想要进行数据清理,但是发现要清理的数据已经上T ,在hadr架构下,主机清理掉大量数据,那么备机要重放大量的日志,尤其是当主机使用大量并发删除时,备机重放日志明显和主机日志差值...显示全部

db2 10.1.3
hadr 架构,由于系统最初设计和规划,并没有合理及时的数据清理策略,在数据量达到一定程度后,想要进行数据清理,但是发现要清理的数据已经上T ,在hadr架构下,主机清理掉大量数据,那么备机要重放大量的日志,尤其是当主机使用大量并发删除时,备机重放日志明显和主机日志差值较大。此时高可用方案不能达到真正的""灾难时高可用"",因为如果主备切换后,日志replay就需要一个长的时间。
如何给出一个方案,能达到高效清理,并又达到切换时延短。

收起

返回tongshuai的回答

tongshuaitongshuai  技术支持 , 上海新炬网络技术有限公司
kong_fanqingwuwenpin蜡笔小秦等赞同了此回答

一般在HADR环境里,主备库的性能都一样的,因此很少有主机产生日志速度超过备库重放日志速度的情况。不过如果想你担心的那样,主库大量删除数据,备库有可能存在日志重放速度跟不上的情况。那建议:
1.如果是要删除整张表,那用truncate清空表的方式,这种方式速度快,产生日志量少。
2.如果是删除表中的历史数据,那建议在业务繁忙时候小并发来操作,而可以在业务不繁忙时段,比如凌晨使用大并发来删除。

 2019-04-10
  • 表数据量已经 TB 级别了,而且没有进行分区。因此,我觉得第一种 “truncate 清空表” 不适合这种场景。 理由有二: 1、truncate 会导致 HADR primary 与 standby 的日志差变的极大,不能采用。因为 standby 备机的日志重放要修改大量的EMP并释放,毕竟表数据量 TB级别了 2、standby 过慢的日志重放会导致 primary 主机执行“truncate table”的应用长时间处于“Commit Active”状态,进而,又会阻塞其他访问该表的应用。一系列锁等问题会严重影响业务的可用性的
    2019-04-10

回答者

tongshuai技术支持, 上海新炬网络技术有限公司

回答状态

  • 发布时间:2019-04-10
  • 关注会员:3 人
  • 回答浏览:423
  • 关于TWT  使用指南  社区专家合作  厂商入驻社区  企业招聘  投诉建议  版权与免责声明  联系我们
    © 2019  talkwithtrend — talk with trend,talk with technologist 京ICP备09031017号-30