【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進行校驗同步。