首頁 > 資料庫 > mysql教程 > MySQL主從複製實戰-基於GTID的複製程式碼分享

MySQL主從複製實戰-基於GTID的複製程式碼分享

黄舟
發布: 2017-03-17 13:39:08
原創
1322 人瀏覽過

本篇文章主要介紹了MySQL主從複製實戰 - 基於GTID的複製,基於GTID的複製是MySQL 5.6後新增的複製方式.有興趣的可以了解一下。

 基於GTID的複製

簡介

基於GTID的複製是MySQL 5.6後新增的複製方式.

GTID (global transaction identifier) 即全域事務ID, 保證了在每個在主庫上提交的事務在集群中有一個唯一的ID.

在原來基於日誌的複製中, 從庫需要告知主庫要從哪個偏移量進行增量同步, 如果指定錯誤會造成數據的遺漏, 從而造成數據的不一致.

而基於GTID的複製中, 從庫會告知主庫已經執行的事務的GTID的值, 然後主庫會將所有未執行的事務的GTID的列表返回給從庫. 並且可以保證同一個事務只在指定的從庫執行一次.

實戰

1、在主庫上建立複製帳戶並授予權限

##基於GTID的複製會自動地將沒有在從庫執行的事務重播, 所以不要在其他從庫上建立相同的帳號. 如果建立了相同的帳戶, 有可能造成複製鏈路的錯誤.

mysql> create user 'repl'@'172.%' identified by '123456';
登入後複製

注意在生產上的密碼必須按照相關規格以達到一定的密碼強度, 並且規定在從庫上的特定網段上才能存取主庫.

mysql> grant replication slave on *.* to 'repl'@'172.%';
登入後複製

查看用戶

mysql> select user, host from mysql.user;
+-----------+-----------+
| user  | host  |
+-----------+-----------+
| prontera | %   |
| root  | %   |
| mysql.sys | localhost |
| root  | localhost |
+-----------+-----------+
4 rows in set (0.00 sec)
登入後複製

查看授權

mysql> show grants for repl@'172.%';
+--------------------------------------------------+
| Grants for repl@172.%       |
+--------------------------------------------------+
| GRANT REPLICATION SLAVE ON *.* TO 'repl'@'172.%' |
+--------------------------------------------------+
1 row in set (0.00 sec)
登入後複製

#2、設定主庫伺服器

[mysqld]
log_bin = /var/log/mysql/mysql-bin
log_bin_index = /var/log/mysql/mysql-bin.index
binlog_format = row
server_id = 101
gtid_mode = ON
enforce_gtid_consistency = ON
#log_slave_updates = ON
登入後複製

NOTE: 把日誌與資料分開是個好習慣, 最好能放到不同的資料分割區


enforce_gtid_consistency 強制GTID一致性, 啟用後以下指令無法再使用

create table ... select ...

mysql> create table dept select * from departments;
ERROR 1786 (HY000): Statement violates GTID consistency: CREATE TABLE ... SELECT.
登入後複製

因為實際上是兩個獨立

事件, 所以只能將其拆分先建立表, 然後再把資料插入到表中

create temporary table
登入後複製

事務內部不能創建臨時表

mysql> begin;
Query OK, 0 rows affected (0.00 sec)

mysql> create temporary table dept(id int);
ERROR 1787 (HY000): Statement violates GTID consistency: 
CREATE TEMPORARY TABLE and DROP TEMPORARY TABLE can only be executed outside transactional context. 
These statements are also not allowed in a function or trigger because functions and triggers are also 
considered to be multi-statement transactions.
登入後複製

同一事務中

更新事務表與非事務表(MyISAM)

mysql> CREATE TABLE `dept_innodb` (id INT(11) UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT);
Query OK, 0 rows affected (0.04 sec)

mysql> CREATE TABLE `dept_myisam` (id INT(11) UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT) ENGINE = `MyISAM`;
Query OK, 0 rows affected (0.03 sec)

mysql> begin;
Query OK, 0 rows affected (0.00 sec)

mysql> insert into dept_innodb(id) value(1);
Query OK, 1 row affected (0.00 sec)

mysql> insert into dept_myisam(id) value(1);
ERROR 1785 (HY000): Statement violates GTID consistency: 
Updates to non-transactional tables can only be done in either autocommitted statements or 
single-statement transactions, and never in the same statement as updates to transactional tables.
登入後複製

所以建議選擇Innodb作為預設的資料庫引擎.

log_slave_updates 此選項在MySQL 5.6版本時基於GTID的複製是必須的,但其增加了從伺服器的IO負載, 而在MySQL 5.7中該選項已經不是必須項目

3、配置從庫伺服器

master_info_repository 與relay_log_info_repository

在MySQL 5.6.2之前, slave記錄的master資訊以及slave應用binlog的資訊存放在檔案中, 即master.info與relay-log.info. 在5.6.2版本之後, 允許記錄到table中. 對應的表分別為mysql.slave_master_info與mysql.slave_relay_log_info, 且這兩個表均為innodb引擎表.

[mysqld]
log_bin = /var/log/mysql/mysql-bin
log_bin_index = /var/log/mysql/mysql-bin.index
server_id = 102
# slaves
relay_log  = /var/log/mysql/relay-bin
relay_log_index = /var/log/mysql/relay-bin.index
relay_log_info_file = /var/log/mysql/relay-bin.info
enforce_gtid_consistency = ON
log_slave_updates = ON
read_only = ON
master_info_repository = TABLE
relay_log_info_repository = TABLE
登入後複製

#4、從庫資料初始化- [optional]

先在主庫備份資料

程式碼如下:

mysqldump --single-transaction --master-data=2 --triggers --routines --all-databases --events -u root -p > backup.sql
登入後複製

—master-data=2 此選項將目前伺服器的binlog的位置和檔案名稱追加到輸出文件中(show master status). 如果為1, 將偏移量拼接到CHANGE MASTER 指令. 如果為2, 輸出的偏移量資訊將會被註解。

--all-databases 因為基於GTID的複製會記錄全部的交易, 所以要建構一個完整的dump這個選項是推薦的

##常見錯誤

當從庫導入SQL的時候出現

 程式碼如下:

ERROR 1840 (HY000) at line 24: @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty.
登入後複製

此時進入從庫的MySQL Command Line, 使用reset master即可

#5、啟動基於GTID的複製

現有master@172.20.0.2和slave@172.20.0.3, 並且已經透過mysqldump將資料同步至從庫slave. 現在在從伺服器slave上設定複製連結

mysql> change master to master_host='master', master_user='repl', master_password='123456', master_auto_position=1;
Query OK, 0 rows affected, 2 warnings (0.06 sec)
登入後複製

啟動複製

mysql> start slave;
登入後複製

啟動成功後查看slave的

狀態

mysql> show slave status\G
*************************** 1. row ***************************
    Slave_IO_State: Queueing master event to the relay log
     Master_Host: master
     Master_User: repl
     Master_Port: 3306
    Connect_Retry: 60
    Master_Log_File: mysql-bin.000002
   Read_Master_Log_Pos: 12793692
    Relay_Log_File: relay-bin.000002
    Relay_Log_Pos: 1027
  Relay_Master_Log_File: mysql-bin.000002
    Slave_IO_Running: Yes
   Slave_SQL_Running: Yes
    Replicate_Do_DB:
   Replicate_Ignore_DB:
   Replicate_Do_Table:
  Replicate_Ignore_Table:
  Replicate_Wild_Do_Table:
 Replicate_Wild_Ignore_Table:
     Last_Errno: 0
     Last_Error:
     Skip_Counter: 0
   Exec_Master_Log_Pos: 814
    Relay_Log_Space: 12794106
    Until_Condition: None
    Until_Log_File:
    Until_Log_Pos: 0
   Master_SSL_Allowed: No
   Master_SSL_CA_File:
   Master_SSL_CA_Path:
    Master_SSL_Cert:
   Master_SSL_Cipher:
    Master_SSL_Key:
  Seconds_Behind_Master: 5096
Master_SSL_Verify_Server_Cert: No
    Last_IO_Errno: 0
    Last_IO_Error:
    Last_SQL_Errno: 0
    Last_SQL_Error:
 Replicate_Ignore_Server_Ids:
    Master_Server_Id: 101
     Master_UUID: a9fd4765-ec70-11e6-b543-0242ac140002
    Master_Info_File: mysql.slave_master_info
     SQL_Delay: 0
   SQL_Remaining_Delay: NULL
  Slave_SQL_Running_State: Reading event from the relay log
   Master_Retry_Count: 86400
     Master_Bind:
  Last_IO_Error_Timestamp:
  Last_SQL_Error_Timestamp:
    Master_SSL_Crl:
   Master_SSL_Crlpath:
   Retrieved_Gtid_Set: a9fd4765-ec70-11e6-b543-0242ac140002:1-39
   Executed_Gtid_Set: a9fd4765-ec70-11e6-b543-0242ac140002:1-4
    Auto_Position: 1
   Replicate_Rewrite_DB:
     Channel_Name:
   Master_TLS_Version:
1 row in set (0.00 sec)
當Slave_IO_Running, Slave_SQL_Running為YES,

當Slave_IO_Running, Slave_SQL_Running為YES,

#且Slave_SQL_Running_State 為Slave has read all relay log; waiting for more updates時表示成功建構複製連結

#6、總結

    6、總結
  1. #6、總結


  1. #因為不用手動設定日誌偏移量, 可以很方便地進行故障轉移

  2. 如果啟用log_slave_updates那麼從庫不會遺失主函式庫上的任何修改

#######缺點##################對執行的SQL有一定限制# ###########只支援MySQL 5.6之後的版本, 而且不建議使用早期5.6版本##########

以上是MySQL主從複製實戰-基於GTID的複製程式碼分享的詳細內容。更多資訊請關注PHP中文網其他相關文章!

來源:php.cn
本網站聲明
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn
熱門教學
更多>
最新下載
更多>
網站特效
網站源碼
網站素材
前端模板