Mysql主从不一致校验

方案

MySQL主从数据不一致的主动发现机制通常依赖于主从复制过程中提供的工具和方法，而非自动的主动检测机制。以下是常见的发现和监控方法：

1. Replication监控工具：MySQL提供了多种监控复制状态的工具，如SHOW SLAVE STATUS命令。通过监控Seconds_Behind_Master等关键指标，可以检测主从延迟，但这只能提示延迟问题，无法直接发现数据不一致。
2. Percona Toolkit：pt-table-checksum是Percona Toolkit中的一个工具，可以主动检查主从数据库的表数据是否一致。它会在主数据库上运行，并在从数据库上执行相同的校验，以发现不一致之处。
3. GTID和Binlog监控：如果启用了全局事务标识符（GTID）或二进制日志（Binlog），可以通过监控这些日志的应用情况，发现潜在的不一致。但这更多是间接检测。
4. 数据校验：定期运行数据校验脚本，对关键表的行数或数据校验和进行对比，发现不一致。

虽然这些工具和方法可以帮助发现主从不一致问题，但MySQL自身没有内置的、自动的主动发现机制。通常需要借助外部工具或脚本进行监控和检测。

pt-table-checksum

pt-table-checksum是Percona Toolkit中的一个工具，用于检测MySQL主从复制中的数据不一致问题。它通过在主库上生成数据校验和，并利用MySQL复制机制将这些校验和传播到从库，然后在从库上进行对比，以检测主从数据是否一致。下面是其详细工作原理：

1. 检查前的准备

pt-table-checksum在运行时需要有以下条件：

• 复制配置：MySQL必须配置了主从复制，且复制正常工作。
• 权限：运行该工具的用户需要在主库和从库上有足够的权限（如读写权限）。

2. 校验和计算的执行

• 分块处理：pt-table-checksum对大表进行了分块处理（默认按主键范围分块），以避免锁表和性能问题。每块数据的大小可以配置。
• 校验和生成：在主库上，对每个分块生成一个校验和。校验和是基于MySQL的CRC32或其他散列函数计算的，它结合了块中所有行的值。

计算方式类似于：

SELECT
  BIT_XOR(CAST(CRC32(CONCAT_WS('#', col1, col2, col3, ...)) AS UNSIGNED))
FROM
  table
WHERE
  (primary_key_column BETWEEN X AND Y);

3. 校验和结果的传播

• 记录到主库：校验和结果与相关的分块信息（表名、块范围等）被插入到主库的percona.checksums表中。
• 复制到从库：由于主从复制，主库中的percona.checksums表的数据会被自动复制到从库中。

4. 从库校验和对比

• 从库对比：工具连接到从库，读取percona.checksums表的数据，并与主库的对应校验和进行对比。如果某块的校验和在主从之间不同，则表示数据不一致。

对比方式类似于：

SELECT 
  master_crc, slave_crc 
FROM 
  percona.checksums 
WHERE 
  master_crc != slave_crc;

5. 报告和输出

• 不一致报告：pt-table-checksum会输出所有不一致的分块信息，包括主键范围、表名、以及不一致的行数等详细信息。
• 日志与警告：工具支持将结果记录到日志文件或标准输出，并可以根据不一致的严重程度发出警告。

6. 锁定与性能考虑

• 最小化锁定：为减少对生产环境的影响，pt-table-checksum使用短期的LOCK IN SHARE MODE来避免写锁。同时，可以通过选项控制锁定行为，如减少表锁定时间。
• 负载控制：工具允许配置负载检测参数，确保在数据库负载高时暂停校验，避免影响正常业务。

关键点总结

• 依赖主从复制：pt-table-checksum依赖于MySQL的复制机制，因此只能检测到复制层面的问题，而无法发现复制日志丢失或数据直接修改导致的不一致。
• 数据一致性保证：工具可以通过设置--replicate-check-only等选项，确保只检测而不修改数据，也可以与pt-table-sync结合使用来修复不一致的数据。

通过这种方式，pt-table-checksum可以在不直接访问从库数据的情况下，有效地检测并报告主从数据不一致问题，为数据库管理员提供了强大的维护工具。