Как эффективно вывести огромную базу данных MySQL innodb?

Я получил производственный сервер базы данных MySQL Ubuntu 10.04, где общий размер базы данных составляет 260 ГБ, а размер корневого раздела составляет 300 ГБ, где хранится БД, по сути, это означает, что около 96% / заполнено, и нет места для хранения дампа / резервной копии и т. д. Никакой другой диск не подключен к серверу на данный момент.

Моя задача - перенести эту базу данных на другой сервер, расположенный в другом центре данных. Вопрос в том, как сделать это эффективно с минимальным временем простоя?

Я думаю в строке:

  • Просьба подключить дополнительный диск к серверу и создать дамп на этом диске. [РЕДАКТИРОВАТЬ: Это не возможно сейчас.]
  • Перенесите дамп на новый сервер, восстановите его и сделайте новый сервер подчиненным существующему для синхронизации данных
  • Когда миграция необходима, прервите репликацию, обновите ведомый конфиг, чтобы он принимал запросы на чтение / запись, и делайте старый сервер доступным только для чтения, чтобы он не принимал никаких запросов на запись и не велел разработчикам приложений обновить там конфигурацию с новым IP-адресом для базы данных.

Каковы ваши предложения по улучшению этого или любого другого альтернативного подхода к этой задаче?

Источник

4 ответа

Решение

Если вы планируете перейти на другой сервер БД с точно такой же версией MySQL, вы можете rsync datadir со старого сервера на новый сервер.

Это будет работать независимо от формата файла InnoDB или даже наличия таблиц MyISAM.

  1. установите ту же версию MySQL на сервере B, что и на сервере A
  2. На сервере А запустите RESET MASTER; стереть все двоичные журналы перед процессом rsycn. Если двоичное ведение журнала не включено, вы можете пропустить этот шаг.
  3. На сервере А запустите SET GLOBAL innodb_max_dirty_pages_pct = 0; от mysql и около 10 минут (это удаляет грязные страницы из пула буферов InnoDB. Это также помогает быстрее выполнять отключение mysql). Если ваша база данных - все MyISAM, вы можете пропустить этот шаг.
  4. rsync /var/lib/mysql сервера A в /var/lib/mysql на сервере B
  5. Повторите шаг 3, пока rsync не займет менее 1 минуты
  6. service mysql stop на сервере А
  7. Выполните еще одну rsync
  8. scp ServerA: /etc/my.cnf для ServerB:/etc/.
  9. service mysql start на сервере B
  10. service mysql start на сервере A (необязательно)

По сути, вот что такое сценарий хотел бы это

mysql -u... -p... -e"RESET MASTER;"
mysql -u... -p... -e"SET GLOBAL innodb_max_dirty_pages_pct = 0;"
RSYNCSTOTRY=10
cd /var/lib/mysql
X=0
while [ ${X} -lt ${RSYNCSTOTRY} ]
do
    X=`echo ${X}+1|bc`
    rsync -r * targetserver:/var/lib/mysql/.
    sleep 60
done
service mysql stop
rsync -r * targetserver:/var/lib/mysql/.
service mysql start

Один из сотрудников DBA StackExchange сказал, что я должен держаться подальше от FLUSH TABLES WITH READ LOCK; основанный на чем-то в mysqlperformanceblog.com

Я прочитал и узнал, что SELECTs против таблиц InnoDB в середине FLUSH TABLES WITH READ LOCK; все еще может позволить записи происходить каким-либо образом. Как указано в комментарии Arlukin, LVM будет работать с FLUSH TABLES WITH READ LOCK на InnoDB просто отлично (+1 за его комментарий).

Для всех не-LVM пользователей у вас все в порядке с базой данных all-MyISAM для использования с FLUSH TABLES WITH READ LOCK;, Для InnoDB придерживайтесь --single-tranaction использование в mysqldumps, пожалуйста.

Источник

Вывод и восстановление базы данных такого размера займет несколько часов. Я бы, в зависимости от версии mysql, пока номер версии увеличивается, и нет скачков в основной номер ревизии. Вы должны иметь возможность взять необработанные файлы базы данных в / var / lib / mysql и поместить их на новый сервер, установить разрешения и запустить сервер с ключом --skip-grant-tables. Добавьте необходимые гранты для пользователей, отражающих новый IP-адрес, а затем перезапустите в обычном режиме.

Я бы обратился к размеру вашей базы данных, так как она слишком велика, чтобы быть эффективной.

Источник

Вы можете просто сбросить базу данных прямо на удаленный сервер...

$ mysqldump | ssh user@server 'cat - > dumpfile.sql.gz'

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

$ mysqldump | ssh -C user@server 'cat - > dumpfile.sql.gz'
$ mysqldump | gzip -c | ssh user@server 'cat - > dumpfile.sql.gz'
Источник

Вы можете выполнить следующие шаги, чтобы перенести эту огромную базу данных InnoDB.

  • Установите SSHFS и смонтируйте соответствующий раздел удаленного сервера на производственном сервере.
  • Используйте Percona XtraBackup, чтобы получить горячую копию базы данных InnoDB и напрямую сохранить ее в подключенном каталоге SSHFS.

  • Эта задача займет несколько часов. Чтобы минимизировать влияние сценария hotcopy на работающий сервер, установите для него низкий приоритет с помощью renice

    $ renice -n 5 -p <SCRIPT-PID>

  • Убедитесь, что на обоих серверах установлена ​​одинаковая версия сервера MySQL.
  • После завершения горячей копии вы можете восстановить ее на новом сервере и запустить процесс репликации.

Вы можете испытывать медлительность во время этого процесса, но определенно нет простоя. Percona XtraBackup создаст горячую копию, которая быстрее и требует меньше ресурсов по сравнению с mys qldump. Это идеально подходит для огромной базы данных InnoDB.

В зависимости от моделей использования и статистики вы можете запускать этот процесс при минимальном трафике на сервере. Возможно, делать это на выходных - хорошая идея? Выше приведен лишь набросок процесса. Возможно, вам придется ознакомиться с документацией по Percona XtraBackup и SSHFS.

Источник
Другие вопросы по тегам