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

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

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

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

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

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

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

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

1. установите ту же версию MySQL на сервере B, что и на сервере A
2. На RESET MASTER;сервере A запустите, чтобы стереть все двоичные журналы перед процессом rsycn. Если двоичное ведение журнала не включено, вы можете пропустить этот шаг.
3. На сервере A запускайте 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

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

• http://www.mysqlperformanceblog.com/2012/03/23/how-flush-tables-with-read-lock-works-with-innodb-tables/
• http://forums.mysql.com/read.php?22,184590,184610

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

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

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

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

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

• Эта задача займет несколько часов. Чтобы минимизировать влияние сценария hotcopy на работающий сервер, установите для него низкий приоритет с помощью 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'