Транзакционная база данных и предотвращение взаимоблокировок

Question

Я занимаюсь разработкой облачных сервисов, в которых синхронизирует локальные базы данных (заказ с POS-системой) в центральную удаленную базу данных. Наша удаленная база данных использует последнюю версию mysql 5.6 с движком innoDB для каждой из таблиц. В основном он работает как транзакционная база данных, в которой много транзакций, в основном записывающих (например, INSERT и UPDATE), а иногда и при чтении отчетов и т. Д. Неизбежно мы столкнулись с нашим первым тупиком базы данных (обратите внимание, что это произошло до обновления mysql 5.6), и мое понимание причины тупика может быть там, где есть два соединения, пытающихся либо ПРОЧИТАТЬ, либо НАПРАВЛЯТЬ в ряд одновременно. Я также понимаю, что взаимоблокировки являются общими и требуют правильного кода, чтобы попробовать/поймать тупики, в которых, я считаю, мне удалось выполнить. Для того, чтобы смягчить тупики я думал о создании 2 базы данных, которые являются зеркалом друг друга А) базы данных, которая записывается в б) База данных, которая считывается

В основном в синхронизации с локального на удаленный будет писать в базу данных A, а использование rsync в фоновом режиме будет отображать базу данных A-B, какая база B будет использоваться для чтения и запроса отчетов, поскольку rsync не использует подключения к базе данных для чтения данных для синхронизации.

Вопрос в том, будет ли эта структура работать с точки зрения устранения взаимоблокировок и иметь какие-либо существенные проблемы с производительностью на сервере?

Надеюсь, мой вопрос имеет смысл в том, чего я пытаюсь достичь.

Заранее спасибо.

Answer 1

Репликация базы данных может помочь в повышении производительности и доступности. Но перед началом репликации баз данных могут возникнуть различные аспекты.

Я предполагаю, что вы включили регуляторы для регистрации медленных запросов. Я бы рекомендовал проанализировать и посмотреть, есть ли возможности оптимизировать вашу проблему, вызвав запросы. Другое дело, хотя не всегда легко повторно моделировать данные, но иногда это может помочь. Убедитесь, что ваши запросы на отчетность используют индексы по желанию. Вы также можете изучить раздел данных.

В какой-то момент, в зависимости от объема данных и требований к отчетности, вы можете очень хорошо подумать об использовании баз данных NoSQL для аналитических данных.

Answer 2

Мертвые блоки не являются результатом двух подключений, которые пытаются записать в одну строку одновременно. Это немного сложнее, чем это.

Род сценария, который будет производить в тупик идет что-то вроде этого:

Есть два ресурса (может быть две строки в таблице, две таблицы, два файла и т.д., которые мы будем определять, как «A "и" B ").

1. Соединение # 1 блокировки ресурсов "A"
2. Соединение # 2 замка ресурса "B"
3. Connection # 1 переходит к попытке заблокировать "B" (в то же время удерживая его блокировку на "A") , Поскольку соединение №2 заблокировано «В», соединение №1 ожидает, что блокировка будет освобождена.
4. Соединение № 2 (все еще удерживающее его блокировку на «В») пытается заблокировать «А». Поскольку соединение №1 заблокировано, соединение №2 ожидает выхода этой блокировки.

Оба соединения теперь находятся в состоянии, когда каждый ждет на другом, чтобы освободить его замок; они зашли в тупик. Тупик можно сломать только одним соединением, прервав его действие, чтобы освободить его замок, позволяя другому закончить.

Такая вещь может происходить на любом уровне детализации в базе данных от строк до страниц до таблиц и может происходить с данными или индексами. Оставляя его в базе данных, чтобы сделать свою оптимистичную блокировку, вы обычно получаете максимальную производительность, но может привести к взаимоблокировкам. Возможно, вам понадобится сделать некоторые из ваших вложений/обновлений в сериализованных транзакциях (хотя это произойдет при снижении производительности). Рассмотрите транзакции, которые касаются более чем одной таблицы в качестве потенциальных участников сценария взаимоблокировки.

Answer 3

Откажитесь от полного устранения взаимоблокировок. Сосредоточьтесь на «смягчении» их.

При необходимости, прикоснитесь к таблицам и строкам в каноническом порядке. Простым примером является сортировка элементов в предложении IN. Я думаю, что следующий может вызвать затор:

UPDATE ... WHERE id IN (3,7) -- in one connection 
UPDATE ... WHERE id IN (7,3) -- in another connection 

Но если вы отсортировали идентификаторы во всех сделках, худшее, вы получите то, что одно соединение будет ждать другой, чтобы снять блокировку строки. (Это где innodb_lock_wait_timeout входит в игру.)

Другой пример включает в себя

BEGIN; 
SELECT ... FROM table1 FOR UPDATE; 
SELECT ... FROM table2 FOR UPDATE; 
... 
COMMIT; 

Конечно, возможны случаи, когда вы не можете предсказать, какие идентификаторы или таблицы необходимы в транзакции, так что вы не можете сделать некоторые простой вид. Вот почему вы должны быть готовы поймать тупики.

Просто повторите транзакцию, когда вы зашли в тупик. Хорошо, это может быть не просто, если у вас есть другой код, перемеженный в транзакции.