0

WebアプリケーションとMariaDBデータベースをホストするEC2インスタンスが1つあり、データベースを別々のインスタンスにするには、のいずれかを実行するための標準的なプラクティスは何ですか?ダウンタイム?それは私にとっては複雑な問題のように思えますが、ウェブとデータ層を離しておくことのメリットについて議論したすべての記事は、セキュリティ上のメリットについて話していますが、スケーラビリティのメリットを強調していないようです私はそれがそれほど複雑ではないと思う。アプリケーションとデータベースが同じインスタンス上にある場合、EC2インスタンスを2つに拡大する

また、この同じシナリオでは、アプリケーションとデータベースを結合したままにしておくと、それほど複雑ではないでしょうが、どのように機能しますか? - 停止時間が0になることを念頭に置いてください。

+0

ダウンタイムなしで単一のマシンを拡大すると、再起動せずにCPUとRAMを追加することになります。それがEC2で可能かどうかは確かではありません。既にロードバランサを配置している場合は、ビフェジエートマシンを並行して準備し、準備ができたらフォールオーバーします。しかし、新しいマシンにすべての現在のデータを保存する必要があります。だから私はあなたのデータをコピーするためには、少なくともいくつかの読み取り専用モードが必要だと思います。 – Thilo

+0

@Thilo最新のインスタンスにトラフィックをリダイレクトすると、そのデータが元のデータで最新のものになることをどのように保証できますか? –

+0

だから私はあなたのデータをコピーするには、しばらくの間、いくつかの読み取り専用モードが必要だと思います。 – Thilo

答えて

0

MariaDBでの複製の仕組みに精通しており、そのソリューションは直感的に明らかになります。

mysqldumpを使用して既存のデータベースを新しいサーバーにコピーし、特にバックアップするのに、--master-dataおよび--single-transactionというオプションに注意してレプリカデータベースサーバーを作成します。新しいデータベースサーバーに結果をロードすると、元のデータベースのレプリカが作成され、バックアップの作成を開始した時点で存在します。。 InnoDB MVCCは、バックアップの開始時に存在していた各テーブルの各行のバージョンが、このバックアップのロードの結果として新しいサーバに表示されることを保証します。

次に、新しいデータベース(スレーブとして)を古いデータベース(マスター)に接続して、それからレプリケートを開始するように指示します特定時点 - バックアップに含まれるマスターログの座標で特定される時点 - バックアップが開始された時刻。

スレーブがマスターと同期するのを待つ。

マスタのSHOW MASTER STATUS;とスレーブのSHOW SLAVE STATUS;を使用してレプリケーションステータスを監視すると、スレーブがマスターと実際に「最新」であるかどうかを判断するのは簡単です。 MariaDBのレプリケーションは、スレーブの変更前にマスター上の変更が行われるという意味で「非同期」ですが、適切な容量のスレーブサーバーでは、通常のレプリケーションの遅延はオーダーまたはミリ秒です...そして、やはり簡単です決定。アプリケーションの停止/起動に時間がかかる場合、残っているデータはすべて複製が完了したことを確認できます。

スレーブを書き込み可能にします(通常、スレーブは読み取り専用モードに設定されていますが、唯一の変更元はレプリケーションSQLスレッドです)。レプリケーションを監視して同期を確認します、アプリケーションを停止し、新しいデータベースにアプリケーションをポイントし、レプリケーションがまだ同期していることを確認し、アプリを起動...完了します。ここで、スレーブをマスターデータベースから切り離し、古いマスターを破棄します。

もちろん、実際にはアプリケーションを別のデータベースに接続するように再構成する必要があるため、停止時間をゼロにすることは実質的に不可能です...しかし、ダウンタイムの合計は基本的に、入力の速さや必要な自動化両方のデータベースサーバーをポーリングしてレプリケーション座標を比較し、移行を実行する手順。

明らかに明白になる危険性があるため、データベース以外のものは絶対にデータベースサーバーに配置しないでください。決してアプリケーションと一緒に配置しないでください。プロダクションでの例外は、議論することすらできません。here,herehere、およびhereのように、頻繁に発生する問題は、アプリケーションとそのデータベースを同じサーバー上で実行するこの原則を無視した人に起因することはありません。パフォーマンスと安定性は危険にさらされているだけでなく、発生する現象も、MySQL(またはMariaDBまたはPercona Server)が実際にアプリケーションが故障しているときに「クラッシュ」しているという誤った印象を与え、OSを促します不可避的なメモリ枯渇に直面してマシンの全体的な安定性を維持しようと努力してデータベースを強制的にクラッシュさせます。

0

一つの可能​​な解決策:

はintiallyちょうどあなたが持っている単一のインスタンスにトラフィックを向ける、あなたのEC2インスタンスの前でロードバランサを置きます。

スピンアップ、あなたのウェブサイトのコピーを実行しconfigurelyそれをすべて取得し、最初のインスタンス上のDBを指して、その後、それはトラフィック

を取得するために開始しますので、ロードバランサにそれを追加する2つ目のインスタンスをオプション:2番目のインスタンスと同じように構成された3番目のインスタンスを追加し、Webサイトのコピーも実行します。

LBプールから元のインスタンスを取り出して、Webトラフィックが#2と#3だけになるようにします。

#1インスタンスからWebサイトを削除すると、dbサーバーのみが実行されます。

関連する問題