Amazon Linux と Amazon-EBS をルートボリュームとして使用して Amazon EC2 を起動しました。また、この EBS ボリュームで tomcat7 と mysql 5.5 を開始しました。
その後、Amazon Linux から Ubuntu に変更することにしました。そのためには、新しい EBS ルート ボリュームで別の Amazon EC2 インスタンスを起動する必要があります。tomcat7 と mysql を古い EBS ボリュームから新しいボリュームにコピーしたいと思います。失いたくないmysqlのテーブルとデータと、Tomcatで実行されているアプリケーションがあります。それについてどうやって行くのですか？
いくつかの考えと提案。
まず、データベースに何らかの重大な負荷がかかる場合、EBS でバックアップされたボリュームで実行することはおそらく良い考えではありません。EBS でバックアップされたストレージは、マシンのローカル/一時ストレージ (/mnt) に比べて非常に遅いからです。 ）。明らかに、DB データをエフェメラル ストレージに保存したくないので、EC2 で MySQL を実行したい場合にできることは何もありません。したがって、インフラストラクチャの要件で許可されている場合は、DB に RDS インスタンスを利用することをお勧めします。
第 2 に、これが本番アプリケーションである場合、この移行を行う際にダウンタイムが発生することは間違いありません。問題は、ダウンタイムを最小限に抑える必要があるかどうかです。その場合、データベースのサイズを把握する必要があります。ダンプ/ロードに時間がかかりますか? そうでない場合は、おそらく新しいインスタンスを起動して実行し、データベースの古いコピーでテストしてから、カットオーバー時に現在のデータベースをダンプしてロードするだけで済みます。
大規模なデータベースの場合は、MySQL のバイナリ ログを有効にすることができます。次に、既知のバイナリ ログ位置でデータベースのダンプを作成します。次に、このダンプを新しいインスタンスにインストールします。次に、カットオーバーの準備ができたら、新しいインスタンスでバイナリ ログを再生して、最新の状態にします。同様に、新しいインスタンスの DB をカットオーバーまでレプリカとしてセットアップし、その時点でそれをマスターにすることもできます。
バイナリログを台無しにしたくない場合は、rsync を使用して物理データベース ファイルを同期することを検討することもできますが、実際の物理データベース ファイルの扱いに慣れていない場合、これは問題のあるアプローチになる可能性があります。
アプリケーションに関する限り、それが単なるファイルの集まりであると仮定すると、移行がはるかに簡単になるはずです。Tomcat7 のインストール自体をコピーするのではなく、Tomcat を Ubuntu にインストールしてから、現在の構成に合わせて構成を調整します。
カットオーバー自体に関する限り、これは非常に簡単で、サーバーにエラスティック IP を使用しているか、ロード バランサーの背後にあるかによってアプローチが異なります。