共计 5298 个字符，预计需要花费 14 分钟才能阅读完成。
这篇文章给大家分享的是有关如何解决 mysql 主从复制中产生了锁的问题的内容。丸趣 TV 小编觉得挺实用的，因此分享给大家做个参考，一起跟随丸趣 TV 小编过来看看吧。
一套主主复制的 mysql 库产生了死锁，导致主从同步出现问题，
解决办法：是先 kill 掉了产生锁等待的那个服务器的 mysql 的 sql 进程，然后 start slave，就好了。
下面具体分析下相关知识点以及解决的过程：
一：mysql 主从复制的流程，以及相关的进程。
1）关于复制的步骤：
整体上来说，复制有 3 个步骤：
(1) master 将改变记录到二进制日志 (binary log) 中（这些记录叫做二进制日志事件，binary log events）；
(2) slave 将 master 的 binary log events 拷贝到它的中继日志(relay log)；
(3) slave 重做中继日志中的事件，将改变反映它自己的数据。
下图描述了复制的过程：
该过程的第一部分就是 master 记录二进制日志。在每个事务更新数据完成之前，master 在二日志记录这些改变。MySQL 将事务串行的写入二进制日志，即使事务中的语句都是交叉执行的。在事件写入二进制日志完成后，master 通知存储引擎提交事务。
下一步就是 slave 将 master 的 binary log 拷贝到它自己的中继日志。首先，slave 开始一个工作线程——I/ O 线程。I/ O 线程在 master 上打开一个普通的连接，然后开始 binlog dump process。Binlog dump process 从 master 的二进制日志中读取事件，如果已经跟上 master，它会睡眠并等待 master 产生新的事件。I/ O 线程将这些事件写入中继日志。
SQL slave thread（SQL 从线程）处理该过程的最后一步。SQL 线程从中继日志读取事件，并重放其中的事件而更新 slave 的数据，使其与 master 中的数据一致。只要该线程与 I / O 线程保持一致，中继日志通常会位于 OS 的缓存中，所以中继日志的开销很小。
此外，在 master 中也有一个工作线程：和其它 MySQL 的连接一样，slave 在 master 中打开一个连接也会使得 master 开始一个线程。复制过程有一个很重要的限制——复制在 slave 上是串行化的，也就是说 master 上的并行更新操作不能在 slave 上并行操作。
2）关于复制的进程：
MySQL 使用 3 个线程来执行复制功能, 其中 1 个在主服务器上，另两个在从服务器上。当发出 START SLAVE 时，从服务器创建一个 I / O 线程，以连接主服务器并让它发送记录在其二进制日志中的语句。
主服务器创建一个线程将二进制日志中的内容发送到从服务器。该线程可以识别为主服务器上 SHOW PROCESSLIST 的输出中的 Binlog Dump 线程。
从服务器 I / O 线程读取主服务器 Binlog Dump 线程发送的内容并将该数据拷贝到从服务器数据目录中的本地文件中，即中继日志。
第 3 个线程是 SQL 线程，是从服务器创建用于读取中继日志并执行日志中包含的更新。
有多个从服务器的主服务器创建为每个当前连接的从服务器创建一个线程；每个从服务器有自己的 I / O 和 SQL 线程。
3）如何找到具体的 sql 和 io 进程的 id 号。
system user 对应着从库的 sql 和 io 进程，因为我们的是主主复制，所以既有主服务器 Binlog Dump 线程，还有从库的 sql 和 io 进程，具体如下：
1）我们看到 Waiting for master to send event 的字样，说明这个进程是从库的 io 进程，因为从服务器 I / O 线程就是读取主服务器 Binlog Dump 线程发送的内容并将该数据拷贝到从服务器数据目录中的本地文件
2）我们看到 Slave has read all relay log; waiting for the slave I/O thread to update it，说明这个进程是从库的 sql 进程，因为从库 SQL 线程，就是读取中继日志并执行日志中包含的更新。
3）我们看到 Master has sent all binlog to slave; waiting for binlog to be updated，说明这个进程是主库的 Binlog Dump，因为主库的 Binlog Dump 就是将二进制日志中的内容（binlog)发送到从服务器. 并且主库的这个进程一般是由主库新建的特定的用户来完成的，我们这里是 info_syncer 用户。
mysql show processlist;
| 13910311 | system user | | NULL | Connect | -1650 | Slave has read all relay log; waiting for the slave I/O thread to update it
| 13418520 | system user | | NULL | Connect | 3638625 | Waiting for master to send event
| 13409506 | info_syncer | 192.168.0.243:36191 | NULL | Binlog Dump | 3690795 | Master has sent all binlog to slave; waiting for binlog to be updated
二：关于 mysql 死锁的查询和解决办法：
1）查询相关的锁：
在 5.5 中，information_schema 库中增加了三个关于锁的表（MEMORY 引擎）：
innodb_trx ## 当前运行的所有事务
innodb_locks ## 当前出现的锁
innodb_lock_waits ## 锁等待的对应关系
看一下表结构：
root@127.0.0.1 : information_schema 13:28:38 desc innodb_locks;
+————-+———————+——+—–+———+——-+
| Field | Type | Null | Key | Default | Extra |
+————-+———————+——+—–+———+——-+
| lock_id | varchar(81) | NO | | | |# 锁 ID
| lock_trx_id | varchar(18) | NO | | | |# 拥有锁的事务 ID
| lock_mode | varchar(32) | NO | | | |# 锁模式
| lock_type | varchar(32) | NO | | | |# 锁类型
| lock_table | varchar(1024) | NO | | | |# 被锁的表
| lock_index | varchar(1024) | YES | | NULL | |# 被锁的索引
| lock_space | bigint(21) unsigned | YES | | NULL | |# 被锁的表空间号
| lock_page | bigint(21) unsigned | YES | | NULL | |# 被锁的页号
| lock_rec | bigint(21) unsigned | YES | | NULL | |# 被锁的记录号
| lock_data | varchar(8192) | YES | | NULL | |# 被锁的数据
+————-+———————+——+—–+———+——-+
10 rows in set (0.00 sec)
root@127.0.0.1 : information_schema 13:28:56 desc innodb_lock_waits;
+——————-+————-+——+—–+———+——-+
| Field | Type | Null | Key | Default | Extra |
+——————-+————-+——+—–+———+——-+
| requesting_trx_id | varchar(18) | NO | | | |# 请求锁的事务 ID（也就是等待锁的 id）
| requested_lock_id | varchar(81) | NO | | | |# 请求锁的锁 ID
| blocking_trx_id | varchar(18) | NO | | | |# 当前拥有锁的事务 ID
| blocking_lock_id | varchar(81) | NO | | | |# 当前拥有锁的锁 ID
+——————-+————-+——+—–+———+——-+
4 rows in set (0.00 sec)
root@127.0.0.1 : information_schema 13:29:05 desc innodb_trx ;
+—————————-+———————+——+—–+———————+——-+
| Field | Type | Null | Key | Default | Extra |
+—————————-+———————+——+—–+———————+——-+
| trx_id | varchar(18) | NO | | | |# 事务 ID
| trx_state | varchar(13) | NO | | | |# 事务状态：
| trx_started | datetime | NO | | 0000-00-00 00:00:00 | |# 事务开始时间；
| trx_requested_lock_id | varchar(81) | YES | | NULL | |#innodb_locks.lock_id
| trx_wait_started | datetime | YES | | NULL | |# 事务开始等待的时间
| trx_weight | bigint(21) unsigned | NO | | 0 | |#
| trx_mysql_thread_id | bigint(21) unsigned | NO | | 0 | |# 事务线程 ID
| trx_query | varchar(1024) | YES | | NULL | |# 具体 SQL 语句
| trx_operation_state | varchar(64) | YES | | NULL | |# 事务当前操作状态
| trx_tables_in_use | bigint(21) unsigned | NO | | 0 | |# 事务中有多少个表被使用
| trx_tables_locked | bigint(21) unsigned | NO | | 0 | |# 事务拥有多少个锁
| trx_lock_structs | bigint(21) unsigned | NO | | 0 | |#
| trx_lock_memory_bytes | bigint(21) unsigned | NO | | 0 | |# 事务锁住的内存大小（B）
| trx_rows_locked | bigint(21) unsigned | NO | | 0 | |# 事务锁住的行数
| trx_rows_modified | bigint(21) unsigned | NO | | 0 | |# 事务更改的行数
| trx_concurrency_tickets | bigint(21) unsigned | NO | | 0 | |# 事务并发票数
| trx_isolation_level | varchar(16) | NO | | | |# 事务隔离级别
| trx_unique_checks | int(1) | NO | | 0 | |# 是否唯一性检查
| trx_foreign_key_checks | int(1) | NO | | 0 | |# 是否外键检查
| trx_last_foreign_key_error | varchar(256) | YES | | NULL | |# 最后的外键错误
| trx_adaptive_hash_latched | int(1) | NO | | 0 | |#
| trx_adaptive_hash_timeout | bigint(21) unsigned | NO | | 0 | |#
+—————————-+———————+——+—–+———————+——-+
22 rows in set (0.01 sec)
mysql show processlist; ## 可以看出来，
或者：
mysql select concat(KILL ,id,) from information_schema.processlist where user= root
+————————+
| concat(KILL ,id,) |
+————————+
| KILL 3101; |
| KILL 2946; |
+————————+
2 rows in set (0.00 sec)
批量 kill 多个进程。
mysql select concat(KILL ,id,) from information_schema.processlist where user= root into outfile /tmp/a.txt
Query OK, 2 rows affected (0.00 sec)
感谢各位的阅读！关于“如何解决 mysql 主从复制中产生了锁的问题”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，让大家可以学到更多知识，如果觉得文章不错，可以把它分享出去让更多的人看到吧！
