Mysql 5.6 GTID-主从搭建

时间  2019-11-11
标签 mysql 5.6 gtid 主从 搭建 栏目 MySQL 繁體版
原文   原文链接

GTID做为mysql5.6带来的新特性，在搭建replicate过程当中，能够更快速方便，感受上更加‘自动化’。 #1、修改配置文件mysql

###1.修改主服务器配置文件my.cnf，添加下面的几行：linux

binlog-format=ROW
log-slave-updates=true
gtid-mode=on # GTID only
enforce-gtid-consistency=true # GTID only
master-info-repository=TABLE
relay-log-info-repository=TABLE
sync-master-info=1
slave-parallel-workers=2
binlog-checksum=CRC32
master-verify-checksum=1
slave-sql-verify-checksum=1
binlog-rows-query-log-events=1
server-id=1
report-port=3306
port=3306
log-bin=black-bin.log
report-host=black
innodb_flush_log_at_trx_commit=1
sync_binlog=1

###2.修改从服务器配置文件，添加下面几行：sql

binlog-format=ROW
log-slave-updates=true
gtid-mode=on # GTID only
enforce-gtid-consistency=true # GTID only
master-info-repository=TABLE
relay-log-info-repository=TABLE
sync-master-info=1
slave-parallel-workers=2
binlog-checksum=CRC32
master-verify-checksum=1
slave-sql-verify-checksum=1
binlog-rows-query-log-events=1
server-id=2
report-port=3307
port=3307
log-bin=blue-bin.log
report-host=blue
innodb_flush_log_at_trx_commit=1
sync_binlog=1

能够看到主与从的配置文件基本上是相同的，这样也便于在主服务器挂掉的时候，不用修改配置文件便可把从服务器提高为主。数据库

#2、在master上建立用户安全

mysql> create user 'rep'@'%' identified by 'rep';
mysql> grant replication slave on *.* to 'rep'@'%';

#3、 从master导出数据服务器

###1.master中设置全部表只读：网络

mysql> FLUSH TABLES WITH READ LOCK;

###2.用mysqldump导出所有数据：多线程

->/usr/local/mysql/bin/mysqldump -uroot -p -h192.168.1.10 -P3306 --all-databases --triggers --routines --events >all.sql 

###3.解锁表格：并发

mysql> UNLOCK TABLES;

###4.slave导入数据异步

-> mysql -uroot -p -h192.168.1.11 -P3307 < all.sql

###5.change master mysql > CHANGE MASTER TO MASTER_HOST='192.168.1.9', MASTER_PORT=3306, MASTER_USER='rep',MASTER_PASSWORD='rep', master_auto_position=1; mysql > SHOW warnings; +-------+------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Level | Code |Message | +-------+------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Note | 1759 | Sending passwords IN plain text WITHOUT SSL/TLS IS extremely insecure. | | Note | 1760 | Storing MySQL USER name OR password information IN the master.info repository IS NOT secure AND IS therefore NOT recommended. Please see the MySQL Manual FOR more about this issue AND possible alternatives. | +-------+------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ 2 ROWS IN SET (0.00 sec)

这里保存的是明文密码，存在密码泄露的风险。

mysql > SELECT * FROM mysql.slave_master_info \G； 
mysql > SELECT * FROM mysql.slave_relay_log_info \G；

mysql > START slave;
mysql  > SHOW warnings;
+-------+------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Level | Code | Message                                                                                                                                                               |
+-------+------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Note  | 1753 | slave_transaction_retries IS NOT supported IN multi-threaded slave mode. IN the event OF a transient failure, the slave will NOT retry the TRANSACTION AND will stop. |
+-------+------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 ROW IN SET (0.00 sec)

多线程模式掉线不重连。

从服务器上看一下状态：

mysql > SHOW slave STATUS \G;
*************************** 1. ROW ***************************
               Slave_IO_State: Waiting FOR master TO send event
                  Master_Host: 127.0.0.1
                  Master_User: rep
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: black-bin.000001
          Read_Master_Log_Pos: 1770
               Relay_Log_File: mysql_sandbox5611-relay-bin.000002
                Relay_Log_Pos: 1980
        Relay_Master_Log_File: black-bin.000001
             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: 1770
              Relay_Log_Space: 2196
              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: 1
                  Master_UUID: 05b47d41-7b10-11e2-9fff-00241db92e69
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has READ ALL relay log; waiting FOR the slave I/O thread TO UPDATE it
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: 05b47d41-7b10-11e2-9fff-00241db92e69:1-6
            Executed_Gtid_Set: 05b47d41-7b10-11e2-9fff-00241db92e69:1-6
                Auto_Position: 1
1 ROW IN SET (0.00 sec)

主服务器上面也能够看到一些信息：

mysql > SHOW master STATUS;
+------------------+----------+--------------+------------------+------------------------------------------+
| File             | POSITION | Binlog_Do_DB | Binlog_Ignore_DB |     Executed_Gtid_Set                        |
    +------------------+----------+--------------+------------------+------------------------------------------+
| black-bin.000001 |     1770 |              |                  | 05b47d41-7b10-11e2-9fff-00241db92e69:1-6 |
    +------------------+----------+--------------+------------------+------------------------------------------+
1 ROW IN SET (0.00 sec)


mysql  > SHOW slave hosts;
+-----------+------+------+-----------+--------------------------------------+
| Server_id | Host | Port | Master_id | Slave_UUID                           |
+-----------+------+------+-----------+--------------------------------------+
|         2 | blue | 3306 |         1 | 1d1e71e7-7b10-11e2-9fff-00241db92e69 |
+-----------+------+------+-----------+--------------------------------------+
1 ROW IN SET (0.00 sec)

  #4、配置文件参数含义：

###1.binlog-format：

采用了row-based，听说5.6对row-based replication作了优化。

###2.gtid-mode与enforce-gtid-consistency：

传统方式下，主从是基于master binary logfile 与 binary logfile postition的， 当主服务器挂掉，须要把某个从服务器提高为主的时候，须要作不少工做， 主要缘由仍是在于主从复制实际上是异步的， 致使多台从服务器间的数据不一致，有的同步速度快，有的速度慢, 颇有可能每一台从服务器上面的Read_Master_Log_Pos都是不一样的。 首先要根据Read_Master_Log_Pos来肯定每台从服务器缺乏binlog中的哪些transactions(events)，帮它们补充完以后， 从服务器间的数据彻底一致了，而后才能把任意一台从服务器提高为主。 这个过程，人工作起来实在是比较痛苦，还好有一些开源的第三方程序能够自动作到，好比MHA。为了从根本上解决这个问题，gtid(Global Transaction ID)就被开发了出来。mysql为每个transactions都生成了独一无二的ID，由二部分构成：
    1) mysql服务器的128bit的UUID
    2) 自增的一个int变量。 此服务器的第一个transaction的id就是1，第二个就是2…
好比： 22096C54-FE03-4B44-95E7-BD3C4400AF21:4711这样GTID就能够在全局范围内惟一标识一个transaction。GTID也会写入binary log，而后被传输到从服务器。有了GTID，主从复制也再也不基于master的binary logfile和logfile postition，从服务器链接到主服务器以后，把本身执行过的GTID(Executed_Gtid_Set) 曾经获取到的GTID(Retrieved_Gtid_Set)发给主服务器，主服务器把从服务器缺乏的GTID及对应的transactions发过去便可。当主服务器挂掉的时候，能够任意选择一台从服务器直接提高为主，而后其它从服务器链接到新的主服务器以后，首先把自已已经执行过的GTID发给新主服务器，新主根据这些GTID，判断本身缺乏哪些transactions，先把本身补全，而后再把从服务器缺乏的GTID及对应的transactions发给从服务器。另外，gtid与myisam的关系，也不是很明确。master-info-repository与relay-log-info-repository都设置为TABLE， 默认值是FILE, 好比master info就保存在master.info文件中，relay log info保存在relay-log.info文件中，若是服务器意外关闭，正确的relay info 没有来得及更新到 relay-log.info文件中，那就比较悲剧了。

###3.mysql.slave_master_info与 mysql.slave_relay_log_info：

这二个table都是innodb类型的， 天生就支持事务，比写文件靠谱多了。

###4.sync-master-info：

若是这个值大于0的话，复制中的slave机器就会在每次sync_master_info事件完成后同步它的master.info信息到对应的磁盘文件中。

###5.slave-parallel-workers：

5.6之前的从服务器，有一个io线程负责接收binary log，还有一个sql线程负责执行binary log中的sql语句。若是主服务器的数据更新至关频繁，而从服务器通常来讲硬件性能要低于主服务器，若是只有一个sql线程的话，万一某条语句执行速度过慢，就卡在这里了，会致使从服务器落后比较长的时间。采用多个sql线程，每一个sql线程处理不一样的database，提升了并发性能，即便某database的某条语句暂时卡住，也不会影响到后续对其它的database进行操做。
ps:若是只有一个database要同步，那么多个sql线程也没有什么意义。
ps2: show slave status里面的Exec_Master_Log_Pos，在多个sql线程的状况下，变为一个低水位线标识，并不是表示最近执行到的pos。
ps3: START SLAVE UNTIL SQL_AFTER_MTS_GAPS; 能够保证sql thread执行完relay log中所有的语句，而后自动stop slave。若是要把slave-parallel-workers的值从非0改成0(切换回单sql线程)，须要这样作：
START SLAVE UNTIL SQL_AFTER_MTS_GAPS;
SET @@GLOBAL.slave_parallel_workers = 0;
START SLAVE SQL_THREAD;

###6.binlog-checksum=CRC32，master-verify-checksum=1，slave-sql-verify-checksum=1：

这也是新特性，有了checksum, 若是binlog文件在master上损坏，或者在网络传输时损坏，或者保存到slave的时候损坏，都能自动检测出来。

###7.binlog-rows-query-log-events：

只对row-based binlog有效。enable以后，会向binlog中写入更多的调试信息，好比sql语句自身都会被写进去。 mysqlbinlog -vv 能够看到。

###8.innodb_flush_log_at_trx_commit=1 与 sync_binlog=1：

这两个参数在mysql数据库调优中有着很重要的做用，当你的mysql数据库性能不好时，你应该在排除完硬件问题后，首先检查这两个参数设置的是否合适。

innodb_flush_log_at_trx_commit分别能够设置成三个数值：0、一、2。
值为0表示每一秒钟将内存中的数据写入log_buff中，操做系统每秒钟将buffer中的数据写入硬盘中，这样作读写性能最优，可是安全性最差。
值为1表示每次事务提交时，将内存中的数据写入log_buffer中同时将数据实时落盘即写入硬盘中，这样数据安全性最高，可是性能最差。
值为2表示内存中的数据在每次提交后，被写入log_buffer中，而操做系统每隔一秒中，将buffer中数据写入硬盘，这中作法能够看做是安全和性能的折中选择。当机器宕机或者掉电后，若是你的raid卡是带电池的话，最后一秒钟的buffer数据是不会丢失的。

mysql中这个默认值为1.

sync_binlog能够设置为0、1或者N三种数值。
值为0，表示不主动作log刷盘动做，即由文件系统决定什么时候将binlog_cache中的数据写入硬盘中，或者只有在binlog_cache满了以后才会写入磁盘。0为默认值。
值为1，表示每次事务提交后，就将cache中的日志数据写入文件中，这样安全性最高，可是性能最差。
值为N,表示没N次事务提交后，进行数据刷盘动做。N的值能够根据本身的业务状况进行选择。

参考文章：http://www.linuxidc.com/Linux/2013-04/82712.htm

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程