您的位置：首页 > 数据库 > MariaDB

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

2018-07-19 17:53 585 查看

记一次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的一致性快照备份。所以我打算自己实验一下。

实验:

实验环境:
- slave: 172.16.3.7
- sysbench_host: 172.16.3.15

安装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

查看是否支持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 ***************************
......

搭建主从

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;

sysbench压测(sysbench_host上面运行)
```
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
```

实验结果

......
......
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进行校验同步。

内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理

标签： tokudb 1062 一致性快照备份

相关文章推荐

新的分享

章节导航