利用pt-table-sync 解决主备数据不一致的问题

https://www.percona.com/doc/percona-toolkit/2.2/pt-table-sync.html

提醒

  • 在使用之前备份将要操作的数据表
  • 使用 --replicate or --sync-to-master方法,是在主库做修改,而不是直接修改备库

同步语法

-- Sync db.tbl on host1 to host2:
pt-table-sync --execute h=host1,D=db,t=tbl h=host2

-- Sync all tables on host1 to host2 and host3:
pt-table-sync --execute host1 host2 host3

-- Make slave1 have the same data as its replication master:
pt-table-sync --execute --sync-to-master slave1 

# Resolve differences that pt-table-checksum found on all slaves of master1:
pt-table-sync --execute --replicate test.checksum master1

# Same as above but only resolve differences on slave1:
pt-table-sync --execute --replicate test.checksum --sync-to-master slave1

# Sync master2 in a master-master replication configuration, where master2’s copy of db.tbl is known or suspected to be incorrect:
pt-table-sync --execute --sync-to-master h=master2,D=db,t=tbl

# Note that in the master-master configuration, the following will NOT do what you want, because it will make changes directly on master2, which will then flow through replication and change master1’s data:
#! Don't do this in a master-master setup!
pt-table-sync --execute h=master1,D=db,t=tbl master2

# 有主键或者唯一键,在主库进行 replace into 的操作
pt-table-sync --execute h=192.168.3.26,u=root,p=zhujie1986,D=working,t=department,P=3306 --sync-to-master --verbose --verbose --charset=utf8 --print

# 没主键或唯一键,直接在备库操作,要有超级用户权限
pt-table-sync --execute h=192.168.3.25,u=root,p=zhujie1986,D=working,t=department,P=3306 h=192.168.3.26 --no-check-slave --verbose --verbose --charset=utf8 --print

风险

FBI WARNING: pt-table-sync changes data! Before using this tool, please:

Read the tool’s documentation
Review the tool’s known “BUGS”
Test the tool on a non-production server
Backup your production server and verify the backups
pt-table-sync is mature, proven in the real world, and well tested, but if used improperly it can have adverse consequences. Always test syncing first with --dry-run and --print.

功能点

  • 使用单向和双向同步数据
  • 并不会同步表结构、索引或者其他对象
  • 针对单向数据同步
    • --replicate的目的
    • 找出不同
    • 匹配主库
      if DSN has a t part, sync only that table:
         if 1 DSN:
            if --sync-to-master:
               The DSN is a slave.  Connect to its master and sync.
         if more than 1 DSN:
            The first DSN is the source.  Sync each DSN in turn.
      else if --replicate:
         if --sync-to-master:
            The DSN is a slave.  Connect to its master, find records
            of differences, and fix.
         else:
            The DSN is the master.  Find slaves and connect to each,
            find records of differences, and fix.
      else:
         if only 1 DSN and --sync-to-master:
            The DSN is a slave.  Connect to its master, find tables and
            filter with --databases etc, and sync each table to the master.
         else:
            find tables, filtering with --databases etc, and sync each
            DSN to the first.
  1. pt-table-sync默认不使用 --replicate参数,程序内部找出表数据的差异并修复差异
  2. 如果启用,pt-table-sync会读取 pt-table-checksum已经验证出的差异信息
  3. 必须指定需要同步的数据库信息:
    • --sync-to-master,后面跟备库的信息;程序运行过程中自动发现并连接主库
    • 检测到差异,在主库上做修改;通过复制,同步到备库
    • 如果是一主多重的环境,那么所有备库都会同步更新
    • 如果不指定 --sync-to-master,那么必须指定至少两个 DSN配置,最前一个作为主库,后一个作为备库
    • 如果配置为主库的信息实际上是备库,那么进程将停止运行,因为备库不可写;
  4. 如果使用了 --replicate但是没有使用 --sync-to-master,那么只需要一个主库的DSN配置;程序会自动发现所有的备库,并且同时修复差异的数据表
  5. 以 DSN的形式配置的第一个数据库,其后的 DSN配置会使用第一个的参数资源,比如
pt-table-sync --execute h=host1,u=msandbox,p=msandbox h=host2

host2 将会使用 host1的 u,p参数连接数据库

限制

Replicas using row-based replication

pt-table-sync requires statement-based replication when used with the --sync-to-master or --replicate option. Therefore it will set binlog_format=STATEMENT on the master for its session if required. To do this user must have SUPER privilege.

输出 --verbose --print --charset=utf8

pt-table-checksum --nocheck-binlog-format --nocheck-replication-filters --replicate=percona.checksums --set-vars innodb_lock_wait_timeout=50 --host=192.168.3.25 --port=3306 --user=root --password=zhujie1986 --databases working --tables department --replicate-check
            TS ERRORS  DIFFS     ROWS  CHUNKS SKIPPED    TIME TABLE
01-18T14:58:11      0      1        7       1       0   0.009 working.department

pt-table-sync --execute h=192.168.3.25,u=root,p=zhujie1986,D=working,t=department,P=3306 h=192.168.3.26 --no-check-slave --verbose --charset=utf8
# Syncing A=utf8,D=working,P=3306,h=192.168.3.26,p=...,t=department,u=root
# DELETE REPLACE INSERT UPDATE ALGORITHM START    END      EXIT DATABASE.TABLE
#      0       0      7      0 GroupBy   14:59:28 14:59:28 2    working.department

同步处理流程

  • 在主备表结构相同,且存在唯一索引或主键的情况下,优先使用 INSERT UPDATE DELETE 操作数据,解决数据差异问题
  • 在主备表结构不同,但是主库表存在主键,备库表存在唯一索引的情况下,将会使用 DELETE REPLACE 修复数据

可选参数

- --verbose:输出差异数据处理信息,--verbose --verbose 输出块信息
- --print:输出处理 SQL语句
- --charset=utf8:设置编码,主要针对插入
- --no-check-slave:直接在备库插入,需要超级用户权限

算法

  • 使用不同的算法来验证数据差异
  • 根据索引、字段类型以及 --algorithms参数指定的值来选择最优的算法
  • Chunk
    • 第一个字段是数字类型(date/time)的索引,并根据 --chunk-size的值设置 chunk大小和个数
    • 每次验证一个块,整个块作为一个整体算出一个值
    • 如果取得的块值不相同,那么单独验证这个块的数据
    • 每个块相对来说都是很小的,小号的系统资源、带宽等可以忽略不计
    • 验证块数据的时候,只有主键和算法值会通过网络传输,一边验证
    • 验证结果有差异,才会传输整个块的行记录
时间: 2024-10-03 22:12:22

利用pt-table-sync 解决主备数据不一致的问题的相关文章

主备不一致:Table definition on master and slave does not match

昨天一同事在线上做变更,为了保证主库的稳定性,先在备库把binlog关闭,然后在进行DDL变更,在通过切换HA,把备库切换为主库,在老的主库上做DDL变更 看上去这样做法没有太大的问题,但是当备库变更一做完,HA切换到备库,开始老主库变更的时候,备库就出现复制出现错误: Last_Error: Table definition on master and slave does not match: Column 10 type mismatch – received type 3, dbname

mysql 主备复制下的可靠性漫谈(三)

引言:    前面两期主要针对各种故障条件下,对数据可靠性带来的挑战及普通应对策略.本文主要针对在主备非强同步复制模式下,能否保证数据可靠性来讨论. 复制模式概述:    异步模式:主库收到commit 请求后,依次执行:写redo log prepare,写入binlog,写redo log commit,返回客户端成功.         半同步模式:主库收到commit 后,依次执行 redo log prepare,写binlog/发往备库(两个步骤并行),等待备库回复收到ack,redo

简单的主备切换方案

主备切换是很多高可用性系统都必须解决的问题,方法有很多,象基于ZooKeeper的主备切换就是一个很好的选择. 在这里提供一种更简单但不完美的主备切换方法: 1) 假设A和B是集群中的主控(Master)节点 2) 1~7是工作节点(如HDFS中的DataNode) 3) 在每个工作节点上,都同时配置了A和B的IP,而且是对等的,无主备之分 所谓主:是指提供服务的主控,而备是指不提供服务的主控,当主故障时,由备接管其它服务,但因网络原因,可能主和备都未故障,这个是解决主备切换的关键问题所在. 选

MySQL · 捉虫动态 · ALTER IGNORE TABLE导致主备不一致

背景 我们知道当一张表的某个字段存在重复值时,这个字段没办法直接加UNIQUE KEY,但是MySQL提供了一个 ALTER IGNORE TABLE的方式,可以忽略修改表结构过程中出现的错误,但是要忽略UNIQUE重复值,就需要打开old_alter_table,也就是拷贝表的方式来ALTER TABLE. 例如这样: CREATE TABLE t1(c1 int) ENGINE = InnoDB; INSERT INTO t1 VALUES (1), (1); SET old_alter_t

利用Repeater控件显示主-从关系数据表

NestedRepeater.aspx NestedRepeater.aspx.csusing System;using System.Data;using System.Data.SqlClient;using System.Web;using System.Web.SessionState;using System.Web.UI;using System.Web.UI.WebControls;namespace eMeng{/// /// NestedRepeater 的摘要说明./// 本

利用XMLHTTP无刷新自动实时更新数据.

xml|数据|刷新|无刷新 前些时间写了几篇关于XMLHTTP运用的实例. (可以到http://dev.csdn.net/user/wanghr100看之前的几编关于XMLHTTP的介绍.) 近来看论坛上经常有人提问关于如何无刷新,自动更新数据. 传统上,我们浏览网页,如果加入最新的数据.只能是等我们重新向服务器端请求时才能显示出来. 但是,对于一些时效性很强的网站.传统的这种做法是不能满足的. 我们可以让程序自动刷新.定时向服务器请求数据.5秒取一次数据,10秒取一次数据. 利用XMLHTT

SQL Server利用HashKey计算列解决宽字段查询的性能问题

SQL Server利用HashKey计算列解决宽字段查询的性能问题 主人翁        本文主人翁:MSSQL菜鸟和MSSQL老鸟. 问题提出        某年某月某日,某MSSQL菜鸟满脸愁容的跑到老鸟跟前,心灰意懒的对老鸟说"我最近遇到一个问题,很大的问题,对,非常大的问题".老鸟不急不慢的推了推2000度超级近视眼镜框,慢吞吞的说:"说来听听".        "我有一个100万数据量的表,有一个宽度为7500字段,不幸的是现在我需要根据这个字

MySQL主备复制原理、实现及异常处理

复制概述 MySQL支持三种复制方式:基于行(Row)的复制.基于语句(Statement)的复制和混合类型(Mixed)的复制. 基于语句的复制早在3.23版本中就存在,而基于行的复制方式在5.1版本中才被加进来.这两种方式都是通过在主库上记录二进制日志.在备库重放日志的方式来实现异步的数据复制. 混合类型的复制:默认采用基于语句的复制,一旦发现基于语句的无法精确的复制时,就会采用基于行的复制. 复制通常不会增加主库的开销,主要是启用二进制日志带来的开销,但出于备份或及时从崩溃中恢复的目的,这

云服务器 ECS 配置:利用MySQL读写分离,提升应用数据吞吐性能

利用MySQL读写分离,提升应用数据吞吐性能 背景 一般情况下,对数据库的读和写都在同一个数据库服务器中操作时,业务系统性能会降低.为了提升业务系统性能,优化用户体验,可以通过读写分离来减轻主数据库的负载.本篇文章分别从应用层和系统层来介绍读写分离的实现方法. 应用层实现方法: 应用层中直接使用代码实现,在进入Service之前,使用AOP来做出判断,是使用写库还是读库,判断依据可以根据方法名判断,比如说以query.find.get等开头的就走读库,其他的走写库. 优点: 1.多数据源切换方便