Возможно ли форк MySQL данных?

Question

Я восстанавливаю базу данных mysql с помощью perl на удаленном сервере с около 30 миллионами записей. Это занимает> 2 дня и, глядя на мои сетевые подключения, я не полностью использую пропускную способность восходящей линии связи. Мне нужно будет сделать это по крайней мере 1 раз в неделю. Есть ли способ разветвить mysqldump (я использую Perl), чтобы я мог в полной мере использовать мою пропускную способность (я не против, если я захлебнулся немного ... Мне просто нужно сделать это быстрее).

Answer 1

Не можете ли вы загрузить весь дамп на удаленный сервер и начать восстановление там?

Answer 2

Насколько велика ваша база данных?Какие таблицы вы используете?

Большой риск при создании резервных копий с использованием mysqldump связан с блокировкой таблиц и обновлениями таблиц в процессе резервного копирования.

Процесс резервного копирования mysqldump в основном работает следующим образом:следует:

For each table {
   Lock table as Read-Only
   Dump table to disk
   Unlock table
}

Опасность заключается в том, что если вы выполняете запрос INSERT / UPDATE / DELETE, который затрагивает несколько таблиц во время выполнения резервной копии, ваша резервная копия может не захватить результаты вашего запроса должным образом.Это очень реальный риск, когда резервное копирование занимает несколько часов и вы имеете дело с активной базой данных.Представьте себе - ваш код выполняет серию запросов, которые обновляют таблицы A, B и C. В процессе резервного копирования в настоящее время заблокирована таблица B.

• Обновление A не будет зафиксировано, поскольку эта таблица быларезервное копирование уже выполнено.
• Обновление для B не будет записано, поскольку таблица в данный момент заблокирована для записи.
• Обновление для C будет записано, поскольку резервная копия еще не достигла C.

Это простой способ уничтожить ссылочную целостность в вашей базе данных.

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

Кроме того - здесь должно быть что-то не так.В предыдущей компании мы выполняли еженедельное резервное копирование 450 ГБ Mysql (самая большая таблица имела 150M строк), и для резервного копирования потребовалось менее 6 часов.

Две мысли:

1. У вас есть ведомая база данных?Оттуда запустите резервное копирование - остановите репликацию (предотвращая риск RW), запустите резервное копирование, перезапустите репликацию.
2. Используют ли ваши таблицы InnoDB?Рассмотрите возможность инвестирования в InnoDBhotbackup , которая решает эту проблему, поскольку в процессе резервного копирования используется ведение журнала, которое является частью механизма хранения InnoDB.

Answer 3

MK-параллельный-дамп и MK-параллельный-восстановления предназначены для того, чтобы делать то, что вы хотите, но в моем тестировании MK-параллельный-дамп был на самом деле медленнее, чем простой старый mysqldump,Ваш пробег может варьироваться.

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

Первое предостережение: mk -rallel- * записывает кучу файлов, и выяснить, когда безопасно начинать отправлять их (и когда вы закончите получать их), может быть немного сложно.Я полагаю, что это оставлено для читателя как упражнение, извините.

Второе предостережение: mk -rallel-dump специально объявлен как не предназначенный для резервного копирования.Потому что «Во время этого выпуска есть ошибка, которая мешает правильной работе --lock-таблиц», это действительно полезно только для баз данных, которые, как вы знаете, не изменится, например, для ведомого устройства, на котором вы можете ОСТАНОВИТЬ SLAVE без каких-либо последствийи затем НАЧАТЬ РАБОТУ после выполнения mk-parallel-dump.

Я думаю, что лучшее решение, чем распараллеливание дампа, может быть следующим:

Если вы выполняете свой mysqldump еженедельно, вы можете просто сделать это один раз (сбросить с помощью --single-транзакции (что вы должны делать в любом случае) и --master-data = n), а затем запустить ведомое устройство, которое подключается через туннель ssh к удаленному мастеру, поэтомураб постоянно обновляется.Недостатком является то, что если вы хотите клонировать локальную копию (возможно, для создания резервной копии), вам понадобится достаточно диска для хранения дополнительной копии.Преимущество состоит в том, что недельный журнал репликации (на основе запросов), вероятно, немного меньше, чем повторная отправка данных, а также он поступает постепенно, поэтому вы не забиваете свой канал.

Answer 4

Восстановление mysqldump - это просто выполнение длинной серии команд, которые восстановят вашу базу данных с нуля. Если путь выполнения для этого есть; 1) отправить команду 2) удаленная система выполняет команду 3) удаленная система отвечает, что команда выполнена 4) отправить следующую команду, тогда вы проводите большую часть времени в ожидании задержки в сети.

Я знаю, что большинство хостов SQL позволяют загружать файл дампа специально, чтобы избежать тех времен восстановления, о которых вы говорите. Компания, которая получает мои деньги каждый месяц, даже имеет веб-форму, которую вы можете использовать для восстановления базы данных из файла, который был загружен через sftp. Изучите документацию вашего хостинга. У них должно быть что-то похожее. Если ничего другого (и вам удобно в командной строке), вы можете загрузить его прямо в свою учетную запись и сделать это из оболочки.