перемещение живого innodb дб от одного сервера до другого
Я должен переместить innodb дб от одного сервера до другого - он также идет от mysql> mariadb. Я хочу удостовериться, что нет никаких проблем вообще и с которым я буду использовать mysqldump, чтобы экспортировать и затем импортировать на новом сервере. my.cnf настройки отличаются на новом сервере, настолько копирующие законченные файлы не являются чем-то, что я хочу попробовать. Я не полностью обеспокоен временем простоя любого, пока это гарантирует хороший дамп/импорт без проблем.
Поскольку это - живой дб, я обеспокоен ошибками в дампе из-за транзакции или чего-либо еще, что при импорте на новом сервере вызовет ограничительные проблемы/повреждение.
Какова лучшая процедура здесь? Вот то, что я думал...
- перезапустите mysql без пользовательского доступа, таким образом, никто не может чтение-запись к дб.
- mysqldump с
mysqldump -u [username] -p[password] -h [host] [databaseName] > [backup-name].sql - импорт с
mysql -u [username] -p[password] -h [host] [databaseName] < [filename].sql
Действительно ли возможно перезапустить mysql и заблокировать всех пользователей? Это решило бы какие-либо непрекращающиеся транзакции и гарантировало бы, что данные законны при импорте? В основном я хочу 'отключить' доступ к дб навсегда, после того как я запускаю процесс резервного копирования как, после того как он импортируется на новом сервере, к нему никогда не должны были бы получать доступ снова, и что еще более важно, я не хочу его, получил доступ во время дампа/восстановления к другому серверу. Конечно, я хотел бы оставить дб на исходном сервере в случае, если там импортируют проблемы, которые подходят.
Обратите внимание, что вы должны использовать - hex-blob с mysqldump , если у вас есть зашифрованные поля в базе данных. Если - hex-blob не используется, данные будут бесполезны при импорте.
Перед резервным копированием выполните FLUSH TABLES WITH READ LOCK , чтобы предотвратить любые изменения. Вы можете направить резервную копию на новый сервер за один шаг, сохранив шаг копирования файла SQL.
mysqldump --single-transaction --routines --triggers --events --hex-blob db-name | mysql -h server db-name
первое, что вы должны сделать, это сделать резервную копию вашей базы данных, а затем импортировать ее на новый сервер и протестировать новый сервер в первую очередь, если все в порядке , также проверьте время, которое вы берете, чтобы создать резервную копию и восстановить на новом сервере, так что вы знаете, сколько времени займет для вас, чтобы поставить новый сервер в производство.
когда вы будете готовы передать все на новый сервер, лучше деактивируйте все соединения к вашей базе данных, кроме localhost, так как вы будете использовать mysqldump для доступа к базе данных и создания резервной копии, если все соединения к базе данных приходят с вашего веб-сервера, вы можете опустить веб-сервер, в противном случае настройте iptables для блокирования всего трафика на вашем mysql порту, кроме localhost. Затем вы создадите резервную копию вашей базы данных, восстановите ее на новом сервере и установите ваш новый сервер в режиме реального времени, и убедитесь, что все соединения будут идти к новому серверу.
.это все зависит от того, достаточно ли большая или малая база данных, также зависит от того, какая служба у вас запущена, но я полагаю, что должно быть какое-то окно обслуживания, в выходные дни поздно вечером, выключите apache/nginx, также вы можете перезагрузить базу данных с отключенной сетью, межсетевым экраном или другим локальным портом. экспорт:
mysqldump -p --single-transaction --routines --triggers --events DATABASE | gzip > backup.sql.gz
импорт:
zcat backup.sql.gz | mysql -f -p DATABASE
перепроверка:
mysql_upgrade -p -f
gzip и zcat помогут вам сделать это быстрее.
.