【MySql】 mysql的组从复制

 mysql的组从复制

配置mastesr

[root@mysql-node10 ~]# vim /etc/my.cnf
[mysqld]
datadir=/data/mysql
socket=/data/mysql/mysql.sock
symbolic-links=0
log-bin=mysql-bin
server-id=1
[root@mysql-node10 ~]# /etc/init.d/mysqld restart
#进入数据库配置用户权限
[root@mysql-node10 ~]# mysql -plee
mysql: [Warning] Using a password on the command line interface can be insecure.
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 3
Server version: 5.7.44-log Source distribution
Copyright (c) 2000, 2023, Oracle and/or its affiliates.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> CREATE USER 'repl'@'%' IDENTIFIED BY 'lee'; ##生成专门用来做复制的用
户，此用户是用于slave端做认证用
mysql> GRANT REPLICATION SLAVE ON *.* TO repl@'%'; ##对这个用户进行授权
mysql> SHOW MASTER STATUS; ##查看master的状态
+------------------+----------+--------------+------------------+----------------
---+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
Executed_Gtid_Set |
+------------------+----------+--------------+------------------+----------------
---+
| mysql-bin.000001 | 350 | | |
|
+------------------+----------+--------------+------------------+----------------
---+
1 row in set (0.00 sec)
[root@mysql-node10 ~]# cd /data/mysql/
[root@mysql-node10 mysql]# mysqlbinlog mysql-bin.000001 -vv ##查看二进制日志

修改主配置文件：修改之后再启动

进入数据库进行编写：

创建一个名为 repl 的用户，该用户可以从任何主机（% 表示任何主机）连接到MySQL服务器，并且设置其密码为 xia。

在MySQL中，GRANT REPLICATION SLAVE 语句用于授权一个用户（在这个例子中是 repl）作为复制从服务器的权限。这个权限允许该用户连接到主服务器，并请求二进制日志事件，以便在从服务器上重放这些事件，从而实现数据复制。

你给出的命令 GRANT REPLICATION SLAVE ON *.* TO repl@'%'; 的含义是：

• GRANT REPLICATION SLAVE：授予复制从服务器的权限。
• ON *.*：这个权限适用于所有数据库（第一个 *）和所有表（第二个 *）。
• TO repl@'%'：这个权限被授予用户 repl，该用户可以从任何主机（% 表示任何主机）连接到MySQL服务器。

配置salve

编辑配置文件并重启：

进入数据库,与其master建立联系

 测试：

在master上建立数据库，在建表

在slave上查看：

如果出现则代表咱们的这个主复数据库依旧搭好，如果没有出现则反之

当有数据时添加slave2

创建新的mysql3：以上配置

在主的mysql中将上面编写的数据库传给MySQL3（slave2）

mysql3/(slave2)拉平数据库

配置好slave：

测试：

master写入：

mysql2:

mysql3:

延迟复制

延迟复制时用来控制 sql 线程的，和 i/o 线程无关

这个延迟复制不是 i/o 线程过段时间来复制， i/o 是正常工作的

是日志已经保存在 slave 端了，那个 sql 要等多久进行回放

#在slave端
mysql> STOP SLAVE SQL_THREAD;
mysql> CHANGE MASTER TO MASTER_DELAY=60;
mysql> START SLAVE SQL_THREAD;
mysql> SHOW SLAVE STATUS\G;
Master_Server_Id: 1
Master_UUID: db2d8c92-4dc2-11ef-b6b0-000c299355ea
Master_Info_File: /data/mysql/master.info
SQL_Delay: 60 ##延迟效果
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more
updates
Master_Retry_Count: 86400

测试：

在 master 中写入数据后过了延迟时间才能被查询到

我们在master中删除东西，查看slave2中，会发现延迟60s之后才会删除东西；

这样的作用是防止咱们重要文件数据被删除，可以其他的slave服务器中挽救减少损失

慢查询日志

慢查询，顾名思义，执行很慢的查询

当执行 SQL 超过 long_query_time 参数设定的时间阈值（默认 10s ）时，就被认为是慢查询，这个

SQL 语句就是需要优化的

慢查询被记录在慢查询日志里

慢查询日志默认是不开启的

如果需要优化 SQL 语句，就可以开启这个功能，它可以让你很容易地知道哪些语句是需要优化的。

打开慢查询日志：

测试：

查看日志：

mysql 的并行复制

默认情况下 slave 中使用的是 sql 单线程回放

在 master 中时多用户读写，如果使用 sql 单线程回放那么会造成组从延迟严重

开启 MySQL 的多线程回放可以解决上述问题

在slaves中设定
[root@mysql-node2 ~]# vim /etc/my.cnf
[mysqld]
datadir=/data/mysql
socket=/data/mysql/mysql.sock
server-id=2
gtid_mode=ON
enforce-gtid-consistency=ON
slave-parallel-type=LOGICAL_CLOCK #基于组提交，
slave-parallel-workers=16 #开启线程数量
master_info_repository=TABLE #master信息在表中记录，默认记录
在/data/mysql//master.info
relay_log_info_repository=TABLE #回放日志信息在表中记录，默认记录
在/data/mysql/relay-log.info
relay_log_recovery=ON #日志回放恢复功能开启

slave2

编辑主文件：

测试结果：

此时 sql 线程转化为协调线程， 16 个 worker 负责处理 sql 协调线程发送过来的处理请求

MySQL 组提交（ Group commit ）是一个性能优化特性，它允许在一个事务日志同步操作中将多个

事务的日志记录一起写入。这样做可以减少磁盘 I/O 的次数，从而提高数据库的整体性能。

原理

三个线程

实际上主从同步的原理就是基于 binlog 进行数据同步的。在主从复制过程中，会基于 3 个线程来操作，一个主库线程，两个从库线程。

• 二进制日志转储线程（Binlog dump thread）是一个主库线程。当从库线程连接的时候， 主库可以将二进制日志发送给从库，当主库读取事件（Event）的时候，会在 Binlog 上加锁，读取完成之后，再将锁释放掉。
• 从库 I/O 线程会连接到主库，向主库发送请求更新 Binlog。这时从库的 I/O 线程就可以读取到主库的二进制日志转储线程发送的 Binlog 更新部分，并且拷贝到本地的中继日志 （Relay log）。
• 从库 SQL 线程会读取从库中的中继日志，并且执行日志中的事件，将从库中的数据与主库保持同步

复制三步骤

步骤 1 ： Master 将写操作记录到二进制日志（ binlog ）。

步骤 2 ： Slave 将 Master 的 binary log events 拷贝到它的中继日志（ relay log ）；

步骤 3 ： Slave 重做中继日志中的事件，将改变应用到自己的数据库中。 MySQL 复制是异步的且串行化的，而且重启后从接入点开始复制。

具体操作

1.slaves 端中设置了 master 端的 ip ，用户，日志，和日志的 Position ，通过这些信息取得 master 的认证及信息

2.master 端在设定好 binlog 启动后会开启 binlog dump 的线程

3.master 端的 binlog dump 把二进制的更新发送到 slave 端的

4.slave 端开启两个线程，一个是 I/O 线程，一个是 sql 线程，i/o线程用于接收 master 端的二进制日志，此线程会在本地打开 relaylog 中继日志，并且保存到本地磁盘 ，sql线程读取本地 relog 中继日志进行回放

5. 什么时候我们需要多个 slave ？

当读取的而操作远远高与写操作时。我们采用一主多从架构

数据库外层接入负载均衡层并搭配高可用机制

架构缺陷

• 主从架构采用的是异步机制
• master更新完成后直接发送二进制日志到slave，但是slaves是否真正保存了数据master端不会检测master端直接保存二进制日志到磁盘
• 当master端到slave端的网络出现问题时或者master端直接挂掉，二进制日志可能根本没有到达slave
• master出现问题slave端接管master，这个过程中数据就丢失了
• 这样的问题出现就无法达到数据的强一致性，零数据丢失