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

конфигурационный файл logrotate:

dateext
dateformat -%Y-%m-%d-%s

:

atop.log-2010-09-30-1285850549

час не поддерживается. Можно использовать постповорачивание для переименования.

8
задан 7 November 2012 в 09:50
4 ответа

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

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

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

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

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

. Для InnoDB придерживайтесь - одинарное использование в mysqldumps, пожалуйста.

. Для InnoDB придерживайтесь - одинарное использование в mysqldumps, пожалуйста.

9
ответ дан 2 December 2019 в 22:54

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

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

1
ответ дан 2 December 2019 в 22:54

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

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

    $ renice -n 5 -p

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

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

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

1
ответ дан 2 December 2019 в 22:54

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

$ 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'
1
ответ дан 2 December 2019 в 22:54

Теги

Похожие вопросы