【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的备份工具
    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进行校验同步。

原文地址:http://blog.51cto.com/11819159/2147347

时间: 2024-07-29 01:41:11

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

使用mybatis注解@Options实现添加记录时返回主键值

官网:http://www.mybatis.org/mybatis-3/index.html 在使用mybatis作为ORM框架时,我通常更喜欢使用注解而非xml配置文件的方式.业务场景:添加记录之后需要返回自己自增长的主键字段值.通常,我们会将DAO层写成如下代码(以添加员工Staff为例): public interface StaffDAO { @InsertProvider(type=StaffProvider.class, method="buildSinleStaff")

Mariadb主从复制,半同步复制,主主复制

文章内容概览 主从复制介绍 主从复制的作用 复制工作流程 复制时应该注意的问题 主从复制配置 半同步复制配置 复制过滤器方法说明和配置 双主(主主复制)配置 文章环境说明 操作系统: [[email protected] ~]# cat/etc/redhat-release CentOS release 6.6 (Final) [[email protected] ~]# uname -r 2.6.32-504.el6.x86_64 [[email protected] ~]# uname -m

L11 MariaDB主从复制(异步,半同步)

   MariaDB主从复制(异步,半同步)   复制简单架构: 复制原理图: 异步与半同步说明: 1.半同步复制       在说明半同步复制之前我们先来了解一下,什么是同步复制?同步复制:同步复制可以定义为数据在同一时刻被提交到一台或多台机器,通常这是通过众所周知的"两阶段提交"做到的.虽然这确实给你在多系统中保持一致性,但也由于增加了额外的消息交换而造成性能下降.使用MyISAM或者InnoDB存储引擎的MySQL本身并不支持同步复制,然而有些技术,例如分布式复制块设备(简称DR

mysql/mariadb主从复制架构配置及过程中出现的问题

两台CentOS7系虚拟主机:分别是:主服务器172.16.75.1,从服务器172.16.75.2使用的是mariadb-5.5.56,即centOS自带的软件版本为了使实验结果显示精准,此处关闭两台服务器的防火墙和SELinux:[[email protected] ~]# setenforce 0[[email protected] ~]# iptables -F 一.首先在主服务器172.16.75.1上配置:在/etc/my.cnf中配置如下:[mysqld]###定义二进制日志的存放

Centos7 mariadb 主从复制

一.mysql基本命令 1.启动mysql systemctl start mariadb 2.linux客户端连接自己 mysql -uroot -p -h 127.0.0.1 3.远程链接mysql服务端 mysql -uroot -p -h 192.168.1.209 远程授权(允许208连接209的数据库): grant all privileges on *.* to root@"192.168.1.208" identified by "123"; fl

centos7上mariadb主从复制

1 mariadb基本命令1.启动mysqlsystemctl start mariadb 2.linux客户端连接自己mysql -uroot -p -h 127.0.0.1 3.远程链接mysql服务端mysql -uroot -p -h 192.168.1.197远程授权:grant all privileges on . to [email protected]"192.168.1.100" identified by "redhat";flush priv

MariaDB 10之TokuDB存储引擎

TokuDB存储引擎,你可以把它看做是ARCHIVE存储引擎的升级版,它拥有了密集压缩,并且支持事务. 压缩比: Engine Compression Table size [MB] InnoDB  none  2272 InnoDB  KEY_BLOCK_SIZE=8  1144 InnoDB  KEY_BLOCK_SIZE=4  584 MyISAM  none  1810 MyISAM  compressed with myisampack  809 Archive  default  2

基于SSL的mysql(MariaDB)主从复制

一.前言 备份数据库是生产环境中的首要任务,重中之重,有时候不得不通过网络进行数据库的复制,这样就需要保证数据在网络传输过程中的安全性,因此使用基于SSL的复制会大加强数据的安全性 二.准备工作 1.主从服务器时间同步 [[email protected] ~]# crontab -e */30 * * * * /usr/sbin/ntpdate 172.16.0.1 &>/dev/null 2.mysql说明 (1)主服务器 hostname:master    IP:172.16.7.2

MariaDB 主从复制

MySQL Replication:NySQL复制,MySQL的复制默认为异步工作模式    mysql的复制功能是mysql内置的,装上它之后就具备了这个功能,而mysql复制是mysql实现大规模高性能应用的一个基本工具,是 mysql完成水平扩展的基本架构,为了能够应付更多的访问请求,通常情况下我们需要对服务器进行扩展,而扩展通常有两种方式:向上扩展和向外扩展:向上扩展:scale on,也称为垂直扩展,一般是扩充服务器的内存或CPU颗数的这种就是向上扩展.向外扩展:scale out,也