【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進行校驗同步。
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章