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

Question

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

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

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

当我们将mysql连接器连接到我们的生产数据库时，就产生了一个锁，我们的整个系统都崩溃了。意识到这一点后，我们很快停止了Kafka，并移除了连接器，但是锁仍然在增加，只有在我们停止所有新的查询，停止生产代码运行并手动终止进程之后，锁才得以解决。

这种情况的潜在原因是什么，我们如何预防这种情况？

Answer 1

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

Answer 2

如果锁定是一个问题，并且您无法在锁定与一致性之间进行权衡，那么请查看快照。锁定。模式config选项。

Answer 3

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

我的意思是下面的顺序是我相信发生的：

>

Debezium会在你的两张桌子上启动桌子锁

该应用程序仍在工作，并且正在尝试执行访问这些锁定表的查询。查询开始等待释放锁。他们最多会等待1年（这是默认的lock\u wait\u timeout值）

当你花上几分钟试图找出你的网站没有响应的原因时，大量被阻止的查询就会累积起来。可能多达最大连接数。在所有允许的连接都充满了阻塞的查询之后，应用程序根本无法连接到MySQL

最后，停止尝试读取数据初始快照的Debezium进程。它释放了表锁

当表锁被释放时，等待的查询可以立即继续。

• 但是，如果它们是INSERT/UPDATE/DELETE/REPLACE，或者如果它们是SELECT... FOR UPDATE或其他锁定语句，它们中的许多确实也需要获取锁。
• 因为有这么多查询排队，所以它们更有可能请求重叠的锁，这意味着它们必须等待彼此完成并释放锁。
• 另外，因为有数百个查询同时执行，它们对CPU等系统资源造成了过大的负担，导致系统html" target="_blank">负载过高，这也使它们都变慢了。因此，查询完成需要更长时间，因此如果它们相互阻塞，它们必须等待更长时间。

与此同时，应用程序仍在尝试接受请求，因此正在添加更多要执行的查询。他们还面临排队和资源枯竭的问题。

最终你会停止应用程序，这至少允许等待的查询队列逐渐完成。随着系统负载的下降，MySQL能够更有效地处理查询，并很快完成所有查询。

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

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