Репликация с большим количеством записей временных таблиц - PullRequest
1 голос
/ 22 сентября 2008

У меня есть база данных, которую я собираюсь реплицировать по причинам резервного копирования (в данный момент производительность не является проблемой).

Мы правильно настроили репликацию, протестировали ее, и все было в порядке.

Затем мы поняли, что он реплицирует все записи во временные таблицы, что фактически означало, что репликация данных за один день заняла почти два часа для неработающего ведомого устройства.

Причина этого в том, что мы пересчитываем некоторые данные в нашей базе данных с помощью cronjob каждые 15 минут, чтобы обеспечить их синхронизацию (в общей сложности это занимает ~ 3 минуты, поэтому эти операции недопустимы во время веб-запроса; вместо этого мы просто сохраняем изменения, не пытаясь что-либо пересчитать во время веб-запроса, а затем выполняем всю работу навалом). Для эффективной обработки этих данных мы используем временные таблицы (поскольку существует много взаимозависимостей).

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

Более серьезная проблема состоит в том, что ведомое устройство может легко догнать менее чем за полчаса, если бы не было всего этого повторного вычисления (что он делает один за другим, поэтому нет никакой пользы для восстановления данных каждые 15 минут ... и вы можете буквально увидеть, что он застрял, скажем, в 1115, только чтобы быстро наверстать упущенное и застрял в 1130 и т. д.).

Одно из решений, которое мы придумали, состоит в том, чтобы убрать всю эту перерасчет из реплицированной базы данных, чтобы ведомый не воспроизводил ее. Но у него есть недостатки, заключающиеся в том, что нам придется сокращать таблицы, которые он в конечном итоге обновляет, что делает нашего ведомого по сути «кастрированным», т.е. нам придется пересчитать все на нем, прежде чем мы сможем его использовать.

У кого-нибудь была похожая проблема и / или как бы вы ее решили? Я что-то упускаю из виду?

Ответы [ 2 ]

3 голосов
/ 26 сентября 2008

Я придумала решение. Он использует replicate-do-db, упомянутый Ником. Запишите это здесь на случай, если у кого-то возникла подобная проблема.

Проблема с использованием только опций replicate- (wild-) do * в этом случае (как я уже говорил, мы используем временные таблицы для повторного заполнения центральной таблицы) в том, что вы либо игнорируете временные таблицы, либо повторно заполняете центральную без данных (что вызывает дальнейшие проблемы, поскольку все запросы, основанные на актуальности центральной таблицы, приведут к разным результатам), или вы игнорируете центральную таблицу, которая имеет аналогичную проблему. Не говоря уже о том, что вы должны перезапустить mysql после добавления любого из этих параметров в my.cnf. Мы хотели что-то, что охватывало бы все эти (и будущие) случаи без необходимости какого-либо повторного запуска.

Итак, мы решили разделить базу данных на базы данных «настоящая» и «рабочая область». Реплицируется только «реальная» база данных (я думаю, вы могли бы принять решение о соглашении имен таблиц, которые будут использоваться для синтаксиса replicate-wild-do-table).

Вся работа с временными таблицами происходит в db "workarea", и во избежание упомянутой выше проблемы с зависимостями мы не будем заполнять центральную таблицу (которая находится в "real" db) INSERT ... SELECT или RENAME TABLE, но лучше запросить таблицы tmp, чтобы сгенерировать разницу в живой таблице (т. Е. Сгенерировать операторы INSERT для новых строк, DELETE для старых и обновить при необходимости).

Таким образом, единственные запросы, которые реплицируются, это именно те обновления, которые требуются, ничего больше, т.е. некоторые (большинство?) запросов на повторные вычисления, которые выполняются каждые пятнадцать минут, могут даже не попасть в подчиненные, а те, которые выполняются, будут минимальными и совсем не вычислительными, просто простыми INSERT и DELETE.

2 голосов
/ 22 сентября 2008

В MySQL, начиная с 5.0, я полагаю, вы можете использовать символы подстановки таблиц для репликации определенных таблиц. Существует ряд параметров командной строки, которые можно установить, но вы также можете сделать это через конфигурационный файл MySQL.

[mysqld]
replicate-do-db    = db1
replicate-do-table = db2.mytbl2
replicate-wild-do-table= database_name.%
replicate-wild-do-table= another_db.%

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

...