あるサーバーから別のサーバーに 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-blobを とともに使用する必要があることに注意してください。を使用しない場合、インポート時にデータは役に立たなくなります。mysqldump--hex-blob
バックアップする前に、FLUSH TABLES WITH READ LOCK変更を防ぐために を実行します。バックアップを 1 つの手順で新しいサーバーにパイプできるため、SQL ファイルをコピーする手順を省くことができます。
mysqldump --single-transaction --routines --triggers --events --hex-blob db-name | mysql -h server db-name
答え2
最初に行うべきことは、データベースのバックアップを作成し、それを新しいサーバーにインポートして、新しいサーバーが問題ないかテストすることです。また、バックアップを作成して新しいサーバーに復元するのにかかる時間をチェックして、新しいサーバーを本番環境に導入するのにどれくらいの時間がかかるかを把握してください。
新しいサーバーにすべてを渡す準備ができたら、mysqldump を使用してデータベースにアクセスし、バックアップを作成するため、localhost 以外のデータベースへのすべての接続を非アクティブ化することをお勧めします。データベースへのすべてのアクセスが Web サーバーから行われる場合、Web サーバーを停止できます。別の方法としては、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
圧縮そしてズキャット より早く実行するのに役立ちます。