MySql主从复制的搭建

本节讲解如何配置主从复制，包括几种形式的主从复制；如果不会安装mysql，自行百度或者参见这篇博客：mysql5.7 安装 ---- Linux

一、MySql主从复制介绍

MySQL 主从复制是指数据可以从一个MySQL数据库服务器主节点复制到一个或多个从节点。MySQL 默认采用异步复制方式，这样从节点不用一直访问主服务器来更新自己的数据，数据的更新可以在远程连接上进行，从节点可以复制主数据库中的所有数据库或者特定的数据库，或者特定的表。

MySQL 主从复制主要用途

• 系统的读写分离
• 数据实时备份，当系统中某个节点发生故障时，可以方便的故障切换
• 高可用HA
• 架构扩展
  随着系统中业务访问量的增大，如果是单机部署数据库，就会导致I/O访问频率过高。有了主从复制，增加多个数据存储节点，将负载分布在多个从节点上，降低单机磁盘I/O访问的频率，提高单个机器的I/O性能。

MySQL 主从形式

• 一主一从，一主多从（提高系统的读性能）
• 多主一从，多主多从；MySql 5.7以后支持

注：一主一从和一主多从是最常见的主从架构，实施起来简单并且有效，不仅可以实现HA，而且还能读写分离，进而提升集群的并发能力。

二、MySql主从复制模式

1. bin_log主从复制

MySQL binlog日志有三种格式，分别为Statement，MiXED，ROW。这里就不详细介绍了，知道就好，知道就可以百度他们的特点。

这种主从复制是最早出现的，兼容性是最好的，但是可能会导致食物的不完整性；从而倒致数据的差异。

2. GTID主从复制

其实这种复制模式，也是使用bin_log进行复制，但是原理稍有差别，让我们看一下原理：

• 主节点更新数据时，会在事务前产生GTID，一起记录到binlog日志中。
• 从节点的I/O线程将变更的bin log，写入到本地的relay log中。
• SQL线程从relay log中获取GTID，然后对比本地binlog是否有记录（所以MySQL从节点必须要开启binary log）。如果有记录，说明该GTID的事务已经执行，从节点会忽略。如果没有记录，从节点就会从relay log中执行该GTID的事务，并记录到bin log。在解析过程中会判断是否有主键，如果没有就用二级索引，如果有就用全部扫描。

注：此种方式虽然整合事物是完整的，但是如果事物失败了，所有的操作都不会被写入从服务器，也是会出现数据不一致性

3. 半同步主从赋值

这种复制只是用mysql自带的技术，就实现不了了，需要使用到插件；

半同步复制是在协议中添加了一个同步步骤，主节点在发送完日志文件之后，等待来自从节点的回应，收到从节点的同步确认之后才去提交数据(保证数据一定被备份了)

注：这种方式下，如果从mysql宕机了，那就麻烦了，MySql会自动切换到异步复制的状态，总结这三种复制方式，还真是没有非常完美的解决方案啊。

三、MySql主从复制的搭建

1. bin_log主从复制搭建

我们既然要做主从复制，首先要有两台计算机，分别都安装了数据库，这里我们假设两台主机的ip为192.168.10.131，192.168.10.133；端口全部为3306

a. 添加主从复制的用户

在主库上，创建从库访问的账号，这里我将其设置为最高权限，生产环境自行处理。

# 命令格式：GRANT 权限 ON 数据库对象 TO 用户
mysql> GRANT ALL ON *.* TO master-slave@'%' IDENTIFIED BY '123456';

# 刷新数据库权限
mysql> flush privileges;

查看刚才创建的用户用户：

mysql> select host, user from mysql.user;
+--------------+---------------+
| host         | user          |
+--------------+---------------+
| %            | master-slave  |
| %            | root          |
| localhost    | mysql.session |
| localhost    | mysql.sys     |
+--------------+---------------+

b. 配置主库

在 Linux 中，MySql 的配置文件名为 my.cnf，我们保持配置文件的其他配置不变，添加如下配置：

server_id=1				# 主机的标识
log-bin=mysql-bin.log	# 确保可写入的日志文件
binlog_format=mixed		# 二进制日志的格式，

# 下面两项为互斥配置，配置其中一项即可
# 注意，如果配置多个库的时候，应该重复写配置项，不要使用逗号分隔各个库
binlog-do-db=master		#允许主从复制数据库
binlog-ignore-db=mysql	#不允许主从复制的数据库

c. 配置从库

同样也是在 my.cnf 配置文件中修改，添加如下内容，注意 server_id 不可重复：

server_id=2				#主机的标识
log-bin=mysql-bin.log	#确保可写入的日志文件
binlog_format=mixed		#二进制日志的格式，

# 解决主从复制跨库和跨表更新的问题
# 例如：
# 主服务器配置：replicate_do_db=elon
# 执行两句sql语句：use mysql;
# update elon.table set ...
# 那么slave（从）服务器上第二句将不会被执行，这就是跨库更新的问题
# 我们在从服务器上replicate_wild_do_table=elon.%，这样就能解决上面的那个问题
# 
# 这个配置和上面的那个一样，互斥，配置一个就行
replicate_wild_do_table=oldboy.%
replicate_wild_ignore_table=mysql.%

d. 查询Master状态

mysql> flush tables with read lock;		# 锁表

mysql> show master status;				# 查看master状态
+------------------+----------+---------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB  | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+---------------+------------------+-------------------+
| mysql-bin.000001 |     2258 | my_db,my_test |                  |                   |
+------------------+----------+---------------+------------------+-------------------+
# File：生成的二进制日志
# position：随着bin_log的日志文件更新内容,发生的变化
# binlog_do_db：主从复制的数据库
# binlog_ignore_db：不允许主从复制的数据库

mysql> unlock tables;					# 解锁

e. 从库链接主库

stop slave;		# 停止从库的运行

# 链接主库，对应信息，自己寻找哦
change master to 
master_host='192.168.10.131',
master_user='master-slave',
master_password='123456',
master_log_file='mysql-bin.000001',
master_log_pos=2258;

start slave;	# 启动从库的运行

查看从库的状态：

mysql> show slave status\G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.10.131
                  Master_User: mysql_backup
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000008
          Read_Master_Log_Pos: 2258
               Relay_Log_File: slave-relay-bin.000009
                Relay_Log_Pos: 2471
        Relay_Master_Log_File: mysql-bin.000008
             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: 2258
              Relay_Log_Space: 2844
              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: 5a3e9412-b7ef-11e9-88fc-000c29a61a95
             Master_Info_File: /usr/local/mysql/data/master.info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: 
            Executed_Gtid_Set: 
                Auto_Position: 0
         Replicate_Rewrite_DB: 
                 Channel_Name: 
           Master_TLS_Version: 

当 Slave_IO_Running、Slave_SQL_Running 线程都为 yes 是主从复制配置成功！

f. 解出主从关系

mysql> stop slave;
Query OK, 0 rows affected (0.01 sec)

mysql> reset slave all;
Query OK, 0 rows affected (0.01 sec)

mysql> show slave status\G;
Empty set (0.00 sec)

这样关系就解除了！