Я только догадываюсь, потому что я не знаю ваш запрос трафика. Я бы предположил, что количество обнаруженных вами блокировок увеличилось в результате невыполнения запросов, которые ожидали освобождения блокировок таблицы.
Я имею в виду следующую последовательность:* Debezium запускает блокировку таблиц на ваших двух столах.
Приложение все еще работает и пытается выполнить запросы, которые обращаются к этим заблокированным таблицам. Запросы начинаются в ожидании снятия блокировки. Они будут ждать до 1 года (это значение по умолчанию
lock_wait_timeout). Когда вы потратите несколько минут, пытаясь выяснить, почему ваш сайт не отвечает, накапливается большое количество заблокированных запросов. Потенциально столько, сколько
max_connections. После того, как все разрешенные соединения заполнены заблокированными запросами, приложение вообще не сможет подключиться к MySQL. Наконец, вы останавливаете процесс Debezium, который пытается прочитать свой первоначальный снимок данных. Он снимает свои блокировки таблиц.
Сразу же после снятия блокировок таблицы ожидающие запросы могут продолжаться.
- Но многим из них тоже нужно получать блокировки, если они являются INSERT / UPDATE / DELETE / REPLACE или если они SELECT ... FOR UPDATE или другие операторы блокировки.
- Поскольку таких запросов в очереди очень много, они с большей вероятностью будут запрашивать перекрывающиеся блокировки, что означает, что им придется ждать завершения друг друга и снимать блокировки.
- Кроме того, поскольку одновременно выполняются сотни запросов, они перегружают системные ресурсы, такие как ЦП, вызывая высокую нагрузку на систему, что также замедляет их работу. Таким образом, для выполнения запросов потребуется больше времени, и поэтому, если они заблокированы друг для друга, им придется ждать дольше.
Между тем приложение все еще пытается принимать запросы,и поэтому добавляет больше запросов для выполнения. Они также подвержены очереди и исчерпанию ресурсов.
В конце концов вы останавливаете приложение, что по крайней мере позволяет постепенно завершать очередь ожидающих запросов. Когда нагрузка на систему снижается, MySQL может обрабатывать запросы более эффективно и довольно быстро завершает их.
Предложение другого ответа использовать реплику чтения для снимка Debezium является хорошим. Если ваше приложение может некоторое время читать из основного экземпляра MySQL, тогда никакие запросы не будут заблокированы для реплики, пока Debezium заблокирует ее. В конце концов, Debezium завершит чтение всех данных и снимет блокировки, а затем перейдет к чтению только binlog. Затем приложение может возобновить использование реплики в качестве экземпляра для чтения.
Если в вашем бинлоге используется GTID, вы сможете настроить инструмент CDC, такой как Debezium, для чтения снимка из реплики, а затем, когда это будет сделано, переключитесь намастер, чтобы прочитать журнал. Но если вы не используете GTID, это немного сложнее. Инструмент должен знать позицию binlog на ведущем устройстве, соответствующую снимку на реплике.