- 16.表锁（偏读）
- 1、创建表
- 2、插入数据
- 给mylock表上读锁，给book表上写锁
- 查看当前表的状态
- 17.行锁（偏写）
- 建表语句
- 插入数据
- 创建索引
- SESSION1
- SESSION1 对test_innodb_lock表做写操作，但是没有commit
- 执行修改SQL之后，查询一下test_innodb_lock表，发现数据被修改了
- SESSION2
- SESSION2 这时候来查询test_innodb_lock表。
- 发现SESSION2是读不到SESSION1未提交的数据的。
- SESSION1 対test_innodb_lock表的
a=6这一行进行写操作，但是没有commit - SESSION2 対test_innodb_lock表的
a=4这一行进行写操作，没有阻塞！！！ - SESSION1和SESSION2同时对不同的行进行写操作互不影响
- 优化建议
- 18.主从复制
- 1、GRANT REPLICATION SLAVE ON . TO ‘username’@’从机IP地址’ IDENTIFIED BY ‘password’;
- 2、刷新命令
- 3、记录下File和Position
- 每次配从机的时候都要SHOW MASTER STATUS;查看最新的File和Position
- Master创建数据库
- Slave查询数据库
16.表锁（偏读）
表锁特点
- 表锁偏向
**MyISAM**存储引擎，开销小，加锁快，无死锁，锁定粒度大，发生锁冲突的概率最高，并发度最低16.1.环境准备
```sql1、创建表
CREATE TABLE IF NOT EXISTSbook(bookidINT(10) UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT COMMENT ‘主键’,cardINT(10) UNSIGNED NOT NULL COMMENT ‘分类’ ) COMMENT ‘书籍’;
CREATE TABLE mylock(
id INT NOT NULL PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(20)
)ENGINE=MYISAM DEFAULT CHARSET=utf8 COMMENT=’测试表锁’;
2、插入数据
INSERT INTO mylock(name) VALUES(‘ZhangSan’);
INSERT INTO mylock(name) VALUES(‘LiSi’);
INSERT INTO mylock(name) VALUES(‘WangWu’);
INSERT INTO mylock(name) VALUES(‘ZhaoLiu’);
<a name="e154c324"></a>## 16.2.锁表的命令1. 查看数据库表锁的命令```sqlSHOW OPEN TABLES; # 查看数据库表锁的命令
- 给
mylock表上读锁，给book表上写锁**LOCK TABLESmylockREAD,bookWRITE;**```sql给mylock表上读锁，给book表上写锁
LOCK TABLESmylockREAD,bookWRITE;
查看当前表的状态
mysql> SHOW OPEN TABLES; +——————————+————————————-+————+——————-+ | Database | Table | In_use | Name_locked | +——————————+————————————-+————+——————-+ | sql_analysis | book | 1 | 0 | | sql_analysis | mylock | 1 | 0 | +——————————+————————————-+————+——————-+
3. 释放表锁`**UNLOCK TABLES;**````sql# 释放给表添加的锁UNLOCK TABLES;# 查看当前表的状态mysql> SHOW OPEN TABLES;+--------------------+-------------------------+--------+-------------+| Database | Table | In_use | Name_locked |+--------------------+-------------------------+--------+-------------+| sql_analysis | book | 0 | 0 || sql_analysis | mylock | 0 | 0 |+--------------------+-------------------------+--------+-------------+
16.3.读锁案例
打开两个会话，
SESSION1为mylock表添加读锁LOCK TABLES `mylock` READ; # 为mylock表添加读锁
打开两个会话，
SESSION1是否可以读自己锁的表？是否可以修改自己锁的表？是否可以读其他的表？
那么SESSION2呢？
能 不能 不能
能 阻塞 能
# SESSION1# 问题1：SESSION1为mylock表加了读锁，可以读mylock表！mysql> SELECT * FROM `mylock`;+----+----------+| id | name |+----+----------+| 1 | ZhangSan || 2 | LiSi || 3 | WangWu || 4 | ZhaoLiu |+----+----------+4 rows in set (0.00 sec)# 问题2：SESSION1为mylock表加了读锁，不可以修改mylock表！mysql> UPDATE mylock SET name = 'abc' WHERE id = 1;ERROR 1099 (HY000): Table mylock was locked with a READ lock and cannot be updated# 问题3：SESSION1为mylock表加了读锁，不可以读其他的表！mysql> SELECT * FROM `book`;ERROR 1100 (HY000): Table 'book' was not locked with LOCK TABLES
# SESSION2# 问题1：SESSION1为mylock表加了读锁，SESSION2可以读mylock表！mysql> SELECT * FROM `mylock`;+----+----------+| id | name |+----+----------+| 1 | ZhangSan || 2 | LiSi || 3 | WangWu || 4 | ZhaoLiu |+----+----------+4 rows in set (0.00 sec)# 问题2：SESSION1为mylock表加了读锁，SESSION2修改mylock表会被阻塞，# 需要等待SESSION1释放mylock表！mysql> UPDATE `mylock` SET `name` = 'abc' WHERE `id` = 1;^C^C -- query abortedERROR 1317 (70100): Query execution was interrupted# 问题3：SESSION1为mylock表加了读锁，SESSION2可以读其他表！mysql> SELECT * FROM `book`;+--------+------+| bookid | card |+--------+------+| 1 | 1 || 7 | 4 || 8 | 4 || 9 | 5 || 5 | 6 || 17 | 6 || 15 | 8 |+--------+------+24 rows in set (0.00 sec)
16.4.写锁案例
打开两个会话，
SESSION1为mylock表添加写锁# 为mylock表添加写锁LOCK TABLES mylock WRITE;
打开两个会话，
SESSION1是否可以读自己锁的表？是否可以修改自己锁的表？是否可以读其他的表？
那么SESSION2呢？
能 能 不能
阻塞 阻塞 能
# SESSION1# 问题1：SESSION1为mylock表加了写锁，可以读mylock的表！mysql> SELECT * FROM `mylock`;+----+----------+| id | name |+----+----------+| 1 | ZhangSan || 2 | LiSi || 3 | WangWu || 4 | ZhaoLiu |+----+----------+4 rows in set (0.00 sec)# 问题2：SESSION1为mylock表加了写锁，可以修改mylock表!mysql> UPDATE `mylock` SET `name` = 'abc' WHERE `id` = 1;Query OK, 1 row affected (0.00 sec)Rows matched: 1 Changed: 1 Warnings: 0# 问题3：SESSION1为mylock表加了写锁，不能读其他表!mysql> SELECT * FROM `book`;ERROR 1100 (HY000): Table 'book' was not locked with LOCK TABLES# SESSION2# 问题1：SESSION1为mylock表加了写锁，SESSION2读mylock表会阻塞，等待SESSION1释放！mysql> SELECT * FROM `mylock`;^C^C -- query abortedERROR 1317 (70100): Query execution was interrupted# 问题2：SESSION1为mylock表加了写锁，SESSION2读mylock表会阻塞，等待SESSION1释放！mysql> UPDATE `mylock` SET `name` = 'abc' WHERE `id` = 1;^C^C -- query abortedERROR 1317 (70100): Query execution was interrupted# 问题3：SESSION1为mylock表加了写锁，SESSION2可以读其他表！mysql> SELECT * FROM `book`;+--------+------+| bookid | card |+--------+------+| 1 | 1 || 7 | 4 || 8 | 4 || 9 | 5 || 5 | 6 || 17 | 6 || 15 | 8 |+--------+------+24 rows in set (0.00 sec)
16.5.案例结论
**MyISAM**引擎在执行查询语句**SELECT**之前，会自动给涉及到的所有表加读锁，在执行增删改之前，会自动给涉及的表加写锁。
MySQL的表级锁有两种模式
- 表共享读锁（Table Read Lock）
- 表独占写锁（Table Write Lock）
対MyISAM表进行操作，会有以下情况
- 读操作（加读锁），不会阻塞其他线程対同一表的读操作，但是会阻塞其他线程対同一表的写操作。只有当读锁释放之后，才会执行其他线程的写操作
- 写操作（加写锁），会阻塞其他线程対同一表的读和写操作，只有当写锁释放之后，才会执行其他线程的读写操作
简言之，就是读锁会阻塞写，但不会阻塞读。而写锁会把读跟写都阻塞
16.6.表锁分析
mysql> SHOW STATUS LIKE 'table%';+----------------------------+-------+| Variable_name | Value |+----------------------------+-------+| Table_locks_immediate | 173 || Table_locks_waited | 0 || Table_open_cache_hits | 5 || Table_open_cache_misses | 8 || Table_open_cache_overflows | 0 |+----------------------------+-------+5 rows in set (0.00 sec)
可以通过
**Table_locks_immediate**和**Table_locks_waited**状态变量来分析系统上的表锁定。具体说明如下Table_locks_immediate产生表级锁定的次数，表示可以立即获取锁的查询次数，每立即获取锁值加1Table_locks_waited出现表级锁定争用而发生等待的次数（不能立即获取锁的次数，每等待一次锁值加1），此值高则说明存在较严重的表级锁争用情况
此外，**MyISAM**的读写锁调度是写优先，这也是**MyISAM**不适合作为主表的引擎。因为写锁后，其他线程不能进行任何操作，大量的写操作会使查询很难得到锁，从而造成永远阻塞
17.行锁（偏写）
行锁特点
- 偏向
InnoDB存储引擎，开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度最高
**InnoDB**存储引擎和**MyISAM**存储引擎最大不同有两点：一是支持事务，二是采用行锁
事务的ACID
Atomicity [ˌætəˈmɪsəti]Consistency [kənˈsɪstənsi]Isolation [ˌaɪsəˈleɪʃn]Durability [ˌdjʊərəˈbɪlɪti]17.1.环境准备
```sql建表语句
CREATE TABLE test_innodb_lock(aINT,bVARCHAR(16) )ENGINE=INNODB DEFAULT CHARSET=utf8 COMMENT=’测试行锁’;
插入数据
INSERT INTO test_innodb_lock(a, b) VALUES(1, ‘b2’);
INSERT INTO test_innodb_lock(a, b) VALUES(2, ‘3’);
INSERT INTO test_innodb_lock(a, b) VALUES(3, ‘4000’);
INSERT INTO test_innodb_lock(a, b) VALUES(4, ‘5000’);
INSERT INTO test_innodb_lock(a, b) VALUES(5, ‘6000’);
INSERT INTO test_innodb_lock(a, b) VALUES(6, ‘7000’);
INSERT INTO test_innodb_lock(a, b) VALUES(7, ‘8000’);
INSERT INTO test_innodb_lock(a, b) VALUES(8, ‘9000’);
创建索引
CREATE INDEX idx_test_a ON test_innodb_lock(a); CREATE INDEX idx_test_b ON test_innodb_lock(b);
<a name="71a2fc60"></a>## 17.2.行锁案例1. 打开`SESSION1`和`SESSION2`两个会话，都开启手动提交```sql# 开启MySQL数据库的手动提交mysql> SET autocommit=0;Query OK, 0 rows affected (0.00 sec)
SESSION1 对test_innodb_lock表做写操作，但是没有commit
执行修改SQL之后，查询一下test_innodb_lock表，发现数据被修改了
mysql> UPDATE test_innodb_lock SET b = ‘88’ WHERE a = 1;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> SELECT * FROM test_innodb_lock;
+———+———+
| a | b |
+———+———+
| 1 | 88 |
| 2 | 3 |
| 3 | 4000 |
| 4 | 5000 |
| 5 | 6000 |
| 6 | 7000 |
| 7 | 8000 |
| 8 | 9000 |
+———+———+
8 rows in set (0.00 sec)
SESSION2
SESSION2 这时候来查询test_innodb_lock表。
发现SESSION2是读不到SESSION1未提交的数据的。
mysql> SELECT * FROM test_innodb_lock;
+———+———+
| a | b |
+———+———+
| 1 | b2 |
| 2 | 3 |
| 3 | 4000 |
| 4 | 5000 |
| 5 | 6000 |
| 6 | 7000 |
| 7 | 8000 |
| 8 | 9000 |
+———+———+
8 rows in set (0.00 se
3. 行锁两个SESSION同时対一条记录进行写操作```shell# SESSION1 対test_innodb_lock表的`a`=1这一行进行写操作，但是没有commitmysql> UPDATE `test_innodb_lock` SET `b` = '99' WHERE `a` = 1;Query OK, 1 row affected (0.00 sec)Rows matched: 1 Changed: 1 Warnings: 0# SESSION2 也对test_innodb_lock表的`a`=1这一行进行写操作，但是发现阻塞了！！！# 等SESSION1执行commit语句之后，SESSION2的SQL就会执行了mysql> UPDATE `test_innodb_lock` SET `b` = 'asdasd' WHERE `a` = 1;ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
- 行锁两个SESSION同时对不同记录进行写操作
```shell
SESSION1 対test_innodb_lock表的
mysql> UPDATEa=6这一行进行写操作，但是没有committest_innodb_lockSETb= ‘8976’ WHEREa= 6; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0
SESSION2 対test_innodb_lock表的a=4这一行进行写操作，没有阻塞！！！
SESSION1和SESSION2同时对不同的行进行写操作互不影响
mysql> UPDATE test_innodb_lock SET b = ‘Ringo’ WHERE a = 4;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
<a name="6d9018ac"></a>## 17.3.索引失效行锁变表锁```shell# SESSION1 执行SQL语句，没有执行commit# 由于`b`字段是字符串，但是没有加单引号导致索引失效mysql> UPDATE `test_innodb_lock` SET `a` = 888 WHERE `b` = 8000;Query OK, 1 row affected, 1 warning (0.00 sec)Rows matched: 1 Changed: 1 Warnings: 1# SESSION2 和SESSION1操作的并不是同一行，但是也被阻塞了？？？# 由于SESSION1执行的SQL索引失效，导致行锁升级为表锁mysql> UPDATE `test_innodb_lock` SET `b` = '1314' WHERE `a` = 1;ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
17.4.间隙锁的危害
什么是间隙锁
当我们用范围条件而不是相等条件检索数据，并请求共享或者排他锁时，InnoDB会给符合条件的已有数据记录的索引项加锁，对于键值在条件范文内但并不存在的记录，叫做”间隙(GAP)”
InnoDB也会对这个”间隙”加锁，这种锁的机制就是所谓的”间隙锁”
间隙锁的危害
因为Query执行过程中通过范围查找的话，他会锁定整个范围内所有的索引键值，即使这个键值不存在
间隙锁有一个比较致命的缺点，就是当锁定一个范围的键值后，即使某些不存在的键值也会被无辜的锁定，而造成在锁定的时候无法插入锁定键值范围内的任何数据。在某些场景下这可能会対性能造成很大的危害
17.5.如何锁定一行
**SELECT .....FOR UPDATE**在锁定某一行后，其他写操作会被阻塞，直到锁定的行被COMMIT
mysql``InnoDB引擎默认的修改数据语句，update``delete``insert都会自动给涉及到的数据加上排他锁，select语句默认不会加任何锁类型，如果加排他锁可以使用select ...for update语句，加共享锁可以使用**select ... lock in share mode**语句。所以加过排他锁的数据行在其他事务中是不能修改数据的，也不能通过for update和lock in share mode锁的方式查询数据，但可以直接通过select ...from...查询数据，因为普通查询没有任何锁机制
17.6.案例结论
InnoDB存储引擎由于实现了行级锁定，虽然在锁定机制的实现方面所带来的性能损耗可能比表级锁定会要更高一些，但是在整体并发处理能力要远远优于MyISAM的表级锁定的。当系统并发量较高的时候，InnoDB的整体性能和MyISAM相比就会有比较明显的优势
但是，InnoDB的行级锁定同样也有其脆弱的一面，当我们使用不当的时候，可能会让InnoDB的整体性能表现不仅不能比MyISAM高，甚至可能会更差
17.7.行锁分析
mysql> SHOW STATUS LIKE 'innodb_row_lock%';+-------------------------------+--------+| Variable_name | Value |+-------------------------------+--------+| Innodb_row_lock_current_waits | 0 || Innodb_row_lock_time | 124150 || Innodb_row_lock_time_avg | 31037 || Innodb_row_lock_time_max | 51004 || Innodb_row_lock_waits | 4 |+-------------------------------+--------+5 rows in set (0.00 sec)
対各个状态量的说明如下：
**Innodb_row_lock_current_waits**当前正在等待锁定的数量**Innodb_row_lock_time**从系统启动到现在锁定总时间长度（重要）**Innodb_row_lock_time_avg**每次等待所花的平均时间（重要）**Innodb_row_lock_time_max**从系统启动到现在等待最长的一次所花的时间**Innodb_row_lock_waits**系统启动后到现在总共等待的次数（重要）
尤其是当等待次数很高，且每次等待时长也不小的时候，就需要分析系统中为什么会有如此多的等待，然后根据分析结果着手制定优化策略
优化建议
- 尽可能让所有数据检索都通过索引来完成，避免无索引行锁升级为表锁
- 合理设计索引，尽量缩小锁的范围
- 尽可能较少检索条件，避免间隙锁
- 尽量控制事务大小，减少锁定资源量和时间长度
-
18.主从复制
18.1.复制基本原理
MySQL复制过程分为三步 Master将改变记录到二进制日志Binary Log。这些记录过程叫做二进制日志事件，Binary Log EventsSlave将Master的Binary Log Events拷贝到它的中继日志Replay LogSlave重做中继日志中的事件，将改变应用到自己的数据库中。MySQL复制是异步且串行化的18.2.复制基本原则
每个
Slave只有一个Master- 每个
Slave只能有一个唯一的服务器ID - 每个
Master可以有多个Salve18.3.一主一从配置
- 基本要求：
Master和Slave的MySQL服务器版本一致且后台以服务运行 主从配置都是配在[mysqld]节点下，都是小写
# docker创建mysql-slave1实例docker run -p 3307:3306 --name mysql-slave1 \-v /root/mysql-slave1/log:/var/log/mysql \-v /root/mysql-slave1/data:/var/lib/mysql \-v /root/mysql-slave1/conf:/etc/mysql \-e MYSQL_ROOT_PASSWORD=root \-d mysql:5.7
# Master配置[mysqld]server-id=1 # 必须log-bin=/var/lib/mysql/mysql-bin # 必须 启用二进制日志log-err=本地路径/mysql-err # 可选 启用错误日志basedir=本地路径 # 可选 根目录tmpdir=本地路径 # 可选 临时目录read-only=0 # 主机 读写都可以binlog-ignore-db=mysql # 可选 设置不要复制的数据库binlog-do-db=ww2 # 可选 设置需要复制的数据库
# Slave配置[mysqld]server-id=2 # 必须log-bin=/var/lib/mysql/mysql-bin
Master建立账户并授权给slave ```sql
1、GRANT REPLICATION SLAVE ON . TO ‘username’@’从机IP地址’ IDENTIFIED BY ‘password’;
mysql> GRANT REPLICATION SLAVE ON . TO ‘zhangsan’@’192.168.199.158’ IDENTIFIED BY ‘123456’; Query OK, 0 rows affected, 1 warning (0.01 sec)
2、刷新命令
mysql> FLUSH PRIVILEGES; Query OK, 0 rows affected (0.00 sec)
3、记录下File和Position
每次配从机的时候都要SHOW MASTER STATUS;查看最新的File和Position
mysql> SHOW MASTER STATUS; +—————————+—————+———————+—————————+—————————-+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +—————————+—————+———————+—————————+—————————-+ | mysql-bin.000001 | 602 | | mysql | | +—————————+—————+———————+—————————+—————————-+ 1 row in set (0.00 sec)
4. Slave从机配置```shellCHANGE MASTER TO MASTER_HOST='192.168.199.132',MASTER_USER='zhangsan',MASTER_PASSWORD='123456',MASTER_LOG_FILE='mysql-bin.File的编号',MASTER_LOG_POS=Position的最新值;
# 1、使用用户名密码登录进Mastermysql> CHANGE MASTER TO MASTER_HOST='192.168.199.132',-> MASTER_USER='zhangsan',-> MASTER_PASSWORD='123456',-> MASTER_LOG_FILE='mysql-bin.000001',-> MASTER_LOG_POS=602;Query OK, 0 rows affected, 2 warnings (0.02 sec)# 2、开启Slave从机的复制mysql> START SLAVE;Query OK, 0 rows affected (0.00 sec)# 3、查看Slave状态# Slave_IO_Running 和 Slave_SQL_Running 必须同时为Yes 说明主从复制配置成功！mysql> SHOW SLAVE STATUS\G*************************** 1. row ***************************Slave_IO_State: Waiting for master to send event # Slave待命状态Master_Host: 172.18.0.4Master_User: zhangsanMaster_Port: 3306Connect_Retry: 60Master_Log_File: mysql-bin.000001Read_Master_Log_Pos: 602Relay_Log_File: b030ad25d5fe-relay-bin.000002Relay_Log_Pos: 320Relay_Master_Log_File: mysql-bin.000001Slave_IO_Running: Yes # 必须同时为YesSlave_SQL_Running: Yes # 必须同时为YesReplicate_Do_DB:Replicate_Ignore_DB:Replicate_Do_Table:Replicate_Ignore_Table:Replicate_Wild_Do_Table:Replicate_Wild_Ignore_Table:Last_Errno: 0Last_Error:Skip_Counter: 0Exec_Master_Log_Pos: 602Relay_Log_Space: 534Until_Condition: NoneUntil_Log_File:Until_Log_Pos: 0Master_SSL_Allowed: NoMaster_SSL_CA_File:Master_SSL_CA_Path:Master_SSL_Cert:Master_SSL_Cipher:Master_SSL_Key:Seconds_Behind_Master: 0Master_SSL_Verify_Server_Cert: NoLast_IO_Errno: 0Last_IO_Error:Last_SQL_Errno: 0Last_SQL_Error:Replicate_Ignore_Server_Ids:Master_Server_Id: 1Master_UUID: bd047557-b20c-11ea-9961-0242ac120002Master_Info_File: /var/lib/mysql/master.infoSQL_Delay: 0SQL_Remaining_Delay: NULLSlave_SQL_Running_State: Slave has read all relay log; waiting for more updatesMaster_Retry_Count: 86400Master_Bind:Last_IO_Error_Timestamp:Last_SQL_Error_Timestamp:Master_SSL_Crl:Master_SSL_Crlpath:Retrieved_Gtid_Set:Executed_Gtid_Set:Auto_Position: 0Replicate_Rewrite_DB:Channel_Name:Master_TLS_Version:1 row in set (0.00 sec)
- 测试主从复制
```shell
Master创建数据库
mysql> create database test_replication; Query OK, 1 row affected (0.01 sec)
Slave查询数据库
mysql> show databases; +——————————+ | Database | +——————————+ | information_schema | | mysql | | performance_schema | | sys | | test_replication | +——————————+ 5 rows in set (0.00 sec)
6. 停止主从复制功能```shell# 1、停止Slavemysql> STOP SLAVE;Query OK, 0 rows affected (0.00 sec)# 2、重新配置主从# MASTER_LOG_FILE 和 MASTER_LOG_POS一定要根据最新的数据来配mysql> CHANGE MASTER TO MASTER_HOST='172.18.0.4',-> MASTER_USER='zhangsan',-> MASTER_PASSWORD='123456',-> MASTER_LOG_FILE='mysql-bin.000001',-> MASTER_LOG_POS=797;Query OK, 0 rows affected, 2 warnings (0.01 sec)mysql> START SLAVE;Query OK, 0 rows affected (0.00 sec)mysql> SHOW SLAVE STATUS\G*************************** 1. row ***************************Slave_IO_State: Waiting for master to send eventMaster_Host: 172.18.0.4Master_User: zhangsanMaster_Port: 3306Connect_Retry: 60Master_Log_File: mysql-bin.000001Read_Master_Log_Pos: 797Relay_Log_File: b030ad25d5fe-relay-bin.000002Relay_Log_Pos: 320Relay_Master_Log_File: mysql-bin.000001Slave_IO_Running: YesSlave_SQL_Running: YesReplicate_Do_DB:Replicate_Ignore_DB:Replicate_Do_Table:Replicate_Ignore_Table:Replicate_Wild_Do_Table:Replicate_Wild_Ignore_Table:Last_Errno: 0Last_Error:Skip_Counter: 0Exec_Master_Log_Pos: 797Relay_Log_Space: 534Until_Condition: NoneUntil_Log_File:Until_Log_Pos: 0Master_SSL_Allowed: NoMaster_SSL_CA_File:Master_SSL_CA_Path:Master_SSL_Cert:Master_SSL_Cipher:Master_SSL_Key:Seconds_Behind_Master: 0Master_SSL_Verify_Server_Cert: NoLast_IO_Errno: 0Last_IO_Error:Last_SQL_Errno: 0Last_SQL_Error:Replicate_Ignore_Server_Ids:Master_Server_Id: 1Master_UUID: bd047557-b20c-11ea-9961-0242ac120002Master_Info_File: /var/lib/mysql/master.infoSQL_Delay: 0SQL_Remaining_Delay: NULLSlave_SQL_Running_State: Slave has read all relay log; waiting for more updatesMaster_Retry_Count: 86400Master_Bind:Last_IO_Error_Timestamp:Last_SQL_Error_Timestamp:Master_SSL_Crl:Master_SSL_Crlpath:Retrieved_Gtid_Set:Executed_Gtid_Set:Auto_Position: 0Replicate_Rewrite_DB:Channel_Name:Master_TLS_Version:1 row in set (0.00 sec)
若有收获，就点个赞吧
0 人点赞
