Оптимальный способ создания резервных копий MySQL для довольно больших баз данных (MyISAM / InnoDB)


8

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

К сожалению, мы недавно попали в стену из-за объема трафика, поэтому я настроил другой главный сервер, чтобы облегчить чтение / резервное копирование.

Сейчас я просто использую mysqldump с несколькими аргументами, и это хорошо ... до сих пор. Очевидно, что mysqldump - медленный и быстрый метод, однако я считаю, что мы переросли его использование. Теперь мне нужна хорошая альтернатива, и я изучал возможность использования утилиты Maatkits mk -rallel -dump или решения для создания снимков LVM.

Краткая короткая версия:

  • У меня довольно большие базы данных MySQL, мне нужно сделать резервную копию
  • Текущий метод, использующий mysqldump, неэффективен и медленен (вызывает проблемы)
  • Рассматривая что-то вроде снимков mk -rallel-dump или LVM

Буду признателен за любые рекомендации или идеи - так как я должен заново делать то, что мы делаем, я скорее делаю это правильно / наиболее эффективно :).

Ответы:


5

Я имел хороший успех с репликацией MySQL и ночными архивами. Для меньшей базы данных, базы данных mysql и схемы я использую комбинацию скриптов, разработанных для использования mysqlhotcopy и mysqldump.

Горячее резервное копирование InnoDB - отличный коммерческий продукт, но я не уверен, как он обрабатывает смешанные таблицы в одной базе данных. Рекомендация pQd для XtraBackup может быть хорошей для сравнения с этим.

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

Также примечательно, что это старая тема. Между книгой по высокопроизводительной MySQL , руководством по MySQL и предыдущими вопросами по ServerFault - это исчерпано в общих чертах. Видеть:


+1; с myisam вы никогда не узнаете, есть ли у вас логически согласованное резервное копирование [взято lvm / mysqldump / from lave] или нет. возможно, если ваше приложение меняется только в рабочее время - вы можете безопасно сбросить его ночью, иначе - вы никогда не уверены и никакой метод не поможет.
PQD

Я думаю, что вы правы в смешивании решений. Как упомянуто в ответе pQd, я, вероятно, сделаю снимки LVM и посмотрю на утилиту xtrabackup (говорит, что она может обрабатывать смешанные таблицы). Я посмотрел в горячую резервную копию InnoDB, однако я всегда один для проектов с открытым исходным кодом. Спасибо за ссылки, я посмотрел 2 из них, но ответы довольно общие / не решают проблемы, которые у меня есть / они имеют в виду не "обычные" и "обычные" базы данных.
WinkyWolly

4

xtrabackup - хотя бы для innodb.


Интересно, однако, что я хотел бы более изящное решение, чтобы не беспокоиться о моем смешении таблиц InnoDB / MyISAM.
WinkyWolly

xtrabackup поставляется со сценарием, который также может помочь вам делать резервные копии myisams, но посмотрите мой комментарий под постом Уорнера
pQd

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

3

Наиболее распространенным способом решения этой проблемы является настройка другого сервера MySQL, который может даже находиться на той же машине, и запуск репликации master / slave. Затем вы можете выполнить резервное копирование на ведомом устройстве, с нулевым воздействием на ведущее устройство.


0

На EC2 EBS я сейчас использую xfs_freeze. Я рассматриваю возможность переключения на xtrabackup в какой-то момент, но когда я дал ему первый тестовый запуск, он был очень и очень жадным к процессору.


К сожалению, сейчас я использую XFS только на медиа-серверах, так что это не вариант. Какой опыт (кроме загрузки процессора, может быть, более подробно?) У вас был с xtrabackup? Вы резервировали чистые таблицы InnoDB или их комбинацию?
WinkyWolly

Мое самое большое сомнение заключалось в том, что он жевал процессор в течение 30 минут после завершения (резервное копирование базы данных объемом около 35 ГБ), делая сервер БД лишь незначительно работоспособным - определенно не то, что я мог бы запустить на рабочем мастере. , Я фактически уже преобразовал мои оставшиеся несколько таблиц MyISAM в InnoDB частично для целей этого. Я думаю, что, вероятно, было бы нормально работать на слейве, если это не приводит к существенному отставанию репликации.
user5336

0

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


0

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

    mysql -u root --password=<password> --database=db_name -B -N -e "SHOW TABLES" | awk '!/not_this_db/ && !/or_this_one/ && /^[a-z]/ {print "ALTER TABLE", $1, "ENGINE=INNODB;"}' | mysql -u root --password=<password> --database=db_name

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

Затем с помощью xtrabackup скопируйте всю базу данных прямо на другой сервер, не блокируя таблицы или не используя слишком много дискового ввода-вывода (после настройки ключей ssh ​​rsa):

innobackupex --throttle=500 --compress --stream=xbstream /doesntneedtoexist | ssh user@otherhost "xbstream -x -C /root/backup/"

и затем вы можете полностью выполнить этап применения журнала и сохранить дисковое пространство, ввод-вывод и ЦП на рабочем сервере.

Percona Howto для использования xtrabackup

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.