pt-archiver归档数据 源库和目标库是否会出现不一致

背景

  • 归档的表在源库和目标库都要存在
  • pt-archiver归档表的场景有：不删原表数据，非批量插入目标库；不删原表数据，批量插入目标库；非批量删除原表数据，非批量插入目标库；批量删除原表数据，批量插入目标库

版本
pt-archiver --version
pt-archiver 3.0.12

select @@version;
+-----------+
| @@version |
+-----------+
| 8.0.12 |
+-----------+

是否会出现不一致情况

  • 源库已经delete，目标库还没有insert
  • 目标库已经insert ，源库还没有delete

--bulk-insert
采用LOAD DATA INFILE的方式，相比一行一行的插入，通过为每批数据创建临时文件，先行写入数据到临时文件，当一批数据获取完毕后，再进行导入操作，加速了目标库插入的速度

--bulk-delete
批量删除，一批数据行用一个DELETE语句完成

生成100000条记录

sysbench /usr/local/share/^Csbench/oltp_read_write.lua --mysql_storage_engine=innodb --table-size=100000 --tables=1 --mysql-db=test_archiver --mysql-user=admin --mysql-password=admin --mysql-port=8013 --mysql-host=127.0.0.1 --threads=8 --time=10 --report-interval=1 --events=0 --db-driver=mysql prepare

源库和目标库在不同的实例 是否会出现不一致测试

源库
192.168.137.133:test_archiver

目标库
192.168.137.1:test_archiver

开启gerneral日志
set global general_log=on;

每5000条记录进行一次commit，每次取10000 条记录进行处理

nohup pt-archiver --source h=127.0.0.1,u=admin,p=admin,P=8013,D=test_archiver,t=sbtest1 --dest h=192.168.137.1,u=admin,p=admin,P=3306,D=test_archiver --progress 1000 --where "id<100000" --statistics --limit 10000 --sleep 10 --no-check-charset --txn-size 5000 --bulk-delete --bulk-insert &

中途kill掉 pt-archiver归档进程，源库和目标库没有出现不一致的情况
ps -ef | grep pt-archiver | awk ‘{print $2}‘ | xargs kill -9

目标库

select id from sbtest1 order by  id  desc limit 1;
+-------+
| id    |
+-------+
| 10000 |
+-------+
1 row in set (0.00 sec)

源库

select id from sbtest1 order by id   limit 1;
+-------+
| id    |
+-------+
| 10001 |
+-------+
1 row in set (0.00 sec)

源库执行语句

2019-08-21T07:02:58.600832Z        56 Connect   [email protected] on test_archiver using TCP/IP
2019-08-21T07:02:58.601186Z        56 Query     set autocommit=0
...
2019-08-21T07:02:58.966036Z        56 Query     SELECT MAX(`id`) FROM `test_archiver`.`sbtest1`
2019-08-21T07:02:58.967807Z        56 Query     SELECT CONCAT(@@hostname, @@port)
2019-08-21T07:02:58.989394Z        56 Query     SELECT /*!40001 SQL_NO_CACHE */ `id`,`k`,`c`,`pad` FROM `test_archiver`.`sbtest1` FORCE INDEX(`PRIMARY`) WHERE (id<100000) AND (`id` < '100000') ORDER BY `id` LIMIT 10000
...
2019-08-21T07:02:59.275620Z        56 Query     commit
...
019-08-21T07:02:59.532682Z        56 Query     commit
2019-08-21T07:02:59.834194Z        56 Query     SELECT 'pt-archiver keepalive'
2019-08-21T07:02:59.834835Z        56 Query     DELETE FROM `test_archiver`.`sbtest1` WHERE (((`id` >= '1'))) AND (((`id` <= '10000'))) AND (id<100000) LIMIT 10000
2019-08-21T07:03:09.958289Z        56 Query     SELECT /*!40001 SQL_NO_CACHE */ `id`,`k`,`c`,`pad` FROM `test_archiver`.`sbtest1` FORCE INDEX(`PRIMARY`) WHERE (id<100000) AND (`id` < '100000') AND ((`id` >= '10000')) ORDER BY `id` LIMIT 10000
...
2019-08-21T07:03:10.215958Z        56 Query     commit
...
2019-08-21T07:03:10.670937Z        56 Query     commit
2019-08-21T07:03:10.904398Z        56 Query     SELECT 'pt-archiver keepalive'
2019-08-21T07:03:10.904715Z        56 Query     DELETE FROM `test_archiver`.`sbtest1` WHERE (((`id` >= '10001'))) AND (((`id` <= '20000'))) AND (id<100000) LIMIT 10000  ====》( 该语句由于没有commit 语句会rollback )

目标库执行语句

2019-08-21T07:03:00.317343Z        33 Connect   [email protected] on test_archiver using TCP/IP
2019-08-21T07:03:00.338390Z        33 Query     set autocommit=0
...
2019-08-21T07:03:00.633938Z        33 Query     SELECT CONCAT(@@hostname, @@port)
2019-08-21T07:03:00.920655Z        33 Query     commit
2019-08-21T07:03:01.177267Z        33 Query     commit
2019-08-21T07:03:01.199046Z        33 Query     LOAD DATA LOCAL INFILE '/tmp/jaGuzZfjSept-archiver' INTO TABLE `test_archiver`.`sbtest1`(`id`,`k`,`c`,`pad`) （插入了 1=<id <=10000的记录）
2019-08-21T07:03:11.850618Z        33 Query     commit
2019-08-21T07:03:12.315829Z        33 Query     commit
2019-08-21T07:03:12.337323Z        33 Query     LOAD DATA LOCAL INFILE '/tmp/GQ2ybc3KCzpt-archiver' INTO TABLE `test_archiver`.`sbtest1`(`id`,`k`,`c`,`pad`)  ====》( 该语句由于没有commit 该语句会rollback ，并在 机器/tmp 目录下留下临时文件)

ll /tmp/GQ2ybc3KCzpt-archiver
-rw------- 1 root root 1920000 Aug 21 15:03 /tmp/GQ2ybc3KCzpt-archiver
  • 从日志可见，源库的delete 操作的commit时间（07:03:10.215958Z） 是在目标库insert操作的commit时间（07:03:11.850618Z）之前，这可能出现归档时源库已delete，目标库还没有insert的情况
  • 这次源库和目标库在不同的实例上，不同的实例时钟会出现不一致 影响general_log中commit出现的时间

源库和目标库在相同的实例 是否会出现不一致测试

源库
192.168.137.133:test_archiver

目标库
192.168.137.133:test_archiver2

删除测试数据重新生成100000 条记录

sysbench /usr/local/share/sysbench/oltp_read_write.lua --mysql_storage_engine=innodb --table-size=100000 --tables=1 --mysql-db=test_archiver --mysql-user=admin --mysql-password=admin --mysql-port=8013 --mysql-host=127.0.0.1 --threads=8 --time=10 --report-interval=1 --events=0 --db-driver=mysql cleanup

sysbench /usr/local/share/sysbench/oltp_read_write.lua --mysql_storage_engine=innodb --table-size=100000 --tables=1 --mysql-db=test_archiver --mysql-user=admin --mysql-password=admin --mysql-port=8013 --mysql-host=127.0.0.1 --threads=8 --time=10 --report-interval=1 --events=0 --db-driver=mysql prepare

每100000条记录 进行commit一次，每次取100000条记录进行处理
pt-archiver --source h=127.0.0.1,u=admin,p=admin,P=8013,D=test_archiver,t=sbtest1 --dest h=127.0.0.1,u=admin,p=admin,P=8013,D=test_archiver2 --progress 1000 --where "id<100000" --statistics --sleep 10 --limit 100000 --no-check-charset --txn-size 100000 --bulk-delete --bulk-insert

源库和目标库执行语句


2019-08-22T01:50:35.672490Z         9 Connect   [email protected] on test_archiver using TCP/IP
2019-08-22T01:50:35.673125Z         9 Query     set autocommit=0
...
2019-08-22T01:50:35.685987Z        10 Connect   [email protected] on test_archiver2 using TCP/IP
2019-08-22T01:50:35.686278Z        10 Query     set autocommit=0
...
2019-08-22T01:50:35.708866Z         9 Query     SELECT /*!40001 SQL_NO_CACHE */ `id`,`k`,`c`,`pad` FROM `test_archiver`.`sbtest1` FORCE INDEX(`PRIMARY`) WHERE (id<100000) AND (`id` < '100000') ORDER BY `id` LIMIT 100000
...
2019-08-22T01:50:40.242371Z        10 Query     LOAD DATA LOCAL INFILE '/tmp/X5W2UemPgDpt-archiver' INTO TABLE `test_archiver2`.`sbtest1`(`id`,`k`,`c`,`pad`)
2019-08-22T01:50:43.692914Z         9 Query     SELECT 'pt-archiver keepalive'
2019-08-22T01:50:43.693411Z         9 Query     DELETE FROM `test_archiver`.`sbtest1` WHERE (((`id` >= '1'))) AND (((`id` <= '99999'))) AND (id<100000) LIMIT 100000
2019-08-22T01:50:58.603351Z         9 Query     SELECT /*!40001 SQL_NO_CACHE */ `id`,`k`,`c`,`pad` FROM `test_archiver`.`sbtest1` FORCE INDEX(`PRIMARY`) WHERE (id<100000) AND (`id` < '100000') AND ((`id` >= '99999')) ORDER BY `id` LIMIT 100000
2019-08-22T01:50:58.606390Z        10 Query     commit
2019-08-22T01:50:58.717251Z         9 Query     commit
2019-08-22T01:50:58.780614Z        10 Quit
2019-08-22T01:50:58.781480Z         9 Quit
  • 从general日志看起来，目标库的批量插入是在源库的批量删除之前，目标库insert 操作的commit（01:50:58.606390Z） 也是在源库delete 操作的commit（01:50:58.717251Z）之前
  • ***在目标库的commit执行后0.11s 期间，pt-archiver发生异常终止(这概率是很小的#_#), 源库的commit没有执行，delete操作就会回滚，出现源库的数据和目标库的数据不一致的问题***

注意
MySQL8.0 执行load data infile 命令除了设置secure_file_priv 外，还需要在[client] 和[mysqld] 中设置local-infile=1，不然会出现错误
DBD::mysql::st execute failed: The used command is not allowed with this MySQL version

pt-archiver commit

  • 操作的相关代码可见是在目标库完成commit 操作后，源库才进行commit操作的
  • 当事务中操作的数据量很大时，源库delete的commit操作耗时也会比较长，pt-archiver发生异常终止后（源库的commit还没完成，delete操作会回滚），会出现目标库已存在数据，源库还未删除数据不一致的情况
 7068       if ( $dst ) {
   7069          trace('commit', sub {
   7070             $dst->{dbh}->commit;
   7071          });
   7072       }
   7073       trace('commit', sub {
   7074          $src->{dbh}->commit;
   7075       });
   7076       $txn_cnt = 0;
   7077    }
   7078 }

结论

  • 在pt-archiver归档非commit期间，pt-archiver异常终止，源库和目标库都会rollback，不会出现不一致情况
  • 在commit的时刻pt-archiver异常终止，可能出现不一致情况：目标库已经insert ，源库还没有delete的情况
  • pt-archiver异常终止后（没按时归档完，手动kill pt进程等），需手动校验目标库和源库的主键情况，否则再次归档会出现主键冲突的错误

pt-archiver归档工具的使用详解

pt-archiver
pt-archiver数据归档

原文地址：https://www.cnblogs.com/YangJiaXin/p/11610217.html

时间： 2024-08-06 11:46:27

pt-archiver归档数据 源库和目标库是否会出现不一致的相关文章

impdp+network link 跳过expdp直接导入目标库

impdp命令特殊用途,可以将数据库的一个用户迁移到另一台机器上的数据库的用户中.如果目标用户不存在,还可以对应的创建该用户. 快速的把A库上的用户迁移到B库上. 下面就来看一下命令格式: B库下执行命令: Impdp username/[email protected] schema=userA remap_schema=userA:userB remap_tablespace=tbsA:tbsB network_link=dblink_to_userA_on_userB 说明: Userid

分享一个远程更新目标库数据的存储过程

本文给大家分享一个远程更新目标库数据的存储过程,适用于更新列名一致,主键为Int类型,可远程链接的数据库.USE [Table]--切换到源表,就是数据最新的那个表GO/****** Object: StoredProcedure [dbo].[proc_DataUpdate] Script Date: 2018/5/4 15:08:56 ******/SET ANSI_NULLS ONGOSET QUOTED_IDENTIFIER ONGO(http://www.0831jlyy.com)--

数据包从源主机到达目标主机的过程。

本人现在研一,最近在准备学校的计算机网络考试,感觉自己对数据包选择路由和数据传输过程的实质总是不清楚,今天认真翻阅课本,参考博文,总算有了自己的理解. 本文采用循序渐进的方式今次那个陈述.理解同一广播域内两台主机通信过程是理解跨路由传输过程的先决条件,两者不同之处在于源和目标MAC地址的转换:因此先讲从同一广播域内两台主机通信,再将跨路由的数据传输过程. 情景一:同一广播域内,两台主机通信过程. 两主机要通信传送数据时,就要把应用数据封装成IP包(因为我们的网络大多都是TCP/IP的以太网了),

数据包从源主机到达目标主机的过程。【转】

最近把跨路由的数据传输过程搞的差不多了,所以特意写下这篇文章,仅为以后回忆之用.~ 为了便于理解,先从同一广播域内两台主机通信开始叙述吧.只要能理解这些,那也就差不多可以理解跨路由传输过程了(两者不同之处在于源和目标MAC地址的转换). 情景一:同一广播域内,两台主机通信过程. 我们知道两主机要通信传送数据时,就要把应用数据封装成IP包(因为我们的网络大多都是TCP/IP的以太网了),然后再交给下一层数据链路层继续封装成帧:之后根据MAC地址才能把数据从一台主机,准确无误的传送到另一台主机. 如

ORACLE同义词源库锁表导致目标库删除操作报ora 02055 02049 02063 06512

故障现象:目标库执行存储过程过程中报ora 02055 02049 02063 06512错误 排查过程:1.查询该存储过程的110行只是简单的删除动作 2.通过如下SQL语句查死锁,未见任何死锁SELECT 'alter system kill session '||chr(39)||l.session_id||','||s.serial#||chr(39)||'immediate;', l.session_id sid,s.serial#,l.locked_mode,l.oracle_use

pt-archiver 归档数据

pt-archiver 参数说明pt-archiver是Percona-Toolkit工具集中的一个组件,是一个主要用于对MySQL表数据进行归档和清除工具.它可以将数据归档到另一张表或者是一个文件中.pt-archiver在清除表数据的过程中并不会影响OLTP事务的查询性能.对于数据的归档,它可以归档到另一台服务器上的另一张表,也可归档到一个文件中,文件可以用LOAD DATA INFILE进行数据装载,这个功能其实就类似是表历史数据的增量删除. 基本说明pt-archiver [OPTION

Linux软件包管理04-压缩归档及源码编译安装

一.压缩.解压缩命令 1.压缩格式:gz, bz2, xz, zip, Z 2.压缩算法:算法不同,压缩比也会不同: 3.原始的压缩命令:compress: FILENAME.Z 解压缩:uncompress 4.压缩成.gz格式的文件(仅压缩文件) a)gzip /PATH/TO/SOMEFILE:压缩完成后会删除原文件,如:gzip /tmp/file* -d:解压缩,相当于gunzip命令: -#:指定压缩比,范围是1-9,默认是6: b)gunzip: 解压缩: gunzip /PATH

关于blob转到目标库报ORA-01461: 仅能绑定要插入 LONG 列的 LONG 值错误解决方案

在数据抽取时,开发需要clob类型的数据,但是目标库类型是blob类型的,于是抽取的时候报错: ORA-01461: 仅能绑定要插入 LONG 列的 LONG 值错误 可能有以下几种原因: 可能有以下几种原因: 1.插入到字符串长度大于4000字节. 2.插入到表中的记录的某个字段数据的实际长度大于2000个字节(如果是UTF-8,则是1333个字节):或者是插入的记录中有两个或两个以上长度大于2000字节的字符串. 3.数据库与客户端的JDBC 驱动不匹配.对于UTF-8或欧洲的某些字符集,o

总结数据科学家常用的Python库

概述 这篇文章中,我们挑选了24个用于数据科学的Python库. 这些库有着不同的数据科学功能,例如数据收集,数据清理,数据探索,建模等,接下来我们会分类介绍. 您觉得我们还应该包含哪些Python库?让我们知道! 介绍 我是Python语言的忠实粉丝,它是我在数据科学方面学到的第一门编程语言.Python有三个特点: 它的易用性和灵活性 全行业的接受度:它是业内最流行的数据科学语言 用于数据科学的庞大数量的Python库 事实上,有如此多的Python库,要跟上它们的发展速度可能会变得非常困难