データベースを新しいデータセンターに移行することは、リスクが高く時間のかかるプロセスになる可能性があります。データベースには状態が含まれており、Webサーバー、キュー、またはキャッシュサーバーと比較して移行がはるかに難しい場合があります。
このブログ投稿では、あるサービスプロバイダーから別のサービスプロバイダーにデータを移行する方法に関するヒントをいくつか紹介します。このプロセスは、MySQLのアップグレード方法に関する以前の投稿と多少似ていますが、いくつかの重要な違いがあります。
MySQLレプリケーションまたはGaleraクラスター？
別のサービスプロバイダーに切り替える（たとえば、AWSからRackspaceに、または同じ場所に配置されたサーバーからクラウドに移行する）ということは、まったく新しいインフラストラクチャを並行して構築し、古いインフラストラクチャと同期してから切り替えることを意味します。それらを接続して同期するには、MySQLレプリケーションを活用することをお勧めします。
Galera Clusterを使用している場合は、Galeraノードを別のデータセンターに移動する方が簡単な場合があります。ただし、クラスター全体を単一のデータベースとして扱う必要があることに注意してください。これは、WANを介してGalera Clusterを拡張するときに、本番サイトで追加の遅延が発生する可能性があることを意味します。 Galeraとオペレーティングシステムの両方でネットワーク設定を調整することで影響を最小限に抑えることは可能ですが、影響を完全に排除することはできません。レイテンシの影響が許容できない場合は、代わりに古いクラスターと新しいクラスターの間に非同期MySQLレプリケーションを設定することもできます。
安全な接続の設定
MySQLレプリケーションは暗号化されていないため、WAN経由で安全に使用することはできません。データが安全に転送されるようにする方法はたくさんあります。現在のインフラストラクチャと新しいサービスプロバイダーの間にVPN接続を確立できるかどうかを調査する必要があります。ほとんどのプロバイダー（たとえば、RackspaceとAWSの両方）がそのようなサービスを提供しています。仮想プライベートネットワークを介して、「曇った」部分を既存のデータセンターに接続できます。
何らかの理由でこのソリューションが機能しない場合（おそらく、アクセスできないハードウェアが必要な場合）、ソフトウェアを使用してVPNを構築できます。そのうちの1つはOpenVPNになります。このツールは、データセンター間の暗号化された接続をセットアップするためにうまく機能します。
OpenVPNがオプションでない場合、レプリケーションが暗号化されるようにする方法は他にもあります。たとえば、SSHを使用して、古いデータセンターと新しいデータセンターの間にトンネルを作成し、3306ポートを現在のMySQLスレーブ（またはマスター）から新しいノードに転送できます。ホスト間にSSH接続がある限り、非常に簡単な方法で実行できます。
$ ssh -L local_port:old_dc_host:mysql_port_in_old_dc [email protected]_dc_host -N &例：
$ ssh -L 3307:10.0.0.201:3306 [email protected] -N &これで、127.0.0.1：3307
を使用してリモートサーバーに接続できます。$ mysql -P3307 -h 127.0.0.1レプリケーションでも同様に機能します。master_hostには127.0.0.1を使用し、master_portには3307を使用することを忘れないでください
最後になりましたが、SSLを使用してレプリケーションを暗号化できます。この以前のブログ投稿では、それを実行する方法と、レプリケーションのパフォーマンスにどのような影響を与える可能性があるかについて説明しています。
両方のデータセンターでGaleraレプリケーションを使用することにした場合は、上記の提案がここにも当てはまります。 SSLに関しては、以前、Galeraレプリケーショントラフィックを暗号化する方法についてブログを書きました。より完全なソリューションとして、クライアントアプリケーションおよび任意の管理/監視インフラストラクチャからのすべてのデータベース接続を暗号化することをお勧めします。
新しいインフラストラクチャのセットアップ
接続できるようになったら、新しいインフラストラクチャの構築を開始する必要があります。そのためには、おそらくxtrabackupまたはmariabackupを使用します。移行とMySQLのアップグレードを組み合わせたくなるかもしれません。結局のところ、新しい場所にまったく新しい環境をセットアップしているのです。そうすることはお勧めしません。新しいインフラストラクチャへの移行はそれ自体で十分に重要であるため、それを別の主要な変更と組み合わせると、複雑さとリスクが増大します。これは他のことにも当てはまります。変更に対して段階的なアプローチを取りたいと考えています。一度に1つずつ変更するだけで、変更の結果と、それがワークロードにどのように影響するかを理解できます。一度に複数の変更を行った場合、どの変更が特定の（新しい）あなたが観察した行動。
新しいMySQLインスタンスを新しいデータセンターで稼働させている場合は、両方のデータセンターのデータの同期を維持するために、古いデータセンターのノードからそのインスタンスをスレーブ化する必要があります。これは、最終的なカットオーバーの準備をするときに便利になります。これは、新しい環境で書き込みの負荷を確実に処理できるようにするための優れた方法でもあります。
次のステップは、新しい場所に完全なステージングインフラストラクチャを構築し、テストとベンチマークを実行することです。これはスキップしてはならない非常に重要なステップです。ここでの問題は、DBAとして、インフラストラクチャの容量を理解する必要があることです。プロバイダーを変更すると、状況も変わります。新しいハードウェア/vmは高速または低速です。インスタンスあたりのメモリは多かれ少なかれあります。使用するハードウェアにワークロードがどのように適合するかをもう一度理解する必要があります。そのためには、おそらくPerconaPlaybackまたはpt-log-playerを使用してステージングシステムで実際のクエリの一部を再生します。パフォーマンスをテストし、許容できるレベルにあることを確認する必要があります。また、新しいリリースで実行するすべての標準受け入れテストを実行する必要があります。すべてが稼働していることを確認するためだけです。一般に、すべてのアプリケーションは、ハードウェア構成と現在のセットアップに依存しない方法で構築する必要があります。ただし、何かがすり抜けた可能性があり、アプリは、新しい環境にはない構成の微調整やハードウェアソリューションの一部に依存している可能性があります。
最後に、テストに満足したら、本番環境に対応したインフラストラクチャを構築する必要があります。これが完了したら、最終検証のために読み取り専用テストを実行することをお勧めします。これがカットオーバー前の最後のステップになります。
カットオーバー
これらのテストがすべて実行され、インフラストラクチャが本番環境に対応していると見なされた後、最後のステップは古いインフラストラクチャからのトラフィックをカットオーバーすることです。
グローバルに言えば、これは複雑なプロセスですが、データベース層を見ると、標準のフェイルオーバーとほぼ同じです。これは、過去に何度も行ったことがあるかもしれません。以前の投稿で詳しく説明しました。簡単な手順は次のとおりです。トラフィックを停止し、停止していることを確認し、アプリケーションが新しいデータセンターに移動するまで待ちます（DNSレコードが変更されるかどうか）、スモークテストを実行して確認しますすべてが良さそうです。ライブに移行し、しばらく注意深く監視してください。
ご覧のとおり、このカットオーバーにはある程度のダウンタイムが必要です。問題は、古いサイトと新しいサイトで一貫した状態を維持することです。ダウンタイムなしでそれを実行したい場合は、マスターマスターレプリケーションを設定する必要があります。その理由は、DNSを更新し、セッションを古いサイトから新しいサイトに移動すると、すべてのセッションが新しいサイトにリダイレクトされるまで、両方のシステムが同時に使用されるためです。それまでの間、新しいサイトでの変更はすべて古いサイトに反映する必要があります。
このブログ投稿で説明されているように、Galera Clusterを使用することも、2つのサイト間のデータの同期を維持する方法になります。
これは、データ移行プロセスの非常に簡単な説明であることを認識しています。うまくいけば、あなたを良い方向に導き、あなたが探す必要のある追加情報を特定するのに役立つでしょう。