goldengate classic模式在空闲数据库上抽取和应用数据延迟问题

【数据同步场景】

1、采用数据库的同步数据方式，例如以oracle代表采用基于日志物理同步方式，支持最大保护模式、最大可用模式、最大性能模式3种,以mysql为代表采用基于binlog日志逻辑同步方式.数据同步性能受到主备之间网络、主库事务大小、备库IO性能以及备库是否采用并行复制等

2、采用非数据库的同步数据方式:

例如以goldengate读取数据库日志来准实时同步数据,能够支持绝大部分数据库以及大数据平台.

以canal读取mysql binlog来同步数据.

以kettle读取数据库表的记录来同步数据，对开发和表设计要求较高.

本次主要关注使用goldengate同步数据的主题:

1、goldengate复制架构

2、goldengate复制逻辑以及延迟问题

3、goldengate性能优化

【goldengate架构】

goldengate出现延迟包括:capture、传输、delivery这个三个部分，其中capture相当于extract进程，传输进程相当于pump，delivery相当于replicat.

【goldengate复制逻辑以及延迟】

goldengate出现延迟分为源端和目标端，源端延迟分为抽取和传输进程，抽取遇到大事务、大的DDL、表没有主键等

传输遇到广域网或者需要传输数据量超过带宽，当然可以使用压缩传输来降低带宽;

以上遇到源端繁忙的情况的延迟可以理解，但是对于源端无任何负载且事务很少的情况下也出现稳定的5-6s的延迟.

目标端出现延迟比较正常，例如源端是并发dml操作，目标端正常情况单进程去应用源端sql对应每一条dml操作，

例如源端更新1000记录；update table aa set id>=1 and id<=1000;通过ogg抽取到目标端变成1000 op操作.源端成比例的并发，目标端还是一样单进程去操作，自然延迟就正常.但是源端很空闲的情况，目标端也出现延迟，这个有点不可思议.

对于空闲数据库的延迟来说，需要了解goldengate如何读取日志和应用生成的trailfile中数据.goldengate如何知道源端数据库有新的日志生成，然后pump、replicat也是同样的道理.由于goldengate并非数据库的插件，属于oracle中间件产品，goldengate通过checkpoint机制定时去检查是否有新的日志生成，而不是数据库主动通知goldengate去解析日志,所以这个checkpoint阈值就会影响抽取生成日志的时效.goldengate通过checkpoint机制定期检查是否到达日志末尾(EOF),如果到了就切换到下一个，类似这种机制。以oracle为例,通过类似SQL查询:

 SELECT 1 FROM V$LOGFILE WHERE(STATUS NOT IN ('STALE', 'INVALID') OR STATUS IS NULL) AND MEMBER <> :log_name AND EXISTS (SELECT 1 FROM V$LOG WHERE GROUP# =
V$LOGFILE.GROUP# AND THREAD# = :ora_thread AND SEQUENCE# = :ora_seq_no ) AND ROWNUM = 1;

【goldengate 控制参数】

Use the EOFDELAY or EOFDELAYCSECS parameter to control how often Extract, a data pump, or Replicat checks for new data after it has reached the end of the current data in its data source. You can reduce the system I/O overhead of these reads by increasing the value of this parameter.

Default

The minimum is 1 second ; the maximum is 60 seconds (6000 centiseconds). The default is 1 second (100 centiseconds).

通过官方文档了解goldengate出发时间是1s，对于空闲数据库来说，源端抽取+传输进程=2s,replicat进程的1s，加上本身传输以及应用之类时间差不多在4s-6s.对于空闲数据库来说延迟保持一个相对恒定在4s-6s.如果把EOFDELAY调整到更高的值，数据库延迟会更大，对于系统IO负载很高的数据库来说，可以适当调高。

对于空闲数据库来说，如果不调整EOFDELAY或者EOFDELAYCSECS的值，不管是调整参数：MAXTRANSOPS 、 GROUPTRANSOPS BATCHSQL是无法优化的.还是拆分进程或者使用并行应用方式都无法收到好的效果.于我们的理解存在偏差.

【goldengate 调整EOFDELAY来降低延迟】

EOFDelay默认是1s，已经最小值，只能调整EOFDelayCSecs 从100调小来降低，可以设置到EOFDelayCSecs 10或者1，整个延迟从5s降低1s左右.

补充:对于集成模式同样存在类似问题.