OracleGoldenGate告警部署异常引发的数据库数据同步思考

IT那活儿 2022-02-08

901

点击上方“IT那活儿”，关注后了解更多精彩内容！！

文章前言

本文通过总结一次由OracleGoldenGate（下文简称OGG）监控告警部署问题引发的问题，获得对于该问题的解决方案和经验教训。在此基础上，做出跟广泛而深入的思考。在更好的注意告警部署细节的同时，提出借助平台化、白屏化思想来规避细节的方法，形成简单的口诀（一要完备测试，二要规范文档，三要场景平台化）方便记忆的同时，继而对该问题继续进行扩展，简要论述OGG与ADG联合架构部署的思路^[1]和更多OGG监控模式的思考。

技术背景

OGG是一种基于日志的结构化数据复制软件。OGG能够实现大量交易数据的实时捕捉、变换和投递，实现源数据库与目标数据库的数据同步，保持亚秒级的数据延迟。一个经典的OGG双向同步架构如图一所示：

图一 OGG双向同步架构

OGG因为其精密的特性，需要实时监控其运行状态，因此对于一套OGG系统，部署一套监控告警，以获取OGG延时信息、自动发现并能够发送对应的告警信息变得尤为关键。

问题描述

1. 问题产生复盘

问题发生于2021年12月28日9：00

问题发现于2021年12月29日9：00

问题发生背景：因计费ACCT库于2021年12月28日凌晨由主机A迁移至主机B，故需要在割接完成后，在新库（主机B）上部署OGG告警定时任务。但当晚在部署任务时操作出现若干失误，导致告警脚本并未即可正常工作。

问题发生负面影响：割接完成后当天，Oracle数据库经历了两次重启。重启时OGG抽取进程Abended，而此时并未产生告警，直到次日上午手动进入主机查看后才发现进程异常。但此时抽取进程启动所需归档已经被自动清理，抽取进程无法启动。

图二抽取进程启动报错信息

2. 产生问题原因

2.1 MGR进程参数设置问题：

因为此次割接时，OGG的MGR并非手动创建的，因此没有对它的参数进行检查，导致进程异常后，MGR进程不会正常拉起Abended进程。

2.2 告警脚本配置问题：

告警脚本的定时任务里有两条，分别用于监控进程查询脚本是否被屏蔽，以及监控进程并发送短信告警。在当晚测试时，仅对第一条定时任务的有效性做了检查，并未检查第二条定时任务的执行效果。直到次日进行进程核查时，才发现告警脚本配置问题。检查告警脚本的第二条定时任务后，发现两条报错：

发送告警信息的定时任务无法执行，报错输出文件目录不存在。
发送告警信息的定时任务（send_JF.sh）无法执行，报错系统JF不存在。

2.3 解决方案

2.3.1 配置MGR进程参数并重启MGR进程：

重新配置MGR进程参数，添加自动拉起进程配置。

图三重新配置MGR进程参数

2.3.2 重新配置告警脚本：

对于第一个问题「报错输出文件目录不存在」，发现是输出文件目录未修改，修改目录后出现输出文件。

对于第二个问题「报错系统JF不存在」，发现是ogg_send.json配置文件里系统名未修改。修改系统名后成功收到告警短信。

图四修改目录

图五修改系统名

2.3.3 手动恢复归档后重新拉起进程：

查询当前保留的的归档文件目录，发现最近的两个节点最近的归档文件在Seq.176左右，而进程所需归档文件需要恢复到Seq.134左右。

2.4 经验教训

这次的进程异常问题，只要在任意一步里处理好，都不会导致最终需要重新恢复归档。（如果MGR配好了参数，出现进程Abended就能够自动拉起；如果配好了告警，出现进程Abended就能够立刻得到消息）

但这样的失误也有一个“好处”，就是同时发现了两个问题。而如果其中一个问题不犯错，那么就发现不了另一个问题。（如果MGR配好了参数，出现进程Abended就能够自动拉起，那么就不会发现告警脚本没有配置好）

因此，对于其中导致错误最关键的两步做出如下总结：

检查MGR进程参数：不论MGR进程是否为手动创建，都要仔细检查其参数配置。推广到更一般的情况，就是在进行操作时，对所有与该操作有关的信息进行核查。
告警脚本完整测试：部署告警脚本的时候，需要对所有涉及的脚本进行测试。推广到更一般的情况，就是在进行操作时，对所有可能触发该操作的情况进行校验。

引发思考

1. 告警部署中的细节

除了在上文中提到的忽略的细节，部署监控告警脚本的细节并不少。

在本案例中，一个规范的部署过程包括如下步骤：

step1 从FTP服务器的ogg目录下载对应文件（需要下载的文件参考其他正常运行ogg的主机）。

step2 将对应文件根据定时任务参数放到对应的文件目录。

step3 从ogg进程参数里获得ogg在数据库中的用户名和密码，修改ora文件里的内容。

step4 从其他正常运行ogg的主机获取新的send_XX.sh文件和ogg_send.json文件覆盖从FTP服务器上下载的文件。并且修改ogg_send.json中的system_name为send_XX.sh中下划线的后缀XX。

step5 使用测试进程来尽可能完备的测试告警是否正常（一测监控告警脚本的脚本是否正常，二测告警脚本是否正常，三测定时任务是否正常）。

对于这些细节和错误处理的过程，需要形成规范化的流程文档，以尽可能防范问题再次发生。

2. 规避细节以永久性规避失误

注意这些细节，并对可能犯错的细节做总结的目的，并不在于在每次实施中都要检查这些细节。而是将复杂的细节尽可能地隐去，让这个操作的难度、门槛越来越低的同时，操作发生问题的可能性自然也会越来越低。

如今，业内越来越多的开始采用平台化、白屏化的方式进行各类复杂操作的处理（如下图）。OGG的监控告警部署同样可以使用这样的模式，让操作更加方便的同时，更让操作的门槛变得很低。不需要明白操作内部的原理，只需要在平台上完成简单的参数设置，就能够达到想要的目的。

图六白屏化操作示例

3. 口诀式概括

上述过程总结，可以概括为如下口诀：

告警部署，一要完备测试，二要规范文档，三要场景平台化。

值得一提的是，这个口诀可以推广到更多的场景里。

更多拓展

1. OGG与ADG联合架构部署

OGG只能提供准实时数据同步。另一种情况是，逻辑复制受到业务逻辑本身的限制，如果有大量的大型事务，就会发生拥塞，这通常是读写密集型业务不需要的，Oracle11g的新特性ActiveDataGuard（以下简称ADG）很好地解决了这个问题。ADG或者简称为DG可以打开的数据库保护，允许在应用来自主库的日志时以只读模式打开数据库。这意味着备用数据库不仅可以与主数据库同步，还可以提供实时查询来满足数据库读写分离的需求。一个经典的ADG架构如图七所示。

图七经典ADG架构

OGG和ADG可以联合部署，一个经典的基于OGG和ADG的灾难备用数据库读写分离架构如图八所示。它具有以下优点：

（1）采用OGG双向复制技术，有效保证数据一致性；

（2）备用数据库节点灵活、可扩展。它们可以在线添加或删除，并且可以线性扩展而不影响生产系统。

（3）能够真正实现实时查询，非大交易造成同步块，性能保证。

（4）高可用性，节点停机时间不会影响数据库的可用性。

图八使用OGG和ADG联合的灾难备用数据库的读写分离架构

2. 更多OGG监控模式的思考

在之前的问题里，仅仅思考了一套OGG系统的监控告警部署情况，也仅仅关注了进程运行状态与延时信息。但在实际的场景中（例如上面提到的多个OGG和ADG联合的灾难备用数据库的读写分离架构），维护人员需要看到的就不只是进程信息，它们还需要看到整体架构图等信息。

图九 OGG Monitor效果图

图十 OGG Director监控创建流程

图十一使用Zabbix3.2监控OGG延时效果图

在这方面，能看到业内做过的很多尝试。有官方提供的OGG Monitor的解决方案（如图九所示），也有使用OGG Director监控的解决方案（如图十所示），还有使用Zabbix3.2监控OGG延时的解决方案（如图十一所示）。这些解决方案在部署成本上、使用面上、适用系统特征上各有优劣，需要使用者灵活选择。

总结

数据库同步技术的发展日新月异，在Oracle规模本身更加庞大的同时，其数据同步组件本身的复杂性也在日记增加。近年来，有工作专注于对其架构的调整^[1]，也有工作专注于对其性能和公共数据连接部分的优化，有工作在分析原有集群技术的基础上，提出了一种新的数据库集群无共享磁盘结构^[2]。它们在解决数据库备份、数据容灾和负载均衡问题上都发挥着作用。在此情境下，如何更好的监控整个OGG的状态，成了一个愈发值得关注的问题，而自动化也将成为进一步研究的重要方向。

本文在论述具体问题的过程中，存在一定程度的特殊性。它所提供的解决方案并不一定在所有情境下适用。但在本文中，更希望的是借着对这个问题的复盘，阐述对这个问题的处理思路和继而阐发的思考和拓展，从而能够激发读者思维深度和广度。

参考文献：

[1] J. Hu, B. Yang, R. Yan, Q. Wang and K. Lin, "Disaster Preparedness Backend Database to Read and Write Separation Technology Research," 2020 2nd International Conference on Computer Communication and the Internet (ICCCI), 2020, pp. 88-92, doi: 10.1109/ICCCI49374.2020.9145978.

[2] Y. Xiao and Q. Gong, "Universal Database Cluster Solution -- Based on Goldengate," 2011 International Conference on Computational and Information Sciences, 2011, pp. 254-256, doi: 10.1109/ICCIS.2011.308.

本文原创来源：IT那活儿微信公众号（上海新炬王翦团队）

oracle

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

OracleGoldenGate告警部署异常引发的数据库数据同步思考