Назад | Перейти на главную страницу

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

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

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

Я думаю о том, что:

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

Что вы предлагаете улучшить этот или какой-либо другой лучший подход к этой задаче?

innodb mysql

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

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

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

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

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

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

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

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

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

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

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

$ renice -n 5 -p <SCRIPT-PID>
Убедитесь, что на обоих серверах запущена одна и та же версия сервера MySQL.
После завершения горячей копии вы можете восстановить ее на новом сервере, запустите процесс репликации.

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

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

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

$ 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'