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

WHMCSデータベースをMariaDBガレラクラスターに移行する方法

    WHMCSは、Webホスティング会社向けのオールインワンのクライアント管理、請求、およびサポートソリューションです。これは、ホスティングコントロールパネル自体と一緒に使用されるホスティング自動化の世界のリーダーの1つです。 WHMCSは、データベースプロバイダーとしてMySQL / MariaDBを使用して、LAMPスタックで実行されます。通常、WHMCSは、WHMCSインストールガイドに従うか、cPanel Site SoftwareやSoftaculousなどのソフトウェアインストーラーツールを使用して、スタンドアロンインスタンス（アプリケーションとデータベース）として個別にインストールされます。 3ノードのGaleraClusterに移行することで、データベースの可用性を高めることができます。

    このブログ投稿では、WHMCSデータベースをスタンドアロンのMySQLサーバー（WHM / cPanelサーバー自体によって提供される）から外部の3ノードのMariaDB Galeraクラスターに移行して、データベースの可用性を向上させる方法を紹介します。 WHMCSアプリケーション自体は、同じcPanelサーバーで実行され続けます。また、パフォーマンスを最適化するためのチューニングのヒントもいくつか紹介します。

    データベースクラスターの導入

    1. ClusterControlのインストール：
      $ whoami
root
$ wget https://severalnines.com/downloads/cmon/install-cc
$ chmod 755 install-cc
$ ./install-cc
      インストールが完了するまで、それに応じて指示に従ってください。次に、 http://192.168.55.50/clustercontrolに移動します （192.168.55.50はClusterControlホストのIPアドレスです）そして、パスワードとその他の必要な詳細をスーパー管理者ユーザーに登録します。
    2. ClusterControlからすべてのデータベースノードへのパスワードなしSSHのセットアップ：
      $ whoami
root
$ ssh-keygen -t rsa # Press enter on all prompts
$ ssh-copy-id 192.168.55.51
$ ssh-copy-id 192.168.55.52
$ ssh-copy-id 192.168.55.53
    3. 3ノードのMariaDBGaleraクラスターのデータベースデプロイメントを構成します。サポートされている最新バージョンのMariaDB10.3を使用します。 ノードの詳細を追加するときに「Enter」を押した後、すべての緑色のチェックが表示されることを確認してください。デプロイメントジョブが完了するまで待ちます。データベースクラスターがClusterControlに一覧表示されます。
    4. [管理]->[ロードバランサー]->[ProxySQL]->[ProxySQLのデプロイ]に移動して、ProxySQLノードをデプロイします（ClusterControlノードと同じ場所に配置します）。 。次の必要な詳細を指定します。 [データベースユーザーの追加]で、ClusterControlに新しいProxySQLおよびMySQLユーザーの設定を依頼できます。したがって、ユーザーを「portal_whmcs」として配置し、データベース「portal_whmcs。*」にALLPRIVILEGESを割り当てます。次に、[含める]のすべてのチェックボックスをオンにし、最後に[暗黙のトランザクションを使用していますか？]で[false]を選択します。

    展開が完了すると、トポロジビューの下に次のようなものが表示されます。

    関連リソースオーストラリアのトップホスティングプロバイダーは、ClusterControlを活用して、MySQLとProxySQLを使用したMariaDB-GaleraClusterを使用したcPanelでの高可用性MySQLのチュートリアル

    これでデータベースの展開が完了しました。このブログ投稿では、ロードバランサー層の冗長性については説明していません。これは、セカンダリロードバランサーを追加し、Keepalivedと一緒にストリング化することで実現できます。これについて詳しくは、「4.2。ProxySQLの高可用性」の章にあるProxySQLチュートリアルをご覧ください。

    WHMCSのインストール

    WHMCSをすでにインストールして実行している場合は、この手順をスキップできます。

    WHMCSには、ソフトウェアを使用するために事前に購入する必要がある有効なライセンスが必要であることに注意してください。無料の試用ライセンスは提供していませんが、30日間の返金保証があります。つまり、オファーの有効期限が切れる前に、請求なしでいつでもサブスクリプションをキャンセルできます。

    インストールプロセスを簡素化するために、サブドメインの1つであるselfportal.mytest.ioにcPanelサイトソフトウェア（WHMCSの手動インストールを選択できます）を使用します。 WHMでアカウントを作成したら、cPanel>ソフトウェア>サイトソフトウェア>WHMCSに移動します。 Webアプリケーションをインストールします。管理者ユーザーとしてログインし、ライセンスをアクティブ化してアプリケーションの使用を開始します。

    この時点で、WHMCSインスタンスはスタンドアロンセットアップとして実行されており、ローカルのMySQLサーバーに接続しています。

    データベースインフラストラクチャ全体のClusterControlSingleコンソールClusterControlのその他の新機能を確認するClusterControlを無料でインストール

    WHMCSデータベースのMariaDBガレラクラスターへの移行

    スタンドアロンのMySQLサーバーでWHMCSを実行すると、データベースの観点から、アプリケーションが単一障害点（SPOF）にさらされます。 MariaDB Galera Clusterは、組み込みのクラスタリング機能とマルチマスターアーキテクチャのサポートにより、データレイヤーに冗長性を提供します。これをProxySQLなどのデータベースロードバランサーと組み合わせると、アプリケーション自体への変更を最小限に抑えて、WHMCSデータベースの可用性を向上させることができます。

    ただし、Galera Clusterで効率的に作業するために、WHMCS（または他のアプリケーション）が従わなければならないベストプラクティスがいくつかあります。特に：

    • すべてのテーブルはInnoDB/XtraDBストレージエンジンで実行されている必要があります。
    • すべてのテーブルで主キーを定義する必要があります（複数列の主キーがサポートされており、一意キーはカウントされません）。

    インストールされているバージョンによっては、テスト環境のインストール（cPanel / WHM 11.78.0.23、サイトソフトウェア経由のWHMCS 7.6.0）では、上記の2つの点が要件を満たしていませんでした。デフォルトのcPanel/WHM MySQL構成には、/ etc/my.cnf内に次の行が含まれています。

    default-storage-engine=MyISAM

    上記の場合、WHMCSアドオンモジュールによって管理される追加のテーブルは、それらのモジュールが有効になっている場合、MyISAMストレージエンジン形式で作成されます。 2つのモジュール（新しいTLDとスタッフ掲示板）を有効にした後のストレージエンジンの出力は次のとおりです。

    MariaDB> SELECT tables.table_schema, tables.table_name, tables.engine FROM information_schema.tables WHERE tables.table_schema='whmcsdata_whmcs' and tables.engine <> 'InnoDB';
+-----------------+----------------------+--------+
| table_schema    | table_name           | engine |
+-----------------+----------------------+--------+
| whmcsdata_whmcs | mod_enomnewtlds      | MyISAM |
| whmcsdata_whmcs | mod_enomnewtlds_cron | MyISAM |
| whmcsdata_whmcs | mod_staffboard       | MyISAM |
+-----------------+----------------------+--------+

    MyISAMのサポートはGaleraで実験的なものです。つまり、本番環境で実行しないでください。最悪の場合、データの一貫性が損なわれ、非トランザクション的な性質のためにライトセットのレプリケーションエラーが発生する可能性があります。

    もう1つの重要な点は、すべてのテーブルに主キーを定義する必要があるということです。実行したWHMCSのインストール手順によっては（私たちの場合、cPanelサイトソフトウェアを使用してWHMCSをインストールしました）、次の出力に示すように、インストーラーによって作成されたテーブルの一部に主キーが定義されていません：

    > 
    MariaDB [information_schema]> SELECT TABLES.table_schema, TABLES.table_name FROM TABLES LEFT JOIN KEY_COLUMN_USAGE AS c ON (TABLES.TABLE_NAME = c.TABLE_NAME AND c.CONSTRAINT_SCHEMA = TABLES.TABLE_SCHEMA AND c.constraint_name = 'PRIMARY' ) WHERE TABLES.table_schema <> 'information_schema' AND TABLES.table_schema <> 'performance_schema' AND TABLES.table_schema <> 'mysql' and TABLES.table_schema <> 'sys' AND c.constraint_name IS NULL;
+-----------------+------------------------------------+
| table_schema    | table_name                         |
+-----------------+------------------------------------+
| whmcsdata_whmcs | mod_invoicedata                    |
| whmcsdata_whmcs | tbladminperms                      |
| whmcsdata_whmcs | tblaffiliates                      |
| whmcsdata_whmcs | tblconfiguration                   |
| whmcsdata_whmcs | tblknowledgebaselinks              |
| whmcsdata_whmcs | tbloauthserver_access_token_scopes |
| whmcsdata_whmcs | tbloauthserver_authcode_scopes     |
| whmcsdata_whmcs | tbloauthserver_client_scopes       |
| whmcsdata_whmcs | tbloauthserver_user_authz_scopes   |
| whmcsdata_whmcs | tblpaymentgateways                 |
| whmcsdata_whmcs | tblproductconfiglinks              |
| whmcsdata_whmcs | tblservergroupsrel                 |
+-----------------+------------------------------------+

    ちなみに、Galeraは、主キーのないテーブルが存在することを許可します。ただし、これらのテーブルではDELETE操作はサポートされていません。さらに、ノードのクラッシュ、ライトセット認定のパフォーマンスの低下、行が異なるノードで異なる順序で表示されるなど、はるかに大きな問題が発生する可能性があります。

    これを克服するには、次のセクションに示すように、移行計画にストレージエンジンとスキーマ構造を修正するための追加の手順を含める必要があります。

    移行計画

    前の章で説明した制限のため、移行計画は次のようにする必要があります。

    1. WHMCSメンテナンスモードを有効にする
    2. 論理バックアップを使用してwhmcsデータベースのバックアップを作成します
    3. Galeraの要件を満たすようにダンプファイルを変更します（ストレージエンジンの変換）
    4. Galeraノードの1つを起動し、残りのノードをシャットダウンします
    5. 選択したGaleraノードに復元します
    6. Galeraの要件を満たすようにスキーマ構造を修正します（主キーがありません）
    7. 選択したGaleraノードからクラスターをブートストラップします
    8. 2番目のノードを起動し、同期させます
    9. 3番目のノードを起動し、同期させます
    10. 適切なエンドポイントを指すデータベースを変更します
    11. WHMCSメンテナンスモードを無効にする

    新しいアーキテクチャは次のように説明できます。

    cPanelサーバー上のWHMCSデータベース名は「whmcsdata_whmcs」であり、このデータベースをClusterControlによってデプロイされた外部の3ノードのMariaDBGaleraクラスターに移行します。データベースサーバー上で、MariaDBロードバランサーとして機能するProxySQL（ClusterControlと同じ場所に配置）を実行し、WHMCSインスタンスに単一のエンドポイントを提供します。代わりに、クラスター上のデータベース名が「portal_whmcs」に変更されるため、簡単に区別できます。

    まず、 WHMCS>[設定]>[一般設定]>[一般]>[メンテナンスモード]>[有効にする]にチェックマークを付けて、サイト全体のメンテナンスモードを有効にします-有効にするとクライアントエリアにアクセスできなくなります 。これにより、データベースのバックアップ操作中にエンドユーザーからのアクティビティが発生しなくなります。

    Galeraにうまく適合するようにスキーマ構造にわずかな変更を加える必要があるため、2つの別々のダンプファイルを作成することをお勧めします。 1つはスキーマのみで、もう1つはデータのみです。 WHMサーバーで、rootとして次のコマンドを実行します。

    $ mysqldump --no-data -uroot whmcsdata_whmcs > whmcsdata_whmcs_schema.sql
$ mysqldump --no-create-info -uroot whmcsdata_whmcs > whmcsdata_whmcs_data.sql

    次に、スキーマダンプファイル内のすべてのMyISAMオカレンスを「InnoDB」に置き換える必要があります：

    $ sed -i 's/MyISAM/InnoDB/g' whmcsdata_whmcs_schema.sql

    ダンプファイルにMyISAM行がもうないことを確認します（何も返さないはずです）：

    $ grep -i 'myisam' whmcsdata_whmcs_schema.sql

    ダンプファイルをWHMサーバーからmariadb1（192.168.55.51）に転送します。

    $ scp whmcsdata_whmcs_* 192.168.55.51:~

    MySQLデータベースを作成します。 ClusterControlから、[管理]->[スキーマとユーザー]->[データベースの作成]に移動します。 データベース名を指定します。ここでは、「portal_whmcs」という別のデータベース名を使用します。それ以外の場合は、次のコマンドを使用してデータベースを手動で作成できます。

    $ mysql -uroot -p 
    MariaDB> CREATE DATABASE 'portal_whmcs';

    このデータベースのMySQLユーザーをその権限で作成します。 ClusterControlから、[管理]->[スキーマとユーザー]->[ユーザー]->[新しいユーザーの作成]に移動します 次のように指定します：

    MySQLユーザーを手動で作成することを選択した場合は、次のステートメントを実行します。

    $ mysql -uroot -p 
    MariaDB> CREATE USER 'portal_whmcs'@'%' IDENTIFIED BY 'ghU51CnPzI9z';
MariaDB> GRANT ALL PRIVILEGES ON portal_whmcs.* TO [email protected]'%';

    WHMCSアプリケーションがロードバランサーに対して認証できるようにするには、作成したデータベースユーザーをProxySQLにインポートする必要があることに注意してください。 ノード->ProxySQLノードを選択->ユーザー->ユーザーのインポートに移動します 次のスクリーンショットに示すように、「portal_whmcs」@「％」を選択します。

    次のウィンドウ（ユーザー設定）で、デフォルトのホストグループとしてホストグループ10を指定します。

    これで、復元の準備段階が完了しました。

    Galeraでは、単一ノードクラスターでmysqldumpを介して大きなデータベースを復元する方が効率的であり、これにより復元時間が大幅に改善されます。そうしないと、クラスター内のすべてのノードがmysqldump入力からのすべてのステートメントを認証する必要があり、完了するまでに時間がかかります。

    すでに3ノードのMariaDBGaleraClusterが実行されているので、一度に1ノードずつmariadb2とmariadb3でMySQLサービスを停止して適切なスケールダウンを行いましょう。 ClusterControlからデータベースノードをシャットダウンするには、ノード->ノードアクション->ノードの停止->続行に移動します。 。 ClusterControlダッシュボードから表示される内容は次のとおりです。クラスターサイズは1で、db1のステータスは同期およびプライマリです。

    次に、mariadb1（192.168.55.51）で、それに応じてスキーマとデータを復元します。

    $ mysql -uportal_whmcs -p portal_whmcs < whmcsdata_whmcs_schema.sql
$ mysql -uportal_whmcs -p portal_whmcs < whmcsdata_whmcs_data.sql

    インポートしたら、テーブル構造を修正して、必要な「id」列（テーブル「tblaffiliates」を除く）を追加し、欠落しているすべてのテーブルに主キーを追加する必要があります。

    $ mysql -uportal_whmcs -p
    MariaDB> USE portal_whmcs;
MariaDB [portal_whmcs]> ALTER TABLE `tblaffiliates` ADD PRIMARY KEY (id);
MariaDB [portal_whmcs]> ALTER TABLE `mod_invoicedata` ADD `id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY FIRST;
MariaDB [portal_whmcs]> ALTER TABLE `tbladminperms` ADD `id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY FIRST;
MariaDB [portal_whmcs]> ALTER TABLE `tblconfiguration` ADD `id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY FIRST;
MariaDB [portal_whmcs]> ALTER TABLE `tblknowledgebaselinks` ADD `id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY FIRST;
MariaDB [portal_whmcs]> ALTER TABLE `tbloauthserver_access_token_scopes` ADD `id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY FIRST;
MariaDB [portal_whmcs]> ALTER TABLE `tbloauthserver_authcode_scopes` ADD `id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY FIRST;
MariaDB [portal_whmcs]> ALTER TABLE `tbloauthserver_client_scopes` ADD `id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY FIRST;
MariaDB [portal_whmcs]> ALTER TABLE `tbloauthserver_user_authz_scopes` ADD `id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY FIRST;
MariaDB [portal_whmcs]> ALTER TABLE `tblpaymentgateways` ADD `id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY FIRST;
MariaDB [portal_whmcs]> ALTER TABLE `tblproductconfiglinks` ADD `id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY FIRST;
MariaDB [portal_whmcs]> ALTER TABLE `tblservergroupsrel` ADD `id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY FIRST;

    または、bashスクリプトのループを使用して、上記の繰り返しステートメントを変換できます。

    #!/bin/bash

db_user='portal_whmcs'
db_pass='ghU51CnPzI9z'
db_whmcs='portal_whmcs'
tables=$(mysql -u${db_user} "-p${db_pass}"  information_schema -A -Bse "SELECT TABLES.table_name FROM TABLES LEFT JOIN KEY_COLUMN_USAGE AS c ON (TABLES.TABLE_NAME = c.TABLE_NAME AND c.CONSTRAINT_SCHEMA = TABLES.TABLE_SCHEMA AND c.constraint_name = 'PRIMARY' ) WHERE TABLES.table_schema <> 'information_schema' AND TABLES.table_schema <> 'performance_schema' AND TABLES.table_schema <> 'mysql' and TABLES.table_schema <> 'sys' AND c.constraint_name IS NULL;")
mysql_exec="mysql -u${db_user} -p${db_pass} $db_whmcs -e"

for table in $tables
do
        if [ "${table}" = "tblaffiliates" ]
        then
                $mysql_exec "ALTER TABLE ${table} ADD PRIMARY KEY (id)";
        else
                $mysql_exec "ALTER TABLE ${table} ADD id INT NOT NULL AUTO_INCREMENT PRIMARY KEY FIRST";
        fi
done

    この時点で、残りのノードを起動してmariadb1と同期するのが安全です。 ノード->ピックdb2->ノードアクション->ノードの開始に移動して、mariadb2から開始します。 。 mariadb3を起動する前に、ジョブの進行状況を監視し、mariadb2が同期状態およびプライマリ状態にあることを確認してください（詳細については、[概要]ページを監視してください）。

    最後に、WHMCS構成ファイル内のポート6033にあるProxySQLホストを指すデータベースを変更します。この場合は、/ home / whmcsdata / public_html / configuration.php：

    にあります。 
    $ vim configuration.php
<?php
$license = 'WHMCS-XXXXXXXXXXXXXXXXXXXX';
$templates_compiledir = 'templates_c';
$mysql_charset = 'utf8';
$cc_encryption_hash = 'gLg4oxuOWsp4bMleNGJ--------30IGPnsCS49jzfrKjQpwaN';
$db_host = 192.168.55.50;
$db_port = '6033';
$db_username = 'portal_whmcs';
$db_password = 'ghU51CnPzI9z';
$db_name = 'portal_whmcs';

$customadminpath = 'admin2d27';

    WHMCS>[設定]>[一般設定]>[一般]>[メンテナンスモード]に移動して、WHMCSメンテナンスモードを無効にすることを忘れないでください。 。これで、データベース移行の演習は完了です。

    テストとチューニング

    ノード->ProxySQL->上位クエリの下にあるProxySQLのクエリエントリを確認することで確認できます。 ：

    最も繰り返される読み取り専用クエリ（カウントスターで並べ替えることができます）の場合、応答時間を改善し、バックエンドサーバーへのヒット数を減らすために、それらをキャッシュすることができます。任意のクエリにロールオーバーして[キャッシュクエリ]をクリックすると、次のポップアップが表示されます。

    宛先のホストグループのみを選択し、[ルールの追加]をクリックするだけです。次に、キャッシュされたクエリが[ルール]タブでヒットしたかどうかを確認できます：

    クエリルール自体から、読み取り（SELECT .. FOR UPDATEを除くすべてのSELECT）がホストグループ20に転送され、接続がすべてのノードに分散され、書き込み（SELECT以外）がホストグループ10に転送され、そこで接続が転送されることがわかります。 1つのGaleraノードにのみ転送されます。この構成により、マルチマスターセットアップによって引き起こされる可能性のあるデッドロックのリスクが最小限に抑えられ、全体としてレプリケーションのパフォーマンスが向上します。

    今のところ以上です。ハッピークラスタリング！


    1. Postgresの配列列の各要素に関数を適用するにはどうすればよいですか？

    2. SQLServerの「describetable」に相当するものは何ですか？

    3. MySQL Orderby a number、Nulls last

    4. SQLでNULLがNULLと一致しないのはなぜですか？