生产中rds的Mysql debezium连接器导致死锁

Question

我们正在创建一个从RDS中的Mysql到elastic search的数据管道，用于创建搜索索引，并为此使用debezium cdc及其mysql源和弹性接收器连接器。

现在，由于mysql在rds中，我们必须向mysql用户授予对我们想要的cdc的两个表的锁表权限，如文档中所述。

我们也有各种其他mysql用户执行事务，这些事务可能需要这两个表中的任何一个。

一旦我们将mysql连接器连接到我们的生产数据库，就会创建一个锁，整个系统就会宕机，在意识到这一点后，我们很快停止了kafka并移除了连接器，但锁仍在增加，只有在我们停止运行生产代码并手动终止进程来停止所有新的查询之后，锁才能得到解决。

可能导致这种情况的潜在原因是什么?我们如何防止这种情况？

Answer 1

我只是猜测，因为我不知道你的查询流量。我假设您看到的增加的锁是等待表锁释放的查询的积压。

我的意思是下面的序列是我认为发生的：

1. Debezium在您的两个表上启动表锁。
2. 应用程序仍在运行，并且它正在尝试执行访问这些锁定表的查询。查询开始等待锁被释放。
3. 当你花几分钟试图弄清楚你的站点没有响应的原因时，大量阻塞的查询会累积起来。可能和max_connections一样多。当所有允许的连接都被阻塞的查询填满后，应用程序根本无法连接到MySQL。
4. 最终停止了尝试读取其初始数据快照的Debezium进程。当表锁被释放时，它释放它的表locks.
5. Immediately，等待的查询可以继续。

- But many of them do need to acquire locks too, if they are INSERT/UPDATE/DELETE/REPLACE or if they are SELECT ... FOR UPDATE or other locking statements. 
- Since there are so many of these queries queued up, it's more likely for them to be requesting locks that overlap, which means they have to wait for each other to finish and release their locks.
- Also because there are hundreds of queries executing at the same time, they are overtaxing system resources like CPU, causing high system load, and this makes them all slow down too. So it will take longer for queries to complete, and therefore if they are blocked each other, they have to wait longer.

​

1. 同时，应用程序仍在尝试接受请求，因此添加了更多要执行的查询。它们还受到您停止应用程序的排队和资源exhaustion.
2. Eventually的影响，这至少允许等待查询的队列逐渐完成。随着系统负载的降低，MySQL能够更有效地处理查询，并很快完成所有查询。

另一个答案建议将读取副本用于Debezium快照，这个建议很好。如果您的应用程序可以在一段时间内从主MySQL实例读取数据，那么在Debezium锁定副本实例时，不会阻塞副本上的任何查询。最终，Debezium将完成读取所有数据，并释放锁，然后继续只读取binlog。然后，应用程序可以恢复使用副本作为读取实例。

如果binlog使用GTID，您应该能够让像Debezium这样的CDC工具从副本服务器读取快照，然后在完成后，切换到主服务器来读取binlog。但是如果你不使用GTID，那就有点棘手了。该工具必须知道与副本上的快照对应的主服务器上的binlog位置。

Answer 2

如果锁定有问题，并且您无法在锁定和一致性之间进行权衡，那么请查看snapshot.locking.mode配置选项。

Answer 3

使用副本来防止lock table语句被执行，为什么debezium需要lock table？所有CDC工具都从bin日志中获取事件。