产品中心
如果有多个从库需要检查，需将 –check-slave-lag 指定多次，每次对应一个从库。
–analyze
在执行完归档操作后，执行 ANALYZE TABLE 操作。
后面可接任意字符串，如果字符串中含有 s ，则会在源库执行 ANALYZE 操作。
如果字符串中含有 d ，则会在目标库执行 ANALYZE 操作。
如果同时带有 d 和 s ，则源库和目标库都会执行 ANALYZE 操作。如，
–optimize
在执行完归档操作后，执行 OPTIMIZE TABLE 操作。
用法同 –analyze 类似。
–charset
指定连接（Connection）字符集。
在 MySQL 8.0 之前，默认是 latin1。
在 MySQL 8.0 中，默认是 utf8mb4 。
注意，这里的默认值与 MySQL 服务端字符集 character_set_server 无关。
若显式设置了该值，pt-archiver 在建立连接后，会首先执行 SET NAMES 'charset_name' 操作。
–[no]check-charset
检查源库（目标库）连接（Connection）字符集和表的字符集是否一致。
如果不一致，会提示以下错误：
这个时候，切记不要按照提示指定 –no-check-charset 忽略检查，否则很容易导致乱码。
针对上述报错，可将 –charset 指定为表的字符集。
注意，该选项并不是比较源库和目标库的字符集是否一致。
–[no]check-columns
检查源表和目标表列名是否一致。
注意，只会检查列名，不会检查列的顺序、列的数据类型是否一致。
–columns
归档指定列。
在有自增列的情况下，如果源表和目标表的自增列存在交集，可不归档自增列，这个时候，就需要使用 –columns 显式指定归档列。
–dry-run
只打印待执行的 SQL，不实际执行。
常用于实际操作之前，校验待执行的 SQL 是否符合自己的预期。
–ignore
使用 INSERT IGNORE 归档数据。
–no-delete
不删除源库的数据。
–replace
使用 REPLACE 操作归档数据。
–[no]safe-auto-increment
在归档有自增主键的表时，默认不会删除自增主键最大的那一行。
这样做，主要是为了规避 MySQL 8.0 之前自增主键不能持久化的问题。
在对全表进行归档时，这一点需要注意。
如果需要删除，需指定 –no-safe-auto-increment 。
–source
给出源端实例的信息。
除了常用的选项，其还支持如下选项：
a：指定连接的默认数据库。
b：设置 SQL_LOG_BIN=0 。
如果是在源库指定，则 DELETE 操作不会写入到 Binlog 中。
如果是在目标库指定，则 INSERT 操作不会写入到 Binlog 中。
i：设置归档操作使用的索引，默认是主键。
–progress
显示进度信息，单位行数。
如 –progress 10000，则每归档（删除）10000 行，就打印一次进度信息。
第一列是当前时间，第二列是已经消耗的时间，第三列是已归档（删除）的行数。
前面，我们对比了归档操作中不同参数的执行时间。
其中，–bulk-delete –limit 1000 –commit-each –bulk-insert 是最快的。不指定任何批量操作参数是最慢的。
但在使用 –bulk-insert 时要注意 ，如果导入的过程中出现问题，pt-archiver 是不会提示任何错误的。
常见的错误有主键冲突，数据和目标列的数据类型不一致。
如果不使用 –bulk-insert，而是通过默认的 INSERT 操作来归档，大部分错误是可以识别出来的。
譬如，主键冲突，会提示以下错误。
如果待归档的实例中有 MySQL 5.6 ，我们其实很难将归档实例的 SQL_MODE 开启为严格模式。
因为 MySQL 5.6 的 SQL_MODE 默认为非严格模式，所以难免会产生很多无效数据，譬如时间字段中的 0000-00-00 00:00:00 。
这种无效数据，如果插入到开启了严格模式的归档实例中，会直接报错。
从数据安全的角度出发，最推荐的归档方式是：
其中，第一步和第三步可通过 pt-archiver 搞定，第二步可通过 pt-table-sync 搞定。
相对于边归档边删除的这种方式，虽然麻烦不少，但相对来说，更安全。
到此这篇关于MySQL 中如何归档数据的实现方法的文章就介绍到这了,更多相关MySQL 归档数据内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！
