収益性の高い企業にはすべて、高可用性が必要です。小規模な企業や個人でさえ、評判を維持するためにサイトを存続させる必要があるため、Webサイトとブログも例外ではありません。
WordPressは、世界で最も人気のあるCMSであり、小規模から大規模まで、何百万ものWebサイトに電力を供給しています。しかし、どうすればあなたのウェブサイトが生き続けることを確実にすることができますか。具体的には、データベースが使用できなくなってもWebサイトに影響がないことを確認するにはどうすればよいですか。
このブログ投稿では、ClusterControlを使用してWordPressWebサイトのフェイルオーバーを実現する方法を紹介します。
このブログで使用するセットアップでは、PerconaServer5.7を使用します。 ApacheとWordpressアプリケーションを含む別のホストがあります。アプリケーションの高可用性の部分については触れませんが、これも必ず必要なものです。 ClusterControlを使用してデータベースを管理し、可用性を確保し、3番目のホストを使用してClusterControl自体をインストールおよびセットアップします。
ClusterControlが稼働していると仮定すると、既存のデータベースをそこにインポートする必要があります。
ClusterControlを使用したデータベースクラスターのインポート
展開ウィザードの[既存のサーバー/データベースのインポート]オプションに移動します。
これはClusterControlの要件であるため、SSH接続を構成する必要があります。ノードを管理できるようになります。
ベンダー、バージョン、rootユーザーに関する詳細を定義する必要がありますアクセス、ノード自体、およびClusterControlに自動回復を管理させるかどうか。以上で、ジョブが成功すると、リストにクラスターが表示されます。
高可用性環境をセットアップするには、いくつかを実行する必要がありますアクションの。私たちの環境は...
で構成されます- マスター-スレーブペア
- 読み取り/書き込み分割とトポロジ検出用の2つのProxySQLインスタンス
- 仮想IP管理用の2つのキープアライブインスタンス
考え方は単純です。マスターにスレーブをデプロイするので、マスターに障害が発生した場合にフェイルオーバーする2番目のインスタンスがあります。 ClusterControlは障害検出を担当し、マスターが使用できなくなった場合にスレーブを昇格させます。 ProxySQLはレプリケーショントポロジを追跡し、トラフィックを正しいノードにリダイレクトします。書き込みはマスターに送信されます。どのノードにあるかに関係なく、読み取りはマスターのみに送信するか、マスターとスレーブに分散できます。 。最後に、KeepalivedはProxySQLと同じ場所に配置され、アプリケーションが接続するためのVIPを提供します。そのVIPは常にProxySQLインスタンスの1つに割り当てられ、「メイン」ProxySQLノードに障害が発生した場合、Keepalivedはそれを2番目のインスタンスに移動します。
以上のことをすべて言ったので、ClusterControlを使用してこれを構成しましょう。それはすべて、数回クリックするだけで実行できます。スレーブを追加することから始めます。
ClusterControlを使用したデータベーススレーブの追加
「レプリケーションスレーブの追加」ジョブを選択することから始めます。次に、フォームに記入するように求められます：
マスターを選択する必要があります（この場合、実際には選択しません）多くのオプションがあります）、新しいスレーブのIPまたはホスト名を渡す必要があります。以前に作成したバックアップがある場合は、そのうちの1つを使用してスレーブをプロビジョニングできます。この場合、これは利用できず、ClusterControlはマスターから直接スレーブをプロビジョニングします。以上で、ジョブが開始され、ClusterControlが必要なアクションを実行します。 [アクティビティ]タブで進行状況を監視できます。
最後に、ジョブが正常に完了すると、スレーブがに表示されます。クラスターリスト。
次に、ProxySQLインスタンスの構成に進みます。この場合、環境は最小限であるため、物事を簡単にするために、データベースノードの1つにProxySQLを配置します。ただし、これは実際の実稼働環境では最良のオプションではありません。理想的には、ProxySQLは別のノードに配置するか、他のアプリケーションホストと同じ場所に配置します。
ジョブを開始する場所は[管理]->[ロードバランサー]です。
>
ここで、ProxySQLをインストールする場所を選択し、管理者の資格情報を渡す必要があります、データベースユーザーを追加します。この例では、WordPressアプリケーションがデータベースへの接続にすでに使用しているため、既存のユーザーを使用します。次に、ProxySQLで使用するノードを選択し（ここではマスターとスレーブの両方が必要です）、明示的なトランザクションを使用するかどうかをClusterControlに通知する必要があります。 ProxySQLがデプロイされたら再構成するため、これはこの場合は実際には関係ありません。このオプションを有効にすると、読み取り/書き込み分割は有効になりません。それ以外の場合、ClusterControlは読み取り/書き込み分割用にProxySQLを構成します。最小限の設定では、読み取り/書き込みの分割を実行するかどうかを真剣に検討する必要があります。それを分析しましょう。
ProxySQLでの読み取り/書き込みスピットの長所と短所
読み取り/書き込み分割を使用する主な利点は、すべてのSELECTトラフィックがマスターとスレーブの間で分散されることです。これは、ノードの負荷が低くなり、応答時間も短くなることを意味します。これは良さそうに聞こえますが、一方のノードに障害が発生した場合、もう一方のノードがすべてのトラフィックに対応できる必要があることに注意してください。 1つのノードが失われると、2番目のノードが過負荷になり、事実上使用できなくなる場合は、自動フェイルオーバーを実施しても意味がありません。
複数のスレーブがある場合は、負荷を分散するのが理にかなっている場合があります。5つのうち1つのノードを失うことは、2つのうち1つを失うよりも影響が少なくなります。何を決定しても、ProxySQLノードに移動して[ルール]タブをクリックすることで、動作を簡単に変更できます。
ルール200（すべてのSELECTステートメントをキャッチするルール）を確認してください。 ）。以下のスクリーンショットでは、宛先ホストグループが20であることがわかります。これは、クラスター内のすべてのノード（読み取り/書き込み分割とスケールアウトが有効になっている）を意味します。このルールを編集し、宛先ホストグループを10（マスターを含むもの）に変更することで、これを簡単に無効にできます。
読み取り/書き込み分割を有効にする場合は、簡単に行うことができますこれを行うには、このクエリルールを再度編集し、宛先ホストグループを20に戻します。
次に、2番目のProxySQLをデプロイしましょう。
すべての構成オプションを再度渡さないようにするには、「構成のインポート」を使用できます。 」オプションを選択し、既存のProxySQLをソースとして選択します。
このジョブが完了すると、環境設定の最後のステップを実行する必要があります。 ProxySQLインスタンスの上にKeepalivedをデプロイする必要があります。
ProxySQLインスタンス上にKeepalivedをデプロイする
ここでは、ロードバランサータイプとしてProxySQLを選択し、両方のProxySQLインスタンスを渡しました。インストールするキープアライブと、VIPおよびネットワークインターフェイスを入力しました。
ご覧のとおり、これでセットアップ全体の準備が整いました。 ProxySQLインスタンスの1つに割り当てられた10.0.0.111のVIPがあります。 ProxySQLインスタンスはトラフィックを正しいバックエンドMySQLノードにリダイレクトし、ClusterControlは必要に応じてフェイルオーバーを実行する環境を監視します。最後に実行する必要があるアクションは、仮想IPを使用してデータベースに接続するようにWordpressを再構成することです。
これを行うには、wp-config.phpを編集し、DB_HOST変数を仮想IPに変更する必要があります。
/** MySQL hostname */
define( 'DB_HOST', '10.0.0.111' );今後、WordpressはVIPとProxySQLを使用してデータベースに接続します。マスターノードに障害が発生した場合、ClusterControlがフェイルオーバーを実行します。
ご覧のとおり、新しいマスターが選出され、ProxySQLもホストグループ10の新しいマスター。
このブログ投稿で、Wordpress Webサイトの高可用性データベース環境を設計する方法と、ClusterControlを使用してそのすべての要素をデプロイする方法についてのアイデアが得られることを願っています。