MariaDB基于GTID的主从复制

2017-05-15  本文已影响481人  yuanzicheng

环境:MariaDB 10.1.23

MySQL复制有两种方式:基于日志点的复制、基于GTID的复制,两种方式都依赖于MySQL二进制日志。

# 二进制日志格式
binlog-format=STATEMENT|ROW|MIXED
# ROW格式下日志的级别
binlog-row-image=full|minimal|noblob

基于GTID的复制

基于GTID的复制是MySQL5.6后的一种新的复制方式。

From MariaDB 10.0.2, global transaction ID is enabled automatically.

MariaDB从10.0.2开始默认开启GTID

GTID即全局事务ID,其保证了每个在Master上提交的事务在复制集群中可以生成一个唯一的ID。

GTID由3段组成,domain ID-server ID-sequence number

配置基于GTID复制的详细步骤:

**1. 在主DB上建立复制账号 **

MariaDB [(none)]> create user 'repl'@'192.168.1.%' identified by '123456';
Query OK, 0 rows affected (0.00 sec)

2. 授予复制权限

MariaDB [(none)]> grant replication slave on *.* to 'repl'@'192.168.1.%';
Query OK, 0 rows affected (0.00 sec)

3. 主服务器参数配置

# ************主服务器*************
[mysqld]
# 服务器id
server-id = 1000
# 二进制日志文件格式
binlog-format=ROW
# ROW格式下日志的级别
binlog-row-image=minimal
# 此两项为打开从服务器崩溃二进制日志功能,信息记录在事物表而不是保存在文件
master-info-repository=TABLE
relay-log-info-repository=TABLE
# 二进制日志,后面指定存放位置。如果只是指定名字,默认存放在/var/lib/mysql下
log-bin = mariadb-bin

4.从服务器参数配置

# ************从服务器*************
# 服务器id(在集群中需要唯一)
server_id = 1001
# binlog日志文件(如果只有文件名,则保存在/usr/lib/mysql目录)
relay_log = /usr/local/mysql/log/mysql-relay-bin
# 开启gtid模式(需要同时下面两个)
gtid_mode = on
# 强制gtid一致性
enforce-grid-consistency
# 从服务器中记录binlog日志
log-slave-updates = on
read_only = on (建议)
master_info_repository = TABLE(建议)
relay_log_info_repository = TABLE(建议)

5. 初始化数据:备份主DB、还原到从DB

这里需要注意下,第1、2步在主DB创建用于复制的账号,这里我们备份、还原所有的库,所以会将用户也还原到从DB。

# 使用mysqldump备份数据
mysqldump --master-data=2 --single-transaction --routines --all-databases -uroot -p >> dump.sql;
# 或使用xtrabackup
xtrabackup --slave-info ...
# 还原
mysql -uroot -p < all.sql

6. 启动基于GTID的复制

# 在备份文件dump.sql中显示了GTID值,也可以在主库中查看变量
set global gtid_slave_pos='0-1000-2';
change master to master_host = '主服务器IP',master_user = 'repl',master_password = '123456',master_use_gtid = slave_pos;
# 启动主从复制
start slave;

7. 检查主从复制状态

MariaDB [(none)]> show slave status\G show processlist;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.1.104
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mariadb-bin.000002
          Read_Master_Log_Pos: 993
               Relay_Log_File: mariadb-relay-bin.000002
                Relay_Log_Pos: 644
        Relay_Master_Log_File: mariadb-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: 993
              Relay_Log_Space: 944
              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: 0
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: 1000
               Master_SSL_Crl:
           Master_SSL_Crlpath:
                   Using_Gtid: Slave_Pos
                  Gtid_IO_Pos: 0-1000-4
      Replicate_Do_Domain_Ids:
  Replicate_Ignore_Domain_Ids:
                Parallel_Mode: conservative
1 row in set (0.00 sec)

+----+-------------+-----------+------+---------+------+-----------------------------------------------------------------------------+------------------+----------+
| Id | User        | Host      | db   | Command | Time | State                                                                       | Info             | Progress |
+----+-------------+-----------+------+---------+------+-----------------------------------------------------------------------------+------------------+----------+
| 13 | system user |           | NULL | Connect | 4858 | Waiting for master to send event                                            | NULL             |    0.000 |
| 14 | system user |           | NULL | Connect | 4858 | Slave has read all relay log; waiting for the slave I/O thread to update it | NULL             |    0.000 |
| 15 | root        | localhost | NULL | Query   |    0 | init                                                                        | show processlist |    0.000 |
+----+-------------+-----------+------+---------+------+-----------------------------------------------------------------------------+------------------+----------+
3 rows in set (0.00 sec)

优点:
方便故障转移;从库不会丢失主库上的任何修改。
缺点:
故障处理比较复杂;对执行的SQL有一定的限制。

主从复制无法解决的问题

无法分担写负载,但可以分担读负载;
无法实现自动故障转移和主从切换,但提供了高可用架构基础;
不提供读写分离功能。

GTID相关命令

# 查看master当前GTID值
select @@global.gtid_current_pos;
# 查看slave当前GTID值
select @@global.gtid_slave_pos;
# 从库采用gtid的复制
change master to master_use_gtid = { slave_pos | current_pos | no }

参考:https://segmentfault.com/a/1190000000598062

上一篇下一篇

猜你喜欢

热点阅读