mysql主从

最新推荐文章于 2024-07-19 22:24:39 发布

Blue Dream~

最新推荐文章于 2024-07-19 22:24:39 发布

阅读量451

点赞数

文章标签： mysql 数据库服务器

本文链接：https://blog.csdn.net/cxyxt/article/details/126171650

版权

1. 主从简介

在现代企业中，数据显得尤为重要，而存储数据的数据库选择又五花八门，但无论是何种数据库，均存在着一种隐患。

想几个问题：

  用一台数据库存放数据，若此数据库服务器宕机了导致数据丢失怎么办？
	业务量大了，数据多了，访问的人多了，一台数据库无法保证服务质量了怎么办？

1.1 主从作用

实时灾备，用于故障切换
读写分离，提供查询服务
备份，避免影响业务

1.2 主从形式

主从复制原理
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-muVVbIXa-1659663941372)(./1659240199647.png)]

主从复制步骤：

	>主库将所有的写操作记录到binlog日志中并生成一个log dump线程，将binlog日志传给从库的I/O线程
	从库生成两个线程，一个I/O线程，一个SQL线程

I/O线程去请求主库的binlog，并将得到的binlog日志写到relay log（中继日志）文件中
SQL线程，会读取relay log文件中的日志，并解析成具体操作，来实现主从的操作一致，达到最终数据一致的目的

3. 主从复制配置

主从复制配置步骤：

1.确保从数据库与主数据库里的数据一样
2.在主数据库里创建一个同步账号授权给从数据库使用
3.配置主数据库（修改配置文件）
4.配置从数据库（修改配置文件）

需求：
搭建两台MySQL服务器，一台作为主服务器，一台作为从服务器，主服务器进行写操作，从服务器进行读操作

环境说明：
数据库角色 IP 应用与系统版本有无数据
master 192.168.47.134 centos8/redhat8
mysql-5.7 有数据

slave 192.168.47.142 centos8/redhat8
mysql-5.7 无数据

3.1 mysql安装

分别在主从两台服务器上安装mysql-5.7版本，此处略过安装步骤，若有疑问请参考《mysql基础》与《mysql进阶》两篇文章。

3.2 mysql主从配置

3.2.1 确保从数据库与主数据库里的数据一样

为确保从数据库与主数据库里的数据一样，先全备主数据库并还原到从数据库中

//先查看主库有哪些库
[root@master ~]# mysql -uroot -p123456 -e 'show databases;'
mysql: [Warning] Using a password on the command line interface can be insecure.
+--------------------+
| Database           |
+--------------------+
| information_schema |
| lty                |
| mysql              |
| performance_schema |
| sys                |
+--------------------+


//再查看从库有哪些库
[root@slave ~]# mysql -uroot -p'12' -e 'show databases;'
mysql: [Warning] Using a password on the command line interface can be insecure.
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| sys                |
+--------------------+


//全备主库
//全备主库时需要另开一个终端，给数据库加上读锁，避免在备份期间有其他人在写入导致数据不一致
mysql> FLUSH TABLES WITH READ LOCK;
Query OK, 0 rows affected (0.00 sec)
//此锁表的终端必须在备份完成以后才能退出

//备份主库并将备份文件传送到从库
[root@master ~]# mysqldump -uroot -p'123456' --all-databases > allsy.sql
mysqldump: [Warning] Using a password on the command line interface can be insecure.
[root@master ~]# ls
allsy.sql  anaconda-ks.cfg
[root@master ~]# scp allsy.sql root@192.168.47.142:/opt/
The authenticity of host '192.168.47.142 (192.168.47.142)' can't be established.
ECDSA key fingerprint is SHA256:Q5exWaBHsfV1gTajIf8KHUP5mlDwNrsgtmGPIwyGNbA.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.47.142' (ECDSA) to the list of known hosts.
root@192.168.47.142's password: 
allsy.sql                         100%  855KB  51.0MB/s   00:00


[root@slave ~]# cd /opt/
[root@slave opt]# ls
allsy.sql  containerd  data


//解除主库的锁表状态，直接退出交互式界面即可
mysql> quit
Bye


//在从库上恢复主库的备份并查看从库有哪些库，确保与主库一致
[root@slave opt]# mysql -uroot -p12 < /opt/allsy.sql 
mysql: [Warning] Using a password on the command line interface can be insecure.
[root@slave opt]# mysql -uroot -p12 -e 'show databases;'
mysql: [Warning] Using a password on the command line interface can be insecure.
+--------------------+
| Database           |
+--------------------+
| information_schema |
| lty                |
| mysql              |
| performance_schema |
| sys                |
+--------------------+

3.2.2 在主数据库里创建一个同步账号授权给从数据库使用

mysql> create user ‘tom’@‘192.168.47.142’ identified by ‘tom12’;
Query OK, 0 rows affected (0.00 sec)

mysql> grant replication slave on . to ‘tom’@‘192.168.47.142’;
Query OK, 0 rows affected (0.00 sec)

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

3.2.3 配置主数据库

[root@localhost ~]# vim /etc/my.cnf
//在[mysqld]这段的后面加上如下内容
log-bin=mysql-bin   //启用binlog日志
server-id=1     //数据库服务器唯一标识符，主库的server-id值必须比从库的大



//重启mysql服务
[root@master ~]# vi /etc/my.cnf 
[root@master ~]# service mysqld restart
Shutting down MySQL.. SUCCESS! 
Starting MySQL. SUCCESS! 
[root@master ~]# mysql -uroot -p123456 -e 'show master status;'
mysql: [Warning] Using a password on the command line interface can be insecure.
+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000003 |      154 |              |                  |                   |
+------------------+----------+--------------+------------------+-                              :::*

3.2.4 配置从数据库

server-id=2     //设置从库的唯一标识符，从库的server-id值必须小于主库的该值
relay-log=mysql-relay-bin       //启用中继日志relay-log



//重启从库的mysql服务
[root@slave opt]# vi /etc/my.cnf 
[root@slave opt]# service mysqld restart
Shutting down MySQL.... SUCCESS! 
Starting MySQL. SUCCESS! 
[root@slave opt]# ss -antl
State  Recv-Q Send-Q Local Address:Port   Peer Address:Port Process 
LISTEN 0      128          0.0.0.0:22          0.0.0.0:*            
LISTEN 0      5          127.0.0.1:631         0.0.0.0:*            
LISTEN 0      128        127.0.0.1:6010        0.0.0.0:*            
LISTEN 0      128          0.0.0.0:111         0.0.0.0:*            
LISTEN 0      128             [::]:22             [::]:*            
LISTEN 0      5              [::1]:631            [::]:*            
LISTEN 0      128            [::1]:6010           [::]:*            
LISTEN 0      80                 *:3306              *:*            
LISTEN 0      128             [::]:111            [::]:* 




//配置并启动主从复制
mysql> change master to
    -> master_host='192.168.47.134',
    -> master_user='tom',
    -> master_password='tom12',
    -> master_log_file='mysql-bin.000003',
    -> master_log_pos=154;
Query OK, 0 rows affected, 2 warnings (0.02 sec)

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

mysql> show slave status \G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.47.134
                  Master_User: tom
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000003
          Read_Master_Log_Pos: 154
               Relay_Log_File: mysql-relay-bin.000002
                Relay_Log_Pos: 320
        Relay_Master_Log_File: mysql-bin.000003
             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: 154
              Relay_Log_Space: 527
              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: 999ab59c-0cf4-11ed-bc6a-000c29686282
             Master_Info_File: /opt/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: 
1 row in set (0.00 sec)

3.2.5 测试验证

在主服务器的student库的bj2表中插入数据：

mysql> select * from hh;
+------+------+
| id   | name |
+------+------+
|    1 | w    |
|    2 | r    |
|    3 | y    |
+------+------+
3 rows in set (0.00 sec)

mysql> insert into hh values (4,'hh'),(5,'g');
Query OK, 2 rows affected (0.00 sec)
Records: 2  Duplicates: 0  Warnings: 0

mysql> select * from hh;
+------+------+
| id   | name |
+------+------+
|    1 | w    |
|    2 | r    |
|    3 | y    |
|    4 | hh   |
|    5 | g    |
+------+------+
5 rows in set (0.00 sec)

在从数据库中查看数据是否同步：

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| lty                |
| mysql              |
| performance_schema |
| sys                |
+--------------------+
5 rows in set (0.00 sec)

mysql> use lty;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> show tables;
+---------------+
| Tables_in_lty |
+---------------+
| hh            |
+---------------+
1 row in set (0.00 sec)

mysql> select * from hh;
+------+------+
| id   | name |
+------+------+
|    1 | w    |
|    2 | r    |
|    3 | y    |
|    4 | hh   |
|    5 | g    |
+------+------+
5 rows in set (0.00 sec)

4. GTID主从

4.1 GTID概念介绍

GTID即全局事务ID (global transaction identifier), 其保证为每一个在主上提交的事务在复制集群中可以生成一个唯一的ID。GTID最初由google实现，官方MySQL在5.6才加入该功能。mysql主从结构在一主一从情况下对于GTID来说就没有优势了，而对于2台主以上的结构优势异常明显，可以在数据不丢失的情况下切换新主。

>使用GTID需要注意: 在构建主从复制之前，在一台将成为主的实例上进行一些操作（如数据清理等），通过GTID复制，这些在主从成立之前的操作也会被复制到从服务器上，引起复制失败。也就是说通过GTID复制都是从最先开始的事务日志开始，即使这些操作在复制之前执行。比如在server1上执行一些drop、delete的清理操作，接着在server2上执行change的操作，会使得server2也进行server1的清理操作。

GTID实际上是由UUID+TID (即transactionId)组成的。其中UUID(即server_uuid) 产生于auto.conf文件(cat /data/mysql/data/auto.cnf)，是一个MySQL实例的唯一标识。TID代表了该实例上已经提交的事务数量，并且随着事务提交单调递增，所以GTID能够保证每个MySQL实例事务的执行（不会重复执行同一个事务，并且会补全没有执行的事务）。GTID在一组复制中，全局唯一。

下面是一个GTID的具体形式 :

mysql> show master status;
+-----------+----------+--------------+------------------+-------------------------------------------+
| File      | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                         |
+-----------+----------+--------------+------------------+-------------------------------------------+
| on.000003 |      187 |              |                  | 7286f791-125d-11e9-9a9c-0050568843f8:1-362|
+-----------+----------+--------------+------------------+-------------------------------------------+
1 row in set (0.00 sec)
 
GTID:7286f791-125d-11e9-9a9c-0050568843f8:1-362
UUID:7286f791-125d-11e9-9a9c-0050568843f8
transactionId:1-362

在整个复制架构中GTID 是不变化的,即使在多个连环主从中也不会变。
 
例如：ServerA --->ServerB ---->ServerC
GTID从在ServerA ,ServerB,ServerC 中都是一样的。

了解了GTID的格式，通过UUID可以知道这个事务在哪个实例上提交的。通过GTID可以极方便的进行复制结构上的故障转移，新主设置，这就很好地解决了下面这个图所展现出来的问题。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-bQQb1POG-1659663941374)(./3U[D}WPQ`W6426780FJUHDE.png)]

如图, Server1(Master)崩溃，根据从上show slave status获得Master_log_File/Read_Master_Log_Pos的值，Server2(Slave)已经跟上了主，Server3(Slave)没有跟上主。这时要是把Server2提升为主，Server3变成Server2的从。这时在Server3上执行change的时候需要做一些计算。

这个问题在5.6的GTID出现后，就显得非常的简单。由于同一事务的GTID在所有节点上的值一致，那么根据Server3当前停止点的GTID就能定位到Server2上的GTID。甚至由于MASTER_AUTO_POSITION功能的出现，我们都不需要知道GTID的具体值，直接使用CHANGE MASTER TO MASTER_HOST=‘xxx’, MASTER_AUTO_POSITION命令就可以直接完成failover的工作。

====== GTID和Binlog的关系 ======

GTID在binlog中的结构
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-M9oRzNfZ-1659663941376)(./7KZURVJ@`T_TC34_52QT6X3.png)]

GTID event 结构
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-LiB4Nqot-1659663941378)(./BD748_JXUX7F]`JFNOLKH[C.png)]

Previous_gtid_log_event
Previous_gtid_log_event 在每个binlog 头部都会有每次binlog rotate的时候存储在binlog头部Previous-GTIDs在binlog中只会存储在这台机器上执行过的所有binlog，不包括手动设置gtid_purged值。换句话说，如果你手动set global gtid_purged=xx；那么xx是不会记录在Previous_gtid_log_event中的。

GTID和Binlog之间的关系是怎么对应的呢? 如何才能找到GTID=? 对应的binlog文件呢？
假设有4个binlog: bin.001,bin.002,bin.003,bin.004
bin.001 : Previous-GTIDs=empty; binlog_event有: 1-40
bin.002 : Previous-GTIDs=1-40; binlog_event有: 41-80
bin.003 : Previous-GTIDs=1-80; binlog_event有: 81-120
bin.004 : Previous-GTIDs=1-120; binlog_event有: 121-160
假设现在我们要找GTID=$A，那么MySQL的扫描顺序为:

从最后一个binlog开始扫描（即: bin.004）

bin.004的Previous-GTIDs=1-120，如果$A=140 > Previous-GTIDs,那么肯定在bin.004中

bin.004的Previous-GTIDs=1-120，如果$A=88 包含在Previous-GTIDs中,那么继续对比上一个binlog文件 bin.003,然后再循环前面2个步骤，直到找到为止.

====== GTID 重要参数的持久化 =======

GTID相关参数：

参数 comment
gtid_executed 执行过的所有GTID
gtid_purged 丢弃掉的GTID
gtid_mode GTID模式
gtid_next session级别的变量，下一个gtid
gtid_owned 正在运行的GTID
enforce_gtid_consistency 保证GTID安全的参数

====== 开启GTID的必备条件 ======

gtid_mode=on    (必选)
enforce-gtid-consistency=1  （必选）
log_bin=mysql-bin           （可选）    #高可用切换，最好开启该功能
log-slave-updates=1     （可选）       #高可用切换，最好打开该功能

4.2 GTID工作原理

从服务器连接到主服务器之后，把自己执行过的GTID (Executed_Gtid_Set: 即已经执行的事务编码) 、获取到的GTID (Retrieved_Gtid_Set: 即从库已经接收到主库的事务编号) 发给主服务器，主服务器把从服务器缺少的GTID及对应的transactions发过去补全即可。当主服务器挂掉的时候，找出同步最成功的那台从服务器，直接把它提升为主即可。如果硬要指定某一台不是最新的从服务器提升为主，先change到同步最成功的那台从服务器，等把GTID全部补全了，就可以把它提升为主了。

GTID是MySQL 5.6的新特性，可简化MySQL的主从切换以及Failover。GTID用于在binlog中唯一标识一个事务。当事务提交时，MySQL Server在写binlog的时候，会先写一个特殊的Binlog Event，类型为GTID_Event，指定下一个事务的GTID，然后再写事务的Binlog。主从同步时GTID_Event和事务的Binlog都会传递到从库，从库在执行的时候也是用同样的GTID写binlog，这样主从同步以后，就可通过GTID确定从库同步到的位置了。也就是说，无论是级联情况，还是一主多从情况，都可以通过GTID自动找点儿，而无需像之前那样通过File_name和File_position找点儿了。

**简而言之，GTID的工作流程为：**

master更新数据时，会在事务前产生GTID，一同记录到binlog日志中。
slave端的i/o 线程将变更的binlog，写入到本地的relay log中。
sql线程从relay log中获取GTID，然后对比slave端的binlog是否有记录。
如果有记录，说明该GTID的事务已经执行，slave会忽略。
如果没有记录，slave就会从relay log中执行该GTID的事务，并记录到binlog。
在解析过程中会判断是否有主键，如果没有就用二级索引，如果没有就用全部扫描。

4.3 GTID主从配置

环境说明：

数据库角色 IP 应用与系统版本
主数据库 172.16.12.128 centos8/redhat8
mysql-5.7
从数据库 172.16.12.129 centos8/redhat8
mysql-5.7

主库配置。vi /etc/my.cnf，添加以下配置，重启mysql。

log-b[root@master ~]# vi /etc/my.cnf in
log-bin=mysql_bin
server-id=10
gtid_mode=on
enforce-gtid-consistency=true
log-slave-updates=on
[root@master ~]# service mysqld restart
Shutting down MySQL.... SUCCESS! 
Starting MySQL. SUCCESS! 

从库配置。vi /etc/my.cnf, 添加以下配置，重启mysql。
[root@slave ~]# service mysqld restart		//这里需要重新启动下在修改
Shutting down MySQL.... SUCCESS! 
Starting MySQL. SUCCESS!
[root@dacker ~]# vi /etc/my.cnf 
server-id=20
relay-log=myrelay
gtid_mode=on
enforce-gtid-consistency=true
log-slave-updates=on
read_only=on
master-info-repository=TABLE
relay-log-info-repository=TABLE
[root@slave ~]# service mysqld restart
Shutting down MySQL.... SUCCESS! 
Starting MySQL. SUCCESS!

主库授权复制用户。

mysql> grant replication slave on *.* to 'gg'@'%' identified by 'gg123';
Query OK, 0 rows affected, 1 warning (0.00 sec)

**从库**设置要同步的主库信息，并开启同步。

mysql> change master to master_host='192.168.47.134',
    -> master_port=3306,
    -> master_user='gg',
    -> master_password='gg123',
    -> master_auto_position=1;
Query OK, 0 rows affected, 2 warnings (0.03 sec)

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

mysql> show slave status
    -> \G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.47.134
                  Master_User: gg
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql_bin.000001
          Read_Master_Log_Pos: 435
               Relay_Log_File: myrelay.000002
                Relay_Log_Pos: 648
        Relay_Master_Log_File: mysql_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: 435
              Relay_Log_Space: 847
              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: 10
                  Master_UUID: 999ab59c-0cf4-11ed-bc6a-000c29686282
             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 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: 999ab59c-0cf4-11ed-bc6a-000c29686282:1
            Executed_Gtid_Set: 999ab59c-0cf4-11ed-bc6a-000c29686282:1
                Auto_Position: 1
         Replicate_Rewrite_DB: 
                 Channel_Name: 
           Master_TLS_Version: 
1 row in set (0.00 sec)

配置完之后，通过查看slave的状态，可以看是否配置成功。同时可以在主库进行一些操作，提交一些事务(insert,update)，之后数据就会自动同步到从库。

//主库插入数据
mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| lty                |
| mysql              |
| performance_schema |
| sys                |
+--------------------+
5 rows in set (0.00 sec)

mysql> use lty;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> show tables;
+---------------+
| Tables_in_lty |
+---------------+
| hh            |
+---------------+
1 row in set (0.00 sec)

mysql> select * from hh;
+------+------+
| id   | name |
+------+------+
|    1 | w    |
|    2 | r    |
|    3 | g    |
+------+------+
3 rows in set (0.00 sec)


//从库查看同步
mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| lty                |
| mysql              |
| performance_schema |
| sys                |
+--------------------+
5 rows in set (0.00 sec)

mysql> use lty;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> show tables;
+---------------+
| Tables_in_lty |
+---------------+
| hh            |
+---------------+
1 row in set (0.00 sec)

mysql> select * from hh;
+------+------+
| id   | name |
+------+------+
|    1 | w    |
|    2 | r    |
|    3 | g    |
+------+------+
3 rows in set (0.00 sec)