数据库高可用复制环境的保护机制与监控建议

白鳝的洞穴 2021-02-05

869

企业的IT决策人员都清楚，对于关键系统，依靠备份恢复来确保数据库系统的高可用是无法满足企业对关键系统可用性的要求的。于是这些IT主管都在寻找能够保障其数据库系统在任何时候都可以快速恢复的技术方案。数据库高可用复制是保障关键系统可用性的最为有效手段，我们的很多IT部门的领导总是在寻找各种各样看似高大上，并且需要做很大额外投入的产品来确保自己的关键系统的高可用，却往往忽视了这些成本低廉，运维成本较低的原生态的数据库高可用保护机制。

十多年前，老白就在向客户推荐Oracle的dataguard，只要建立起可用于切换的standby database，那么这个企业的数据库运维就是有底线保障的，大不了切换到备库，丢失少量的业务数据就可以在1小时内完全恢复系统的运行。对于对数据一致性要求特别高的系统，通过把一个member的REDO LOG写到STANDBY DATABASE所在的存储上，还可以确保不丢失任何数据。当年淘宝的支付宝就是靠这个手段来确保0数据丢失的。

和十多年前相比，现在越来越多的企业接受了这个观念，对关键业务系统构建高可用备库也成了标准动作。对于Oracle来说，可以用ACTIVE DATAGUARD或者DATAGUARD，这二者之间的区别是，ADG的备库是可读的，DATAGUARD的备库平时是处于MOUNT状态的，不会打开。ADG是要收费的，虽然绝大多数天朝的ORACLE用户并未对此买单，从法律上讲，是收费的，而DATAGUARD是不收费的。Mysql数据库的高可用复制就不用细说了，不论是MGR集群还是MHA，都已经被我们的企业应用的炉火纯青了。对于PG来说，streams replication是标准选项，这种技术与Oracle的DATAGUARD的原理十分相似。

Oracle的Dataguard是一种有着二十多年历史的数据库高可用复制技术，老白在90年代就给客户搭建过standby database，这就是现在ADG的爷爷。早期维护DATAGUARD环境中遇到最大的麻烦是，DBA或者备份工具把主库的归档删了，但是有些归档还没有发送到备库端，这样备库就无法同步，DBA的苦活就来了。这个备库必须重建，在10M网络和不如现在2、30万的入门级存储的当年高端磁盘阵列的环境下，重建一个备库是一个需要几天的大工程。于是，当STANDBY DATABASE升级为DATAGUARD（9.2.0.1之后）的时候，ORACLE提供了这种保护机制，如果备份软件要删除未被某个备库应用的归档日志的时候，会报RMAN-8120/8137错误。而我们要做手工删除的时候，也需要根据v$archived_log里的相关状态位来进行删除，从而确保这种情况不会发生。为了避免归档空间的使用率过高，我们需要采用必要的监控手段来分析每个备库的应用情况，及时发现过大的备库应用延时，从而避免此类故障的发生。

PostgreSQL社区这些年发展的特别快，Oracle备库存在的问题，也给了PG开发者很大的启示。这些年PG在确保streams replication的安全上做了数次的优化调整，其目的是让复制更加容易管理。为了避免出现主备库之间复制出现问题，运维人员没有及时发现导致主库WAL已经被删除，备库无法恢复复制状态必须重建的情况出现，PG在9.4版本开始引入了复制槽（replication slot）机制。复制槽机制的目的是为了保证未被传输到某个备库的WAL不会被删除，哪怕WAL的大小已经超过了max_wal_size等规定的大小。只要某个复制槽还需要某个WAL，某个WAL就会被保留下来不被覆盖。这个机制在保护备库不会出现因为WAL文件丢失而需要重建方面能够发挥很好的作用，这一点和Oracle的归档日志保护机制类似。不过这个机制也会带来一些不良的影响，如果我们创建了某个备库，但是这个备库损坏了，暂时不会恢复，甚至可能DBA也忘记了这个备库的存在。那么配置了复制槽的环境中，WAL就会野蛮增长，直到用尽所有的空间为止。

PG社区的Kyotaro Horiguchi一直为解决这个问题而努力。经过漫长的审查和反复优化，这个能够限制为某个复制槽保留WAL的大小的功能已经十分成熟了并被集成到PG 13中了。它的工作方式非常简单：在PG 13中引入了一个新的参数max_slot_wal_keep_size，该参数限制允许复制槽保留的WAL的最大磁盘空间。如果某个插槽到达该点并发生检查点，则该插槽将被标记为无效，并且某些WAL文件可能会被删除。如果walsender进程正在使用该插槽，则将发出该进程信号，使其终止。如果walsender重新启动，它会发现WAL无法传输而自动终止。

从PG这些年在streams replication上的这些优化来看，目的都是让运维高可用复制环境更为方便，避免一些不必要的错误导致需要重建复制环境这种高开销的运维工作的出现。实际上ORACLE也是在这么做，只不过Oracle在这方面做的没有PG多。无论数据库给你提供了多么完善的保护机制，运维监控仍然是不可或缺的。前面的一些问题，在一个监控体系十分完善的环境下，是不容易发生的，但是事实上往往我们的运维体系总有不够完善的地方。因此我们还是需要对复制进行有效的监控。比如对ORACLE，我们可以通过主库的v$archived_log视图进行监控，及时了解归档目的地的日志接收应用情况，对于PG，我们建议启用replication slot，并且对pg_replication_slots视图进行监控。对于已经处于extented状态的slot加以重点关注，对于unreserved状态的slot,就应该及时清除了。

高可用复制是关键业务系统运维的底线，确保这个底线的安全，是运维人员十分重要的职责，为了自己的职业生涯，这条底线也是必须严守的。

数据库

文章转载自白鳝的洞穴，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

数据库高可用复制环境的保护机制与监控建议

评论