Я просто потратил часы на создание нового сервера базы данных, чтобы заменить 2 отказавших сервера из mysqldump файл, созданный месяц назад, затем использовал бинарные журналы моего сервера, чтобы mysqldump до настоящего времени. Теперь, когда у меня есть этот новый сервер базы данных в сети и он работал в течение нескольких дней, мне нужно завершить настройку сервера и повторно реализовать стратегию резервного копирования.
Мне нужно подключить (по крайней мере) одно подчиненное устройство репликации MySQL к новому серверу, а также начать создавать пригодные для использования резервные копии на случай, если что-то снова выйдет из строя.
Прежде чем двигаться дальше:
innodb-file-per-table вариант в my.cnf перед импортом всех данных. Двоичный журнал теперь включен на новом сервере MySQL, но опция inno file per table в значительной степени не исправляет, пока я не смогу импортировать еще одну логическую резервную копию (я, вероятно, в конечном итоге подниму второй подчиненный сервер и продвигаю первый подчиненный сервер чтобы освоить и отказаться от текущего мастера - поскольку конфигурация просто не там, где мне нужно).Итак, проблема:
Мне нужно сделать резервную копию сервера MySQL, но я не могу отключить новый сервер MySQL. Мне нужно продолжать принимать записи и обслуживать чтение с минимальным временем простоя или без него. Это требование «минимальное время простоя» определяется как менее 10 минут. Мои данные в настоящее время используют около 100 ГБ места на сервере (файлы данных mysql), а логические резервные копии составляют около 50 ГБ (это много индексов ... хаха). Меня не волнует эта логическая резервная копия, или копия файлов данных из каталога данных MySQL. Я могу создать логическую резервную копию ведомого устройства после того, как подключу его к сети.
И вопрос:
Как бы вы создали эту необходимую резервную копию? Я знаю, что это непросто, многие скажут, что это невозможно. Но я отказываюсь верить, что это невозможно, что должен быть способ сделать это.
Замечание о сервере: Он работает под управлением Ubuntu 10.04, MySQL 5.1.41, а файловая система, в которой хранятся данные, - ext3. Сервер работает в облаке Rackspace, поэтому файловая система в значительной степени «такая, какая она есть», если я не смогу повторно разбить корневое устройство и переразбить его с другой файловой системой (возможно, XFS?), Чтобы сделать снимок.
Я читал о Инструмент Perconas XtraBackup но это работает только для таблиц InnoDB. У них есть инструмент MyISAM, но я действительно не понимаю, как он может (или даже если он работает) работать вместе с XtraBackup для создания полностью согласованной резервной копии.
Я читал о mysqlhotcopy но он работает только с таблицами MyISAM.
Очевидно я знаю о mysqldump, но (также очевидно) проблема здесь в создании согласованной резервной копии без блокировки всего сервера базы данных на количество часов, которое потребуется для вывода всего этого файла резервной копии sql.
Что касается XtraBackup или, точнее, innobackupex, ознакомьтесь с этим объяснение
Отрывок:
Программа innobackupex добавляет больше удобства и функциональности, также позволяя создавать резервные копии таблиц MyISAM и файлов .frm. Он запускает xtrabackup, ждет, пока не закончит копирование файлов, а затем выдает команду FLUSH TABLES WITH READ LOCK, чтобы предотвратить дальнейшие изменения данных MySQL и сбросить все таблицы MyISAM на диск. Он удерживает эту блокировку, копирует файлы MyISAM, а затем снимает блокировку.
Резервные копии таблиц MyISAM и InnoDB в конечном итоге будут согласованы друг с другом, потому что после процесса подготовки (восстановления) данные InnoDB откатываются до точки, в которой резервное копирование завершено, а не откатывается до точки, в которой она началась. Этот момент времени совпадает с местом, где были взяты FLUSH TABLES WITH READ LOCK, поэтому данные MyISAM и подготовленные данные InnoDB синхронизированы.
Надеюсь это поможет.
Ура
Это требование «минимальное время простоя» определяется как менее 10 минут.
ОК 2 очевидных решения:
1) настроить зеркальную файловую систему для хранения таблиц данных mysql. Если вы хотите сделать резервную копию, выключите mysqld, удалите одно из зеркал из набора, затем снова запустите mysqld, затем перемонтируйте диск, который вы только что вынули из зеркала, в другое место и либо скопируйте необработанные файлы, либо запустите создайте второй экземпляр mysld (другой порт, другой путь к файлам) и запустите там mysqldump. По завершении выключите 2-й экземпляр mysqld и снова поместите диск в набор зеркал (система RAID должна обрабатывать обновление диска перед его чтением из зеркала, поэтому нет необходимости отключать первый экземпляр на этом этапе).
2) Аналогично пункту 1, но реализуйте зеркалирование на уровне приложения - настройте текущий экземпляр mysqld как ведущий, настройте второй экземпляр как ведомый. Если вы хотите создать резервную копию, остановите репликацию на ведомом устройстве, сделайте резервную копию, а затем снова запустите репликацию (0 простоев).
Поскольку это облачная инфраструктура, и вы не можете делать многие вещи, которые вы можете делать на выделенном сервере (например, перераспределение / изменение файловых систем / использование lvm), поищите у поставщика облачных услуг решение для создания снимков / резервного копирования.
Быстрый поиск в Google указал мне на это: http://www.rackspace.com/cloud/blog/2010/06/16/introduction-cloud-servers-snapshots-to-cloud-files/
Проверьте это, это может быть лучшим решением вашей проблемы.