资讯专栏INFORMATION COLUMN

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

IT那活儿 / 2758人阅读
OracleGoldenGate告警部署异常引发的数据库数据同步思考

点击上方“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那活儿微信公众号(上海新炬王翦团队)


文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/129671.html

相关文章

  • AIOps在携程践行

    摘要:随着人工智能时代的到来,携程生产环境运维进入了新的运维时代。本文选取了几种典型的运维场景对在携程的践行展开了介绍,首先让我们从概念认识下。针对应用异常指标检测这种场景,抽取一定的样本统计,在基于专家经验标注下的准确率可达到以上,召回率接近。 作者简介徐新龙,携程技术保障中心应用管理团队高级工程师,负责多个AIOps项目的设计与研发。信号处理专业硕士毕业,对人工智能、机器学习、神经网络及数学有...

    MingjunYang 评论0 收藏0
  • 雷神 Thor —— TiDB 自动化运维平台

    摘要:相当于分布式数据库的大脑,一方面负责收集和维护数据在各个节点的分布情况,另一方面承担调度器的角色,根据数据分布状况以及各个存储节点的负载来采取合适的调度策略,维持整个系统的平衡与稳定。原文链接雷神自动化运维平台 作者:瞿锴,同程艺龙资深 DBA 背景介绍 随着互联网的飞速发展,业务量可能在短短的时间内爆发式地增长,对应的数据量可能快速地从几百 GB 涨到几百个 TB,传统的单机数据库提...

    RayKr 评论0 收藏0
  • 如何让运维指标变得更有价值?

    摘要:为了掌握你的告警事件响应时间,在你已经开始处理告警时,强烈建议及时响应认领,例如通过移动端微信页面移动等方式及时认领。这一点国外做的很棒,在短信电话移动都可以很容易确认认领在微信端可以认领和关闭。 这是《运维不容错过的4个关键指标》的姐妹篇,上篇文章介绍了优秀运维团队需要关注的4个关键指标,我们分享了平均恢复时间 MTTR、平均响应时间 MTTA 等概念。这篇是介绍一些实践方法,更好的...

    suxier 评论0 收藏0
  • vivo统一告警平台设计与实践

    摘要:告警当一个问题通过告警系统将消息以短信电话邮件等方式告知给用户时,我们称之为一条告警。图统一告警系统结构图告警收敛对于告警平台每天会产生数以万计的告警,这些告警对于运维或开发人员都需要去分析甄别优先级并处理故障。 一、背景一套监控系统检测和告警是密不可分的,检测用来发现异常,告警用来将问题信息发送给相应的人。v...

    Rocko 评论0 收藏0

发表评论

0条评论

IT那活儿

|高级讲师

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<