【20180719】记录一次MariaDB主从复制因为tokudb出现主键1062错误问题

记一次MariaDB主从复制的搭建

环境:

• 系统: CentOS release 6.3
• 内核: 2.6.32-431.23.3.el6.centos.plus.x86_64
• 数据库版本:
  • master: 10.1.16-MariaDB MariaDB Server
  • slave: 10.1.34-MariaDB MariaDB Server

问题描述:

• 使用mysqldump备份工具在master上面进行全备，而后根据备份获取获得的binlog file和position搭建主从环境，可是在start slave以后报错，出现1062错误。

• mysqldump备份命令:

  mysqldump -S/var/lib/mysql/mysql.sock  -uroot -p --single-transaction --master-data=2 zst > 20180719_zst.sql

• 刚刚开始的时候觉得是极少部分数据或者说由于slave上面有进行write致使出现1062主键冲突的错误，而后直接在slave上面根据报错的主键进行删除行，而后再进行start slave,可是发现发现这样的数据有不少，而后直接查询致使这样的缘由。

猜测:

• 由于线上的数据是innodb和tokudb引擎混合使用，因此我怀疑是tokudb引擎不支持快照备份，可是mysqldump只有支持MVCC的数据库引擎才支持快照备份，tokudb引擎是支持MVCC和事务的。最后我询问了一下其余人员获得tokudb引擎不支持mysqldump的一致性快照备份。因此我打算本身实验一下。

实验:

1. 实验环境:

   • master: 172.16.3.5
   • slave: 172.16.3.7
   • sysbench_host: 172.16.3.15

2. 安装MariaDB(master和slave都需安装)

   shell> wget https://downloads.mariadb.com/MariaDB/mariadb-10.1.34/yum/rhel/mariadb-10.1.34-rhel-6-x86_64-rpms.tar
   shell> tar -xf mariadb-10.1.34-rhel-6-x86_64-rpms.tar
   shell> cat sys/kernel/mm/transparent_hugepage/enabled ##须要关闭大页传输
   always madvise [never] ## 是never是正确的
   shell> echo never > /sys/kernel/mm/transparent_hugepage/enabled
   shell> echo never > /sys/kernel/mm/transparent_hugepage/defrag
   shell> cd mariadb-10.1.34-rhel-6-x86_64-rpms
   shell> ./setup_repository
   shell> yum install Mariadb-Server

3. 查看是否支持TokuDB

   ......
   *************************** 5. row ***************************
     Engine: TokuDB
    Support: DEFAULT
    Comment: Percona TokuDB Storage Engine with Fractal Tree(tm) Technology
   Transactions: YES
         XA: YES
   Savepoints: YES
   *************************** 6. row ***************************
   ......

4. 搭建主从

   mysql> change master to
   -> master_host='172.16.3.5',
   -> master_user='rpl',
   -> master_password='new_password',
   -> master_port=3306,
   -> master_log_file='mysql-bin.000010',
   -> master_log_pos=258482739;

5. sysbench压测(sysbench_host上面运行)

   • 验证思路: 由于个人目的是为了验证tokudb不支持快照备份，因此我首先我只须要不停往数据库里面写数据，而且保证我在备份的期间还有数据写入。因此尽量的将table size的值弄大些，这样子的话那么写数据的时间比较长，在写入数据的时候在master上面进行mysqldump的一致性快照备份，将获取获得的数据导入slave中，而且根据备份文件中的binlog file和position搭建主从，假如在start slave的时候没有出现1062主键冲突的状况，那么说明tokudb是支持一致性快照备份的，假如出现了1062错误(不是说只有一条，而是多条，具体的验证能够设置sql_slave_skip_counter设置空事务，能够看到须要跳过不少的空事务;或者说上诉说的删除slave上面主键冲突的row，start slave。由于是为了实验因此没有开启GTID。)

   sysbench oltp_insert.lua --threads=10 --report-interval=5 --db-driver=mysql --mysql-host=172.16.3.5 --mysql-port=3306 --mysql-user=root --mysql-password='new_password' --mysql-db=zst --mysql_storage_engine=tokudb --tables=10 --table_size=2000000 prepare

6. 实验结果

   ......
   ......
   Last_SQL_Errno: 1062
              Last_SQL_Error: Could not
   execute Write_rows event on table zst.sbtest1; Duplicate entry '8' for key
   'PRIMARY', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's
   master log mysql-bin.000005, end_log_pos 2678
   ......
   ......

总结

• 能够很明确的清楚tokudb引擎不支持事务的一致性快照。

• tokudb的备份工具

  • 使用 Percona 版本的 mysqldump 能够备份 tokuDB 的数据，而且额外提供了一个参数 lock-for-backup 来保证数据一致性。(https://www.percona.com/doc/percona-server/LATEST/management/backup_locks.html#mysqldump)

  mysqldump has also been extended with a new option, lock-for-backup (disabled by default). When used together with the --single-transaction option, the option makes mysqldump issue LOCK TABLES FOR BACKUP before starting the dump operation to prevent unsafe statements that would normally result in an inconsistent backup.
  When used without the single-transaction option, lock-for-backup is automatically converted to lock-all-tables.
  Option lock-for-backup is mutually exclusive with lock-all-tables, i.e. specifying both on the command line will lead to an error.
  If the backup locks feature is not supported by the target server, but lock-for-backup is specified on the command line, mysqldump aborts with an error.

  • 物理备份工具，也是编译过的xtrabackup

  https://github.com/XeLabs/tokudb-xtrabackup

  • 在使用tokudb备份的时候建议最好使用物理备份，由于在tokudb是一个压缩引擎，线上使用innodb和tokudb混合引擎物理磁盘使用了33G,可是使用mysqldump备份出来有88G的数据，因此说一个磁盘和一个效率问题并不推荐使用逻辑备份tokudb，尽可能仍是使用物理备份。

问题解决

• 虽然是验证了tokudb不支持mysqldump的一致性快照备份，可是实际问题仍是没有解决。
• 最后仍是设置slave_skip_errors的值为1062而后重启slave，一段时间等以后(等主键冲突的数据所有同步过去)在关掉这个参数，而后再重启slave。最后实验percona的工具集pt-table-cheksum和pt-table-sync进行校验同步。