Percona XtraDB Cluster（PXC）やMariaDB Galera ClusterなどのGaleraベースのクラスター用にデータベースをアップグレードすることは、特に本番ベースの環境では難しい場合があります。高可用性の状態を失い、危険にさらす余裕はありません。
アップグレード手順は十分に文書化されている必要があり、理想的には、アップグレードの前に文書化、厳密なテスト、およびベンチマークを実行する必要があります。最も重要なことは、データベースのバージョンアップグレードの変更ログに基づいて、セキュリティと改善点を特定する必要があることです。
すべての懸念事項とともに、自動化はより効率的なアップグレードプロセスを実現し、人的エラーを回避し、RTOを改善するのに役立ちます。
PXC /MariaDBGaleraクラスターのアップグレードプロセスを管理する方法
PXC / MariaDB Galera Clusterをアップグレードするには、実行する必要があることと、問題が発生した場合に実行する必要があることをリストした適切なドキュメントとプロセスフローが必要です。つまり、ディザスタリカバリ計画もカバーする事業継続計画を立てる必要があります。トラブルが発生した場合にビジネスを失うわけにはいきません。
通常は、最初にテスト環境から開始します。テスト環境は、実稼働環境とまったく同じ設定と構成である必要があります。計画に従わない場合にどのような影響と影響が発生するかわからないため、本番環境のアップグレードを直接続行することはできません。
本番環境での作業は非常に機密性が高いため、ほとんどの場合、大幅な影響を回避するために、ダウンタイムとメンテナンスの時間枠が常にあります。
PCXまたはMariaDBGaleraClusterのアップグレードには、注意が必要な2つのタイプがあります。これらは、メジャーリリースアップグレードとマイナーリリースアップグレード、またはインプレースアップグレードと呼ばれることがよくあります。インプレースアップグレードでは、データベースと同じバイナリデータを使用して、データベースバージョンを最新のマイナーバージョンにアップグレードできます。データ自体に物理的な変更はありませんが、データベースのバイナリまたは基盤となるソフトウェアパッケージにのみ変更があります。
PCXまたはMariaDBGaleraクラスターのメジャーリリースへのアップグレード
メジャーリリースへのアップグレードは、特に実稼働環境では困難な場合があります。これには、複雑なタイプのデータベース構成と、PXCまたはMariaDBGaleraClusterの特別な組み込み機能が含まれます。時空間データ、タイムスタンプ付きデータ、マシンデータ、または多面的なデータは非常に保守的で、アップグレードの影響を受けやすくなっています。多くの主要な変更が行われたため、このプロセスにインプレースアップグレードを適用することはできません。非常に小さいデータ、べき等元で構成されるデータ、または簡単に生成できるデータがない限り、影響がデータに影響を与えないことがわかっている限り、安全に実行できます。
データ量が多い場合は、アップグレードプロセスを自動化することをお勧めします。ただし、主要なアップグレードフェーズ中に予期しない問題が発生する可能性があるため、アップグレードプロセスのすべてのシーケンスを自動化することは理想的なソリューションではない可能性があります。メジャーアップグレードでは、既知の結果を伴う反復的なステップとプロセスを自動化するのが最善です。いつでも、アップグレードプロセスの停止を回避するために、自動化プロセスが安全かどうかを評価するためのリソースが必要です。アップグレード後の自動テストも同様に重要であり、アップグレード後のプロセスの一部として含める必要があります。
PCXまたはMariaDBGaleraクラスターのマイナーリリースへのアップグレード
インプレースアップグレードと呼ばれるマイナーリリースアップグレードは、通常、アップグレードプロセスを実行するためのより安全なアプローチです。これは、このリリースの最も一般的な変更は、セキュリティとエクスプロイトのパッチまたは改善、バグ（通常は重大なもの）、または特に現在のハードウェアまたはOSに変更が適用されている場合にパッチを必要とする互換性の問題であり、データベースも変更しないためです。適切に機能します。影響は通常、最小限の影響で回復可能ですが、特定のマイナーバージョンアップグレードにプッシュされた変更ログを確認して読み取る必要があります。
アップグレードプロセスを実行するためにジョブを展開することは、自動化の理想的な例です。通常のフローは非常に反復的であり、ほとんどの場合、既存のPXCまたはMariaDBGaleraClusterに害を及ぼすことはありません。最も重要なのは、アップグレード後、自動テストを進めて、セットアップ、構成、効率、および機能が壊れていないかどうかを判断することです。
フィアスコを避けてください！準備をして、自動化してください！
データベースのマイナーアップグレード後、データベースで使用している機能が正しく機能していないため、クライアントからサポートを求められました。彼らは、ダウングレードする方法とそれがどれほど安全になるかについてのステップとプロセスを求めました。彼らの顧客は、彼らのアプリケーションが完全に機能していないと不平を言っていて、それは役に立たないと一般化していました。
このような小さな不具合であっても、腹を立てている顧客はあなたの製品に悪い発言をするかもしれません。このシナリオから学んだ教訓は、アップグレード後にテストに失敗すると、データベース内のすべての機能が期待どおりに機能しているという仮定につながるということです。
アップグレードプロセスを自動化する計画があるとします。自動化プロセスのタイプは、実行する必要のあるアップグレードのタイプによって異なることに注意してください。前述のように、メジャーアップグレードとマイナーアップグレードには、異なるアプローチがあります。そのため、オートマトンの設定が両方のデータベースソフトウェアのアップグレードに適用されない場合があります。
この時点で、理想的には自動化によってアップグレードプロセスが完了していることが期待されます。データベースがクライアント接続を受信する準備ができたので、厳密なテストフェーズを実行する必要があります。
mysql_upgradeを実行
アップグレードプロセスが完了したら、mysql_upgradeを実行することが非常に重要であり、非常に推奨されます。 mysql_upgradeは、次のことを実行して、アップグレードされたMySQLサーバーとの非互換性を探します。
-
mysqlスキーマのシステムテーブルをアップグレードして、新しい特権や機能を利用できるようにします。追加されました。
-
パフォーマンススキーマとsysスキーマをアップグレードします。
-
ユーザースキーマを調べます。
mysql_upgradeは、アップグレード後の最新バージョンの変更による非互換性などの問題があるかどうかを判断し、テーブルを修復して解決を試みます。そうでなければ、失敗した場合、自動化テストは失敗する必要があり、他の何かに進んではいけません。最初に調査し、手動で修復する必要があります。
mysql_upgradeが完了したら、発生したエラーをチェックして確認する必要があります。これをスクリプトに入れて、エラーログに「エラー」または「警告」ラベルがないか確認できます。そのようなものがあるかどうかを判断することは非常に重要です。自動テストには、エラートラップをキャッチする機能が必要です。エラーがごくわずかであるか予想される場合は、ユーザー入力の続行を待つことができます。それ以外の場合は、アップグレードプロセスを停止します。
TDD（テスト駆動開発）データベース環境は、検証される一連のテストケースがあり、検証が真（合格）か偽（不合格）かを判断するソフトウェア開発アプローチです。下のスクリーンショットにあるようなもの：
guru99.comの画像提供
これは、アプリケーションおよびデータベース内の不要なバグや論理エラーを回避するのに役立つ単体テストの一種です。データベースに無効なデータが保存されている場合、特に複雑な財務計算や数式が含まれている場合は、すべてのビジネス分析とトランザクションに悪影響を与えることを忘れないでください。
質問された場合、アップグレード後に単体テストを実行する必要が本当にありますか？もちろん！必ずしも実稼働環境でこれを実行する必要はありません。テスト段階、つまり最初にQA、開発/ステージング環境をアップグレードする際には、その領域に適用する必要があります。データは、少なくとも本番環境とほぼ同じまたはほぼ同じ正確なコピーである必要があります。ここでの目標は、望ましくない結果や間違いなく間違った論理結果を回避することです。もちろん、データには十分注意し、結果が検証テストに合格するかどうかを判断する必要があります。
本番環境で実行する場合は、実行してください。ただし、QA、開発、またはステージング環境で適用されるテストフェーズほど厳格にしないでください。これは、利用可能なメンテナンスウィンドウに基づいて時間を計画し、遅延やRTOの延長を回避する必要があるためです。
私の経験では、アップグレードフェーズ中に、顧客は、そのような機能が正しい結果を提供するかどうかを判断するために重要な、より迅速なアプローチを選択します。さらに、クエリをキャッシュしてデータベースをウォームアップするのに役立つため、一連のビジネス論理関数またはストアドプロシージャのテストを自動化するスクリプトを作成できます。
データベースの単体テストの準備をするときは、車輪の再発明を避けてください。代わりに、要件やニーズに適しているかどうかを選択できる利用可能なツールを確認してください。 Seleniumをチェックするか、このブログをチェックしてください。
使用できる最も一般的なツールは、Perconaのptアップグレードです。クエリ結果が異なるサーバーで同一であることを確認します。指定されたログと提供された接続（またはDSNと呼ばれる）に基づいてクエリを実行し、結果を比較して重要な違いを報告します。たとえば、tcpdumpを介してクエリを収集または分析するためのオプションとして、それ以上のものを提供します。
pt-upgradeの使用は簡単です。たとえば、次のコマンドで実行できます。
## Comparing via slow log for the given hosts
pt-upgrade h=host1 h=host2 slow.log
## or use fingerprints, useful for debugging purposes
pt-upgrade --fingerprints --run-time=1h mysqld-slow.log h=127.0.0.1,P=5091 h=127.0.0.1,P=5517
## or with tcpdump,
tcpdump -i eth0 port 3306 -s 65535 -x -n -q -tttt \
| pt-query-digest --type tcpdump --no-report --print \
| pt-upgrade h=host1 h=host2アップグレード、特にメジャーリリースのアップグレードが実行されたら、pt-upgradeを使用して続行し、結果に基づいて差異を特定するクエリ分析を実行することをお勧めします。 QAまたはステージングおよび開発環境で実行しているときに、テストフェーズでこれを実行することをお勧めします。これにより、続行する方が安全かどうかを判断できます。これを自動化ツールに追加して、任務を遂行する準備ができたら、これをプレイブックとして実行できます。
以前のブログでは、データベースを自動化するさまざまな方法を紹介しました。流行している最も一般的なツールは、これらのIaC（Infrastructure as Code）展開ソフトウェアツールです。 Puppet、Chef、SaltStack、またはAnsibleを使用して作業を行うことができます。
自動テストを実行することは常にAnsibleでした。これにより、職務ごとにプレイブックを作成できます。もちろん、状況や環境が異なるため、すべてを実行する1つのオートマトンを作成することはできません。以前に指定されたアップグレードタイプ（メジャーアップグレードとマイナーアップグレード）に基づいて、そのプロセスを区別する必要があります。インプレースアップグレードであっても、プレイブックが正しい仕事をすることを確認する必要があります。
ClusterControlはデータベース自動化の友です！
ClusterControlは、基本的な自動テストを実行するための優れたオプションです。 ClusterControlはテスト用のフレームワークではありません。単体テストを提供するためのツールではありません。ただし、これはデータベース管理および監視ツールであり、ソフトウェアのユーザーまたは管理者から要求されたトリガーに基づいて、多くの自動展開が組み込まれています。
ClusterControlはマイナーバージョンのアップグレードを提供します。これは、アップグレードを実行するときにDBAに便利な機能を提供します。 mysql_upgradeもオンザフライで実行します。したがって、手動で実行する必要はありません。 ClusterControlは、アップグレードする新しいバージョンも検出し、次の手順を実行することをお勧めします。障害が発生した場合、アップグレードは続行されません。
注意深く見ると、mysql_upgradeは正常に実行されます。マスターの自動アップグレードは推奨されておらず、実行されますが、続行するのに適切なアプローチではないためです。その場合は、新しいスレーブを昇格させてから、マスターをスレーブとして降格してアップグレードを実行する必要があります。
ClusterControlの優れている点は、エラーログのチェックを組み込み、単体テストを実行し、アドバイザを作成してクエリのIDを確認できることです。そうすることは難しくありません。以前のブログ「ClusterControlAdvisorを使用したSELinuxおよびMeltdown/Spectreのチェックの作成：パート1」を参照できます。これは、アップグレードが実行されたら、どのように利用して次のジョブをトリガーするかを示しています。 ClusterControlには、自動テストの現在のステータスを通知するために、お気に入りのサードパーティのアラートシステムに統合できるアラートまたはアラームが組み込まれています。