DBus数据库表结构变更处理方法是什么
这篇文章主要讲解了“DBus数据库表结构变更处理方法是什么”,文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习“DBus数据库表结构变更处理方法是什么”吧!
创新互联是一家专注于成都网站设计、做网站、成都外贸网站建设公司与策划设计,广德网站建设哪家好?创新互联做网站,专注于网站建设10多年,网设计领域的专业建站公司;建站业务涵盖:广德等地区。广德做网站价格咨询:13518219792
一、感知表结构变更
对于感知表结构变更,Oracle已经通过DDL trigger为我们提供了很好的支持,接下来我们要考虑的是如何让DBus感知到表结构变更? 我们讨论出以下两种方案:
1.1 RPC方案
在DDL trigger中调用DBus提供的REST服务,将表结构变更事件发送给DBus。
该方案思路简单容易实现,但也有一些明显的弊端,比如DBus需要提供高可用、低延时的REST服务,否则可能会使数据库中的DDL操作变得缓慢甚至执行出现错误; DBus 的REST服务器对有数据实时同步需求的所有数据库都必须开通防火墙策略,这将给DBus的部署带来很大的麻烦。
1.2 OGG实时同步方案
在DDL trigger中将表结构变更事件存储到一张Event表里,然后通过OGG实时的从日志中将数据同步到Kafka,从而感知表结构变更事件。
该方案实现相对复杂但具有很多优点,比如对数据库的侵入性相对较小,DDL执行时只是将数据写入到Event表中,相对网络通信来说,其延时更低、可靠性更高;更明显的优势是这种方案基于数据库日志实现,能够使用Event表的数据,严格的将表结构变更前后的数据区分开。
举例来说,对于表:test来说,依次执行insert → alter → insert 三个操作,因为OGG读取数据库日志存在延时,如果利用RPC方案,可能出现这样的一种情况:DBus REST服务接收到alter事件之后,第一个insert的记录才被OGG捕获并发送给DBus,此时DBus会认为这条数据中包含alter变化后的数据。这是一个很严重的问题,而OGG实时同步方案无论数据还是时间均通过OGG读取日志的方案实现,可以完美的避免这种问题的发生。
对比两种方案OGG实时同步方案优势明显,最终我们采用此方案。
然而,采用这种方案也并非一帆风顺,按照该方案的总体思路实现以后,我们遇到了一个很奇怪的问题:通过DDL trigger写到Event表中的数据无法被OGG读取,在经历多番尝试无解之后,我们试图到OGG的文档中寻找答案,而最终的结果却是:DML or DDL operations performed from within a DDL trigger are not captured.
这个答案让问题变得更棘手,但这是最佳方案,我们没有理由放弃。于是我们开始尝试在DDL trigger中调用存储过程,在存储过程中执行Event表的insert操作,但由于存储过程和DDL trigger仍然属于同一个事务,因此Event表的数据依然不能被OGG捕获,但通过这个尝试我们觉得只要在另外一个事务中写Event表就能解决我们面临的问题,于是我们又想到了RPC,但RPC缺点太过明显。那么有没有其他可以替代的方案呢?
实际上oracle数据库里可以使用多种语言来编写存储过程,Oracle 8i开始支持java编写存储过程,于是我们立即开始实现java存储过程,通过JDBC连接数据库实现Event表的写入并提交事务,最终通过实践验证了这种办法的可行性,OGG成功的获取到了DDL trigger调用java存储过程写入到Event表的数据。
然而,这种实现并不算完美。当我们在生产环境部署DDL trigger的时候,发现数据库服务器中并没有安装执行java所需要的组件,每次部署都需要DBA同学安装执行java存储过程所需要的组件,我们试图找到一个不使用java存储过程的方案。这里要感谢韩锋老师对我们的帮助,韩老师在听了我 们的实现原理之后,启发我们自治事务应该可以解决这个问题,我们即刻动手开始改造DDL trigger,使之支持自治事务,经过改造之后该方案才算完美,最终实现逻辑如图1所示:
二、处理表结构变更事件
DBus已经具备通过事件方式感知表结构变更的能力,接下来详细说明一下表结构变更事件该如何处理。
下图描述了Event的完整处理流程:
Event中描述了发生结构变更的表名、该表所属的schema以及元数据版本号,DBus接受并解析Event之后,根据表名、schema以及版本号调用元数据抓取模块获取该表的元数据(包括表的字段类型、长度以及注释等)信息,实际上DDL trigger和alter语句在一个事务中执行,这样在trigger执行过程中无法从oracle的数据字典里获取到修改之后表结构元数据,我们写入到meta_history表中的元数据只是执行alter语句之前的元数据信息(因此我们给这个表取名为table_meta_his),要得到完整的元数据信息需要联合table_meta_his和数据字典进行查询,示意SQL如下:
这个SQL的结果有两种可能:
1)只包含all_tab_cols视图中的数据
2)既包含all_tab_cols视图中的数据又包含table_meta_his表的数据(is_current字段的作用是区别该字段的来源)
结果A表明在table_meta_his表中没有找到数据,这说明在生成表结构变更Event至元数据抓取程序成功获取元数据期间没有再次发生表结构变更,结果B则说明在此期间又发生过一次或多次表结构变更。
为什么要使用union all?
单独使用上图中的两个SQL可能导致元数据获取程序获取到错误的结果,例如:接到表结构变更Event 1后,我们调用SQL 1 查询table_meta_his结果集为空,在调用SQL 2之前表结构再次发生变更(命名为Event 2),这种情况下我们通过SQL 2 查询到的结果实际上是再次变更后的结果,使用这个结果产生的元数据去解析Event 1和Event 2之间的数据,如果两次表结构变更是不兼容的,那么必然会导致解析失败。
感谢各位的阅读,以上就是“DBus数据库表结构变更处理方法是什么”的内容了,经过本文的学习后,相信大家对DBus数据库表结构变更处理方法是什么这一问题有了更深刻的体会,具体使用情况还需要大家实践验证。这里是创新互联,小编将为大家推送更多相关知识点的文章,欢迎关注!
本文名称:DBus数据库表结构变更处理方法是什么
当前链接:http://myzitong.com/article/ieshho.html