东城建站推广,腾讯云存储 wordpress,wordpress yootheme,网络推广引流是做什么工作问题背景: 用户通过OGG从源端一个MySQL从库将数据同步到目标端的另一个MySQL数据库里面#xff0c;后面由于源端的从库出现了长时间的同步延时#xff0c;由于延时差距过大最后选择通过重建从库方式进行了修复
从库重建之后#xff0c;源端的OGG出现了报错ERROR OGG-0014…问题背景: 用户通过OGG从源端一个MySQL从库将数据同步到目标端的另一个MySQL数据库里面后面由于源端的从库出现了长时间的同步延时由于延时差距过大最后选择通过重建从库方式进行了修复
从库重建之后源端的OGG出现了报错ERROR OGG-00146 Call to VAMInitialize returned with error status 600: VAM Client Report CAUSE OF FAILURE : Failed to find binlog: inside binlog index从报错信息看很明显是源端的extract进程找不到读取的binlog文件这是因为从库进行了重建导致从库的binlog重新从1开始知道问题的原因之后用户对源端的extract抽取进行修复将抽取进程的读取位置重新指向最新序号1的binlog进行抽取源端的抽取进程也恢复了正常通过stats可以看到有在正常的抽取事务但奇怪的事目标端的replicat应用进程一直却无法应用数据进程状态显示为正常 问题分析 查看目标端应用进程r_test的状态可以看到应用进程r_test有在正常的读取队列文件而且没有存在应用延时的情况 检查应用进程的日志发现存在大量的事务被过滤的报错OGG-05664 CSN-based filtering suppressed 2 duplicate transactions, from trail Seqno 3, RBA 14043 to Seqno 3, RBA 14283. 最近一次的报错信息可以看到被过滤的 第一个事务为CSN 000000000000000000001:000000000011177 and transaction ID 000000000000000000001:000000000010963 最后一个事务为CSN 000000000000000000001:000000000011511 and
transaction ID 000000000000000000001:000000000011297 注:CSN表示事务结束所在的binlog位置:000000000000000000001表示事务在binlog的序号为1000000000011177表示事务结束的binlog位置pos transaction ID表示事务开始所在的binlog位置000000000000000000001表示事务在binlog的序号为1,000000000010963表示事务开始的binlog位置pos 查看目标端检查表里面应用进程的检查点信息可以看到当前检查点存储的低位线log_cmplt_csn为000000000000000000004:000000000003836,已经应用执行事务log_cmplt_xids为000000000000000000004:000000000003622均超过了之前报错被过滤的事务csn以及事务xid因此事务将被视作已经完成执行从而被跳过这也为什么应用进程看起来读取队列正常但一直没有应用事务的原因因为应用的事务csnxid都低于检查表里面的检查点csn以及事务XID 那为什么检查表里面的检查点信息都这么大呢从000000000000000000004序号我们可以判断检查点已经读取到了属于binlog为4的事务很明显这是重搭从库之前应用进程的检查点信息因为从库的binlog已经重新从1开始所以检查表的信息应该也需要被重新清理确保检查点也从binlog 1重新开始 问题解决 我们先要清理检查表里面链路的信息这里直接根据应用的进程名称删除检查表信息辅助的检查表checkpoint_lox记录为空不需要进行操作另一种方式直接删除应用进程delete replicat重建也可以清空检查表进程的信息
mysql delete from checkpoint where group_nameR_TEST; 修改进程r_test读取队列文件的位置指向最近一个的队列文件3再重新应用一遍队列文件由于修改的队列文件位置不一定准确可能出现重复应用数据的情况可以通过参数HANDLECOLLISIONS去解决冲突数据
GGSCI (rac2) 20 alter replicat r_test,extseqno 3,extrba 0 重新开启应用进程发现依然出现事务被过滤的报错OGG-05664 CSN-based filtering suppressed 15 duplicate transactions 问题二次分析 再次查看检查表的信息发现进程R_TEST的检查点又重新回到了之前的CSN位置000000000000000000004:000000000003836不是期待的binlog为1的日志 通过logdump分析队列文件3日志首先尝试根据filter ggstoken TRANID过滤检查点里面记录的事务ID000000000000000000004:000000000003836发现队列文件记录了从库重建之前的binlog 4的事务信息 之后再往下查找又发现了属于从库重建之后binlog日志序列号1的事务信息000000000000000000001:000000000005280 也就是说队列文件3同时记录了从库重建之前binlog 4的事务以及重建之后binlog 1的事务这样如果应用进程从队列文件头开始读取的话会先应用重建之前binlog 4的事务检查点里面的信息会更新为binlog 4的事务检查点信息这样后面再读取到重建之后binlog 1的事务信息时由于binlog 1事务的csnxid均低于binlog 4事务的csn,xid就会导致binlog 1事务都被过滤 最终解决 知道问题原因是由于队列文件里面同时包含从库重建之前binlog 4的事务以及重建之后binlog 1的事务之后我们需要获取更为准确的读取rba位置让应用进程跳过从库重建之前binlog 4的事务应用 通过logdump确认第一个属于binlog 1的事务的位置rba 4421 清理检查表里面链路的信息这里我直接根据应用的进程名称删除检查表信息辅助的检查表checkpoint_lox记录为空不需要进行操作另一种方式直接删除应用进程delete replicat重建也可以清空检查表进程的信息
mysql delete from checkpoint where group_nameR_TEST; 修改进程r_test读取队列文件的位置指向队列文件3rba 4421
GGSCI (rac2) 20 alter replicat r_test,extseqno 3,extrba 4421 注如果知道重建从库的时间点也可以通过修改应用进程的开始事务的时间点启动跳过重建之前的事务这种方式更加便捷
ALTER REPLICAT xxxx, BEGIN 2017-01-07 08:00:00 重新开启应用进程同步终于恢复正常没有再出现事务被过滤的报错 检查表的信息也更新为binlog 1的事务
