sql >> データベース >  >> RDS >> MariaDB

MySQLまたはPostgreSQLを使用したDrupalWebサイトのデータベーススイッチオーバーとフェイルオーバー

    Drupalは、小規模から大規模の企業Webサイトまですべてを作成するように設計されたコンテンツ管理システム(CMS)です。 Drupalでは1,000,000を超えるWebサイトが実行されており、毎日使用する多くのWebサイトやアプリケーション(これを含む)を作成するために使用されます。 Drupalには、簡単なコンテンツオーサリング、信頼性の高いパフォーマンス、優れたセキュリティなど、優れた標準機能のセットがあります。 Drupalを際立たせているのは、モジュール性がそのコア原則の1つであるため、その柔軟性です。

    Drupalは、統合されたデジタルフレームワークを作成するための優れた選択肢でもあります。利用可能な何千ものアドオンで拡張できます。これらのモジュールは、Drupalの機能を拡張します。テーマを使用すると、コンテンツのプレゼンテーションをカスタマイズできます。ディストリビューション(Drupalバンドル)は、スターターキットとして使用できるバンドルです。これらすべての機能を使用して、Drupalのコア機能を強化したり、Drupalを外部サービスと統合したりするために組み合わせることができます。強力でスケーラブルなコンテンツ管理ソフトウェアです。

    Drupalは、データベースを使用してWebコンテンツを保存します。 DrupalベースのWebサイトまたはアプリケーションで大量のトラフィックが発生している場合、データベースサーバーに影響を与える可能性があります。このような状況では、データベースをオンラインに保つために、負荷分散、高可用性、および冗長アーキテクチャが必要になります。

    このブログの調査を開始したとき、この問題に対する多くの回答がオンラインにあることに気付きましたが、推奨される解決策は非常に古いものでした。これは、WordPressによる市場シェアの増加の結果、オープンソースコミュニティが縮小した結果である可能性があります。私が見つけたのは、マスター/マスター(高可用性)またはマスター/マスター/スレーブ(高可用性/高パフォーマンス)を使用して高可用性を実装する例です。

    Drupalはさまざまなデータベースをサポートしていますが、当初はMySQLのバリアントを使用して設計されていました。 MySQLの使用は完全にサポートされていますが、実装できるより良いアプローチがあります。ただし、これらの他のアプローチを実装すると、適切に実行されない場合、Webサイトで大量のダウンタイムが発生し、アプリケーションでパフォーマンスの問題が発生し、スレーブへの書き込みの問題が発生する可能性があります。ダウンタイムなしでサーバーのアップグレードまたはパッチ(ハードウェアまたはソフトウェア)を適用するにはフェイルオーバーが必要なため、メンテナンスの実行も困難になります。これは、大量のデータがあり、ビジネスに大きな影響を与える可能性がある場合に特に当てはまります。

    これらは起こりたくない状況です。そのため、このブログでは、MySQLまたはPostgreSQLデータベースにデータベースフェイルオーバーを実装する方法について説明します。

    DrupalWebサイトにデータベースフェイルオーバーが必要な理由

    Wikipediaから「フェイルオーバーとは、以前にアクティブだったアプリケーション、サーバー、システム、ハードウェアコンポーネント、またはネットワークの障害または異常終了時に、冗長またはスタンバイのコンピューターサーバー、システム、ハードウェアコンポーネント、またはネットワークに切り替えることです。フェイルオーバーとスイッチオーバーは基本的に同じ操作ですが、フェイルオーバーは自動であり、通常は警告なしに動作しますが、スイッチオーバーには人間の介入が必要です。」

    データベース操作では、スイッチオーバーは手動フェイルオーバーにも使用される用語です。つまり、フェイルオーバーを操作するには人が必要です。フェイルオーバーは、テーブルの偶発的な削除/ドロップ、ビジネスへの影響を引き起こす長時間のダウンタイム、データベースの破損、システムレベルの破損などの不要な問題を分離するため、管理者にとって便利です。

    データベースフェイルオーバーは、物理的または仮想的に、複数のデータベースノードで構成されます。理想的には、フェイルオーバーでは別のノードに切り替える必要があるため、ホストが単一のホストで複数のデータベースインスタンスを実行している場合は、別のデータベースサーバーに切り替えることもできます。それでもスイッチオーバーまたはフェイルオーバーのいずれかである可能性がありますが、通常は、現在のホストで大災害が発生した場合に備えて、冗長性と高可用性が向上します。

    DrupalのMySQLフェイルオーバー

    Drupalベースのアプリケーションのフェイルオーバーを実行するには、データベースによって処理されるデータが区別されたり、分離されたりしないことが必要です。利用可能なソリューションはいくつかありますが、それらのいくつかについては、以前のSevereninesブログですでに説明しています。 MySQLレプリケーションのフェイルオーバーの概要-101ブログを読むことをお勧めします。

    マスタースレーブスイッチオーバー

    MySQLフェイルオーバーの最も一般的なアプローチは、マスタースレーブスイッチオーバーまたは手動フェイルオーバーを使用することです。ここで実行できるアプローチは2つあります。

    • 一般的な非同期マスタースレーブレプリケーションを使用してデータベースを実装できます。
    • または、GTIDベースのレプリケーションを使用して非同期マスタースレーブレプリケーションで実装できます。

    別のマスターへの切り替えは、より迅速かつ簡単になります。これは、次のMySQL構文で実行できます。

    mysql> SET GLOBAL read_only = 1; /* enable read-only */
    
    mysql> CHANGE MASTER TO MASTER_HOST = '<hostname-or-ip>', MASTER_USER = '<user>', MASTER_PASSWORD = '<password>', MASTER_LOG_FILE = '<master-log-file>', MASTER_LOG_POS=<master_log_position>; /* master information to connect */
    
    mysql> START SLAVE; /* start replication */
    
    mysql> SHOW SLAVE STATUS\G /* check replication status */

    またはGTIDを使用すると、簡単に実行できます

    ...
    
    mysql> CHANGE MASTER TO MASTER_HOST = '<hostname-or-ip>', MASTER_USER = '<user>', MASTER_PASSWORD = '<password>', MASTER_AUTO_POSITION = 1; /* master information to connect */
    
    ...
    
    Wit

    非GTIDアプローチを使用するには、最初にマスターのログファイルとマスターのログ位置を決定する必要があります。これは、切り替える前にマスターノードでマスターのステータスを確認することで判断できます。

    mysql> MASTER STATUS;

    サーバーを強化してsync_binlog=1とinnodb_flush_log_at_trx_commit=1を追加することも検討してください。マスターがクラッシュした場合、マスターからのトランザクションがスレーブと同期しない可能性が高くなります( s)。このような場合、プロモートされたマスターは一貫性のあるデータソースノードになる可能性が高くなります。

    ただし、これはDrupalデータベースにとって最善のアプローチではない可能性があります。これは、突然ダウンするなど、正しく実行されない場合、長いダウンタイムが発生する可能性があるためです。マスターデータベースノードでバグが発生し、データベースがクラッシュした場合は、アプリケーションが、新しいマスターとしてスタンバイ状態で待機している別のデータベースを指すか、スレーブをマスターに昇格させる必要があります。どのノードが引き継ぐかを正確に指定してから、そのノードのラグと整合性を判断する必要があります。これを実現することは、SET GLOBAL read_only=1を実行するほど簡単ではありません。マスターを…(など)に変更すると、スタンバイサーバーまたはプロモートされたマスターに存在する必要のある実行可能なトランザクションを調べて、それを実行するために、より詳細な分析が必要な特定の状況があります。

    MHAを使用したDrupalフェイルオーバー

    自動および手動フェイルオーバーの最も一般的なツールの1つは、MHAです。それは長い間存在していて、今でも多くの組織で使用されています。 MHAの主な一般的な問題と、それらまたはMySQL高可用性ツールの修正方法-MHA、MRM、およびClusterControlの比較に関するこれらの以前のブログを確認できます。

    オーケストレーターを使用したDrupalフェイルオーバー

    オーケストレーターは現在広く採用されており、GithubやBooking.comなどの大規模な組織で使用されています。フェイルオーバーを管理できるだけでなく、トポロジー管理、ホスト検出、リファクタリング、およびリカバリーも可能にします。ここに素晴らしい外部ブログがあり、Orchestratorを使用したフェイルオーバーメカニズムについて学ぶことが非常に役立つことがわかりました。これは2部構成のブログシリーズです。パート1とパート2。

    MaxScaleを使用したDrupalフェイルオーバー

    MaxScaleは、MariaDBサーバー用に設計されたロードバランサーであるだけでなく、MariaDBの高可用性、スケーラビリティ、セキュリティを拡張すると同時に、基盤となるデータベースインフラストラクチャからアプリケーション開発を分離することでアプリケーション開発を簡素化します。 MariaDBを使用している場合は、MaxScaleが適切なテクノロジーになる可能性があります。 MaxScaleフェイルオーバーメカニズムの使用方法については、以前のブログをご覧ください。

    ClusterControlを使用したDrupalフェイルオーバー

    SeveralninesのClusterControlは、さまざまなデータベース管理および監視ソリューションを提供します。当社が提供するソリューションの一部は、自動フェイルオーバー、手動フェイルオーバー、およびクラスター/ノードのリカバリーです。これは、仮想データベース管理者として機能するかのように非常に役立ち、クラスターが「パニックモード」になっている場合に、システムによってリカバリが管理されている間、リアルタイムで通知します。 ClusterControlフェイルオーバーの詳細については、このブログ「ClusterControlを使用してデータベースフェイルオーバーを自動化する方法」を確認してください。

    その他のMySQLソリューション

    フェイルオーバーする場合でも、古いアプローチのいくつかは引き続き適用できます。 MMM、MRMがあります。または、グループレプリケーションまたはGaleraをチェックアウトできます(注:Galeraは非同期ではなく、同期レプリケーションを使用します)。 Galeraクラスターでのフェイルオーバーは、非同期レプリケーションの場合と同じようには機能しません。 Galeraを使用すると、任意のノードに書き込むことができます。マスタースレーブアプローチを実装する場合は、クラスターのアクティブライターとなる別のノードにアプリケーションを転送できます。

    DrupalPostgreSQLフェイルオーバー

    DrupalはPostgreSQLをサポートしているため、PostgreSQLのフェイルオーバーまたはスイッチオーバープロセスを実装するためのツールもチェックアウトします。 PostgreSQLは組み込みのストリーミングレプリケーションを使用しますが、論理レプリケーション(バージョン10でPostgreSQLのコア要素として追加された)を使用するように設定することもできます。

    pg_ctlclusterを使用したDrupalフェイルオーバー

    ご使用の環境がUbuntuの場合、pg_ctlclusterを使用すると、フェイルオーバーを実現するためのシンプルで簡単な方法です。たとえば、次のコマンドを実行するだけです。

    $ pg_ctlcluster 9.6 pg_7653 promote
    またはRHEL/Centosでは、pg_ctlコマンドを次のように使用できます

    $ sudo -iu postgres /usr/lib/postgresql/9.6/bin/pg_ctl promote -D  /data/pgsql/slave/data
    
    server promoting

    Recovery.confのtrigger_fileで指定されたファイル名とパスを使用してトリガーファイルを作成することにより、ログ配布スタンバイサーバーのフェイルオーバーをトリガーすることもできます。

    ここでは、スタンバイプロモーションまたはスレーブプロモーションに注意する必要があります。これは、1つのマスターのみが読み取り/書き込み要求を受け入れるようにする必要がある場合があるためです。つまり、切り替えを行うときに、前のマスターがリラックスまたは停止していることを確認する必要がある場合があります。

    プライマリサーバーからスタンバイサーバーへのスイッチオーバーまたは手動フェールオーバーの処理は高速ですが、フェールオーバークラスターの再準備には時間がかかります。プライマリからスタンバイに定期的に切り替えることは、メンテナンスのために各システムで定期的なダウンタイムを可能にするため、便利な方法です。これは、フェイルオーバーメカニズムのテストとしても機能し、必要なときに実際に機能することを確認します。書面による管理手順を常にお勧めします。

    DrupalPostgreSQL自動フェイルオーバー

    手動によるアプローチの代わりに、自動フェイルオーバーが必要になる場合があります。これは、ハードウェア障害または仮想マシンの破損が原因でサーバーがダウンした場合に特に必要です。 Drupalアプリケーションのダウンタイムを減らすために、フェイルオーバーを自動的に実行するアプリケーションが必要になる場合もあります。次に、自動フェイルオーバーに利用できるこれらのツールのいくつかについて説明します。

    パトロニを使用したDrupalフェイルオーバー

    Patroniは、Pythonを使用して独自のカスタマイズされた高可用性ソリューションを作成するためのテンプレートであり、最大限のアクセシビリティを実現するために、ZooKeeperなどの分散構成ストア、Consul、Kubernetesなどがあります。 HA PostgreSQLをデータセンター(またはその他の場所)に迅速に導入しようとしているデータベースエンジニア、DBA、DevOpsエンジニア、およびSREは、それが役立つことを願っています

    Pgpoolを使用したDrupalフェイルオーバー

    Pgpool-IIは、PostgreSQLサーバーとPostgreSQLデータベースクライアントの間にあるプロキシソフトウェアです。自動フェイルオーバーのほかに、接続プール、負荷分散、レプリケーション、超過接続の制限など、複数の機能があります。このツールの詳細については、3部構成のブログをご覧ください。パート1、パート2、パート3。

    pglookoutを使用したDrupalフェイルオーバー

    pglookoutは、PostgreSQLレプリケーション監視およびフェイルオーバーデーモンです。 pglookoutは、データベースノードとそのレプリケーションステータスを監視し、そのステータスに従って動作します。たとえば、事前定義されたフェイルオーバーコマンドを呼び出して、前のマスターが見つからなくなった場合に新しいマスターをプロモートします。

    pglookoutは、dbノード自体にインストールされるノードタイプと、どこにでもインストールできるオブザーバーノードの2つの異なるノードタイプをサポートします。 PostgreSQL DBノードでpglookoutを使用する目的は、クラスターのレプリケーションステータスを監視し、それに応じて動作することです。オブザーバーは、クラスターステータスを監視するだけで、クラスター状態に別の視点を与えることができます。

    repmgrを使用したDrupalフェイルオーバー

    repmgrは、PostgreSQLサーバーのクラスターでレプリケーションとフェイルオーバーを管理するためのオープンソースツールスイートです。スタンバイサーバーをセットアップし、レプリケーションを監視し、フェイルオーバーや手動スイッチオーバー操作などの管理タスクを実行するツールを使用して、PostgreSQLの組み込みのホットスタンバイ機能を強化します。

    repmgrは、9.0で導入されて以来、PostgreSQLの組み込みレプリケーションメカニズムの高度なサポートを提供してきました。現在のrepmgrシリーズであるrepmgr4は、カスケードレプリケーション、タイムラインスイッチング、レプリケーションプロトコルを介したベースバックアップなど、PostgreSQL9.3から導入されたレプリケーション機能の最新の開発をサポートしています。

    ClusterControlを使用したDrupalフェイルオーバー

    ClusterControlは、PostgreSQLの自動フェイルオーバーをサポートしています。インシデントが発生した場合、スレーブを自動的にマスターステータスに昇格させることができます。 ClusterControlを使用すると、スタンドアロン、レプリケート、またはクラスター化されたPostgreSQLデータベースをデプロイすることもできます。 1回のアクションでノードを簡単に追加または削除することもできます。

    その他のPostgreSQLDrupalフェイルオーバーソリューション

    このブログでは見逃したかもしれない自動フェイルオーバーソリューションが確かにあります。もしそうなら、以下にコメントを追加してください。特にDrupalのWebサイトまたはアプリケーションのフェイルオーバーの実装とセットアップに関するあなたの考えと経験を知ることができます。

    Drupalフェイルオーバーの追加ソリューション

    前述のツールはフェイルオーバーの問題の解決策を確実に処理しますが、フェイルオーバーを非常に簡単かつ安全にし、データベースレイヤーを完全に分離するツールを追加することで十分です。

    ProxySQLを使用したDrupalフェイルオーバー

    ProxySQLを使用すると、Drupal WebサイトまたはアプリケーションをProxySQLサーバーホストにポイントするだけで、書き込みを受信するノードと読み取りを受信するノードを指定できます。魔法はTCP層内で透過的に発生し、アプリケーション/Webサイトの構成に変更を加える必要はありません。それに加えて、ProxySQLは、データベーストラフィックの書き込みおよび読み取り要求のロードバランサーとしても機能します。これは、MySQLデータベースバリアントを使用している場合にのみ適用されます。

    KeepalivedでHAProxyを使用したDrupalフェイルオーバー

    HAProxyとKeepalivedを使用すると、Drupalのデータベース内に高可用性と冗長性が追加されます。フェイルオーバーが必要な場合は、アプリケーションがデータベースレイヤー内で何が起こっているかを知らなくてもフェイルオーバーを実行できます。 KeepalivedでセットアップしたvrrpIPをアプリケーションにポイントするだけで、すべてがアプリケーションから完全に分離されて処理されます。自動フェイルオーバーの実行は、アプリケーションによって透過的かつ無意識のうちに処理されるため、災害が発生してリカバリまたはフェイルオーバーが適用された場合など、一度変更を加える必要はありません。この設定の良いところは、MySQLデータベースとPostgreSQLデータベースの両方に適用できることです。これを行う方法の詳細については、ブログPostgreSQL Load Balancing Using HAProxy&Keepalivedを確認することをお勧めします。

    上記のすべてのオプションは、ClusterControlでサポートされています。データベースをデプロイまたはインポートしてから、ProxySQL、MaxScale、またはHAProxy&Keepalivedをデプロイできます。すべてが管理、監視され、お客様の側で追加の構成を必要とせずに自動的にセットアップされます。それはすべてバックグラウンドで行われ、すぐに生産できる状態になります。

    結論

    常にオンのDrupalWebサイトまたはアプリケーションを使用すると、特に大量のトラフィックが予想される場合は、作成が複雑になる可能性があります。ただし、適切なツール、適切なセットアップ、および適切なテクノロジースタックがあれば、高可用性と冗長性を実現できます。

    そうでない場合は?それでは、ClusterControlがそれをセットアップし、維持します。または、このブログに記載されているテクノロジーを使用してセットアップを作成することもできます。そのほとんどは、ニーズに対応するオープンソースの無料ツールです。


    1. IDENTITY列を広げることによる影響の最小化–パート2

    2. アセットフォルダに配置されているAndroidのデータベースファイルからバージョン番号を読み取る方法

    3. java.sql.SQLException:ORA-03115:サポートされていないネットワークデータ型または表現

    4. SQLServerのカーソルタイプ-静的カーソルのみを転送| SQLServerチュートリアル/TSQLチュートリアル