innodb db를 한 서버에서 다른 서버로 이동해야 합니다. mysql > mariadb에서도 마찬가지입니다. 나는 전혀 문제가 없는지 확인하고 mysqldump를 사용하여 새 서버로 내보낸 다음 가져올 것입니다. my.cnf 설정은 새 서버에서 다르기 때문에 파일을 복사하는 것은 시도하고 싶지 않습니다. 문제 없이 좋은 덤프/가져오기를 보장하는 한 가동 중지 시간에 대해 전적으로 걱정하지 않습니다.
이것은 라이브 DB이기 때문에 트랜잭션이나 새 서버로 가져올 때 제약 문제/손상을 일으킬 수 있는 다른 항목으로 인한 덤프 오류가 걱정됩니다.
여기서 가장 좋은 절차는 무엇입니까? 내가 생각했던 것은 다음과 같습니다 ...
- 사용자 액세스 없이 mysql을 다시 시작하면 아무도 db를 읽거나 쓸 수 없습니다.
- mysqldump를 사용하여
mysqldump -u [username] -p[password] -h [host] [databaseName] > [backup-name].sql - 다음으로 가져오기
mysql -u [username] -p[password] -h [host] [databaseName] < [filename].sql
mysql을 다시 시작하고 모든 사용자를 잠글 수 있습니까? 이렇게 하면 느린 트랜잭션이 해결되고 가져올 때 데이터가 합법적인지 확인할 수 있습니까? 기본적으로 백업 프로세스를 시작하면 db에 대한 액세스를 영원히 '차단'하고 싶습니다. 새 서버로 가져온 후에는 다시 액세스할 필요가 없으며 더 중요한 것은 덤프 중에 액세스하는 것을 원하지 않는다는 것입니다/ 다른 서버로 복원합니다. 물론 가져오기 문제가 발생할 경우를 대비해 원본 서버에 db를 남겨두고 싶습니다.
답변1
데이터베이스에 암호화된 필드가 있는 경우 --hex-blobwith를 사용해야 합니다 . 를 사용하지 mysqldump않으면 --hex-blob가져올 때 데이터가 쓸모 없게 됩니다.
백업하기 전에 FLUSH TABLES WITH READ LOCK변경 사항을 방지하려면 다음을 수행하십시오. 한 단계로 백업을 새 서버로 파이프하여 SQL 파일을 복사하는 단계를 저장할 수 있습니다.
mysqldump --single-transaction --routines --triggers --events --hex-blob db-name | mysql -h server db-name
답변2
가장 먼저 해야 할 일은 데이터베이스를 백업한 다음 이를 새 서버로 가져온 다음 먼저 새 서버를 테스트하는 것입니다. 문제가 없으면 먼저 새 서버를 테스트하고, 백업을 만들고 새 서버로 복원하는 데 걸리는 시간도 확인하세요. 새 서버를 프로덕션에 투입하는 데 시간이 얼마나 걸리는지 알고 있습니다.
모든 것을 새 서버에 전달할 준비가 되면 mysqldump를 사용하여 데이터베이스에 액세스하고 백업을 만들 것이므로 로컬 호스트가 아닌 한 데이터베이스에 대한 모든 연결을 비활성화하는 것이 좋습니다. 데이터베이스에 대한 모든 액세스가 웹 서버에서 오는 경우에는 내려놓을 수 있습니다. 다른 방법은 웹 서버가 localhost를 제외한 mysql 포트의 모든 트래픽을 차단하도록 iptables를 구성하는 것입니다. 그런 다음 데이터베이스를 백업하고, 새 서버로 복원하고, 새 서버를 라이브로 설정하고, 모든 연결이 새 서버로 연결되는지 확인하세요.
답변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 더 빨리 할 수 있도록 도와줄 것입니다.