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

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

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

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

Вторая оговорка: mk-parallel-dump специально объявляется как не резервная копия. Потому что "Во время этого выпуска есть ошибка, которая предотвращает правильную работу -lock-таблиц", она действительно полезна только для баз данных, которые, как вы знаете, не будут меняться, например, подчиненный, на котором вы можете STOP SLAVE без каких-либо последствий, а затем START SLAVE после выполнения mk-parallel-dump.

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

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

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

Большой риск при резервном копировании с использованием 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.

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

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

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

Две мысли:

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

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

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