
Linux サーバーを 1 つの専用サーバーから別の専用サーバーに移動するタスクがあります。
一般的に私の計画は次のとおりです:
- 夜間 - httpd と mysql をオフにします。SSH 経由で RSYNC を実行します。
- 日中 - http と mysql をオンにします。
- 夜間は httpd と mysql をオフにします。SSH 経由で RSYNC を実行します。
- 夜間。両方のサーバーで httpd と mysql をオンにします。DNS エントリを変更します。
- 日中。サーバーの状態を監視します。
したがって、mysql と httpd の両方を同期するには、ほとんどの場合、rsync (mysqldump なし) を使用します。
いいですね?何か注意点はありますか?
答え1
私は 2 つの解決策を提案します。個人的には、論理クローン方式の方がダウンタイムが少なくて済むため、またデータベース レプリケーションは他の理由から取得できる多目的な機能であるため、論理クローン方式を好みます。ただし、提案されたものと類似した正確なクローン方式は、あらゆるサーバーを移行するための一般的なブルート フォース アプローチです。
正確なクローン
- DNS エントリの TTL を減らして、作業を楽にしましょう。
- ソースからターゲットにrsyncします。ソース上のサービスをシャットダウンする必要はありません。不整合は手順(4)と(7)で修正されます。
- オプションで、新しいサーバーでいくつかのテストを実行することもできます。ターゲット サーバーで動作させるためにどのような構成変更を行う必要があるかを調べます。すべてが正常に起動することを確認するために、ターゲット マシンを再起動する必要がある場合もあります。
- rsync ソースをターゲットに再度実行して、(3) で導入した新しいサーバーへの「ダメージ」を元に戻し、さらにいくつかの違いを検出し、増分 rsync の実行にかかる時間 (予想されるダウンタイムの指標) を把握します。
- 両方のマシンのすべてのサービスをシャットダウンします。ソース マシンのサービスがオフになっていることを確認します。古いマシンと新しいマシンでデータが分岐する「スプリット ブレイン」状態は避けてください。
- DNS エントリを変更します。ロールバックする予定がない場合は、新しいエントリに通常の TTL を使用できます。
- ソースをターゲットに再度 rsync します。
- 手順 (3) で発見したように、ターゲット マシンに必要な構成変更を適用します。
- ターゲットマシンでサービスを開始します。
論理クローン
設定を検討するMySQL レプリケーションMySQL サーバーでバイナリ ログがまだ有効になっていない場合は、データベースを一時的にバウンスして有効にする必要があります。いずれにしても、バイナリ ログを有効にすることを強くお勧めします。これは、MySQL のアップグレードなどの将来の操作をほぼゼロのダウンタイムで実行するのに便利なためです。
設定した場合循環複製MySQL がアプリケーションの唯一のデータ ストアである場合は、古い Web サーバーと新しい Web サーバーの両方を同時に実行できる場合もあります。