Мне нужно переместить базу данных 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 и заблокировать всех пользователей? Решит ли это какие-либо затянувшиеся транзакции и обеспечит ли это легитимность данных при импорте? По сути, я хочу «отключить» доступ к базе данных навсегда, как только я начну процесс резервного копирования, поскольку после импорта на новый сервер к ней больше никогда не понадобится доступ, и, что более важно, я не хочу, чтобы к ней обращались во время дампа/восстановления на другом сервере. Конечно, я хотел бы оставить базу данных на исходном сервере на случай возникновения проблем с импортом.
решение1
Обратите внимание, что вы должны использовать --hex-blobwith mysqldump, если у вас есть какие-либо зашифрованные поля в базе данных. Если --hex-blobне использовать, данные будут бесполезны при импорте.
Перед резервным копированием выполните a, FLUSH TABLES WITH READ LOCKчтобы предотвратить любые изменения. Вы можете перенаправить резервную копию на новый сервер за один шаг, избавившись от шага копирования файла SQL.
mysqldump --single-transaction --routines --triggers --events --hex-blob db-name | mysql -h server db-name
решение2
Первое, что вам следует сделать, это создать резервную копию вашей базы данных, а затем импортировать ее на новый сервер и сначала протестировать новый сервер. Если все в порядке, также проверьте время, которое у вас уходит на создание резервной копии и восстановление на новом сервере, чтобы вы знали, сколько времени вам потребуется, чтобы запустить новый сервер в эксплуатацию.
Когда вы будете готовы перенести все данные на новый сервер, лучше всего отключить все соединения с базой данных, за исключением localhost, так как вы будете использовать mysqldump для доступа к базе данных и создания резервной копии. Если все обращения к базе данных осуществляются с вашего веб-сервера, вы можете отключить веб-сервер. Другой способ — настроить iptables для блокировки всего трафика на порту MySQL, за исключением localhost. Затем выполните резервное копирование базы данных, восстановление на новом сервере, запустите новый сервер и убедитесь, что все ваши соединения будут идти к новому серверу.
решение3
все зависит от того, достаточно ли велика или мала ваша база данных, а также от того, какую службу вы используете, но я полагаю, что должен быть какой-то перерыв на обслуживание, в выходные дни поздно ночью, выключите ваш 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 поможет вам сделать это быстрее.