記事ディレクトリ
序文
MySQL高可用性システム
MySQLは高可用性です。名前が示すように、MySQLホストまたはサービスで障害が発生した場合、別のホストがその作業をすぐに引き継ぐことができ、最小要件はデータの一貫性を保証することです。したがって、MySQLの高可用性システムで達成すべき目標は次のとおりです。
（1）データの整合性の保証これは最も基本的で前提条件です。プライマリデータとセカンダリデータに不整合がある場合、切り替えは実行できません。もちろん、ここでの整合性も相対的ですが、最終的な整合性を実現する必要があります。
（2）高速フェイルオーバー。マスターで障害が発生した場合、それはマシン障害またはインスタンス障害である可能性があります。ビジネスが最短の時間で影響を受けるように、ビジネスを最短の時間でスタンバイノードに切り替えることができることを確認する必要があります。
（3）日常のメンテナンスを簡素化し、高可用性プラットフォームを介して高可用性の展開、メンテナンス、監視、その他のタスクを自動的に完了します。これにより、DBAの手動操作を最大限に解放し、日常の操作とメンテナンスの効率を向上させることができます。
（4）統合管理レプリケーションセットが多数ある場合、高可用性インスタンス情報、監視情報、スイッチング情報を一元管理できます。
（5）高可用性の展開は、既存のデータベースアーキテクチャに影響を与えないはずです。高可用性の展開のためにデータベースアーキテクチャを変更または調整する必要がある場合、コストが増加します。
現在のMySQL高可用性ソリューションは、MMM、ハートビート+ drbd、およびNDBクラスターなど、ある程度の高データベース可用性を実現できます。MariaDBのGalera ClusterとMySQL 5.7.17 Group Replicationもあります。これらの高可用性ソフトウェアには、独自の長所と短所があります。高可用性ソリューションを選択する場合、それは主にデータの整合性に対するビジネスの要件に基づいています。最後に、データベースの高可用性と信頼性のため、MySQL GPは本番環境では使用できないため、MHAアーキテクチャを使用することをお勧めしますが、将来的には本番環境で徐々に使用されると思います。
1. MHAテクノロジーの紹介
MHA（Master High Availability）は現在、MySQLの高可用性のための比較的成熟したソリューションです。これは、日本のDeNA企業（現在Facebookで働いています）のyoushimatonによって開発されました。これは、MySQLの高可用性のためのフェイルオーバーおよびマスターソリューションの優れたセットです。高可用性ソフトウェアのプロモーションから。MySQLフェイルオーバープロセスでは、MHAはデータベースフェイルオーバー操作を0〜30秒以内に自動的に完了でき、フェイルオーバーのプロセスでは、MHAはデータの一貫性を最大限に確保して真を実現できます。ある意味で高可用性。フェイルオーバーに加えて、MHAはオンラインマスタースイッチングもサポートしています。これは非常に安全で効率的であり、ブロックする書き込み時間（0.5〜2秒）のみが必要です。
ソフトウェアは、MHAマネージャー（管理ノード）とMHAノード（データノード）の2つの部分で構成されています。MHAマネージャーは、複数のマスター/スレーブクラスターを管理するために別のマシンにデプロイすることも、単一のスレーブノードにデプロイすることもできます。MHAノードは各MySQLサーバーで実行されます。MHAマネージャーはクラスター内のマスターノードを定期的に検出します。マスターに障害が発生すると、最新のデータでスレーブを自動的に新しいマスターにアップグレードし、他のすべてのスレーブを新しいマスターにリダイレクトします。マスター。フェイルオーバープロセス全体は、アプリケーションに対して完全に透過的です。
2. MHAは次の機能を提供します
現在、MHAは主に1マスターと複数スレーブのアーキテクチャをサポートしています。MHAを構築するには、レプリケーションクラスタに少なくとも3つのデータベースサーバーが必要です。1つはマスター、2つはスレーブ、つまり1つはマスター、1つはスタンバイマスター、もう1つはスレーブとして機能します。もちろん、コストを考慮している場合は、2つのノードのMHAを使用することもできます。
要約すると、MHAは次の機能を提供します。
（1）マスター自動監視およびフェイルオーバー統合（自動マスター監視およびフェイルオーバー）
（2）MHAはレプリケーショングループ内のマスターのステータスを監視でき、ハングした場合は自動的にフェイルオーバーできます。
（3）MHAは、すべてのスレーブの差分リレーログを通じてデータの一貫性を保証します。
（4）MHAがフェイルオーバーとこれらのアクションのログ補正を実行している場合、通常は10〜30秒しかかかりません。
（5）通常の状況では、MHAは最新のスレーブを新しいマスターとして選択しますが、どのマスターを候補にするかを指定することもできるため、新しいマスターが選出されると、これらのホストから選択されます。
（6）MHAではレプリケーション環境を中断させるような整合性の問題は発生しませんので、ご安心ください。
MHA自動フェイルオーバーのプロセスでは、MHAはダウンしたメインサーバーからのバイナリログを保存して、データが最大限に失われないようにしますが、これが常に可能であるとは限りません。たとえば、メインサーバーハードウェアに障害が発生した場合、またはssh経由でアクセスできない場合、MHAはバイナリログを保存できず、フェールオーバーのみを行い、最新のデータを失います。MySQL 5.5以降の準同期レプリケーションを使用すると、データ損失のリスクを大幅に削減できます。MHAは半同期レプリケーションと組み合わせることができます。最新のバイナリログを受信したスレーブが1つだけの場合、MHAは最新のバイナリログを他のすべてのスレーブサーバーに適用できるため、すべてのノードのデータの一貫性を保証できます。
（7）手動対話型マスターフェイルオーバー（対話型手動開始マスターフェイルオーバー）
MHAは手動で対話的にフェールオーバーを実行するように構成でき、マスターのステータスの監視をサポートしていません。
（8）非対話型マスターフェイルオーバー（非対話型マスターフェイルオーバー）
非対話型の自動フェイルオーバーは、監視マスターステータス機能を提供しません。監視は他のコンポーネント（Pacemakerハートビートなど）で実行できます。
（9）マスターを別のホストにオンラインで切り替える
より高速で優れたマスターがあり、古いマスターを新しいマスターに置き換える予定がある場合、この機能はそのようなシナリオに特に適しています。
マスターが本当にダウンしているわけではありませんが、マスターの定期的なメンテナンスには多くのニーズがあります。
3. MHAの利点
-
マスターフェイルオーバーとスレーブ昇格は非常に高速です。
-
自動検出、複数検出、切り替えプロセス中に他のスクリプトインターフェイスを呼び出すためのサポート。
-
マスタークラッシュによってデータの不整合が発生することはなく、データを自動的に入力してデータの整合性を維持します。
-
レプリケーションの設定を変更する必要がなく、シンプルで簡単に展開でき、既存のアーキテクチャに影響を与えません。
-
MHAを展開し、マルチインスタンスの集中管理をサポートするために、多くの追加のマシンを追加する必要はありません。
-
パフォーマンスへの影響はありません。
-
オンライン切り替えをサポートします。
-
クロスストレージエンジン、任意のエンジンをサポートします。
4. MHAワークフロー
次の図は、MHAマネージャーを介してマスタースレーブレプリケーションの複数のセットを管理する方法を示しています。MHAの動作原理は、次のように要約できます。
1. MHAはマスターとフェイルオーバーをどのように監視しますか？
1.1レプリケーション設定を確認し、現在のマスターステータスを確認する
すべてのホストを接続すると、MHAが自動的に現在のマスターを確認します。構成ファイルでマスターを指定する必要はありません。
スレーブのいずれかが電話を切ると、スクリプトは直ちに終了し、監視を停止します。
MHAノードノードに必要なスクリプトがインストールされていない場合、MHAはこの段階で終了し、監視は停止します。
1.2監視マスター
マスターがハングアップするまでマスターを監視します。
この段階では、MHAはスレーブを監視していません。スレーブでの操作の停止/再起動/追加/削除は、現在のMHA監視プロセスに影響を与えません。スレーブを追加または削除する場合は、構成ファイルを更新してください。できればMHAを再起動してください。
1.3マスターに障害が発生したかどうかを確認する
MHAマネージャーが3つの間隔でマスターサーバーに接続できない場合、この段階に入ります。
secondary_check_scriptを設定すると、MHAはスクリプトを呼び出して2番目のチェックを行い、マスターが本当にダウンしているかどうかを判断します。
次のステップは、masterha_master_switchのワークフローです。
1.4スレーブ構成を再度確認する
不正なレプリケーション構成が見つかった場合（一部のスレーブマスターが同じではない場合）、MHAは監視を停止し、エラーを報告します。ignore_failを無視するように設定できます。
この手順はセキュリティを考慮したものであり、コピーされた構成ファイルが変更されている可能性が高いため、再確認することをお勧めします。
最後のフェイルオーバー（フェイルオーバー）の状況を確認する
最後のフェイルオーバーがエラーを報告した場合、または最後のフェイルオーバーがあまりにも最近に終了した場合（デフォルトは3日）、MHAは監視を停止してフェイルオーバーを停止し、masterha_managerコマンドでignore_last_failoverおよびwait_on_failover_errorを設定してこの検出を変更します。これも安全上の理由によるものです。頻繁なフェイルオーバー。ネットワークに問題がないか、その他のエラーがないかを確認しますか？
1.5障害が発生したマスターサーバーをシャットダウンする（オプション）
master_ip_failover_scriptやshutdown_scriptが構成ファイルで定義されている場合、MHAはこれらのスクリプトを呼び出します。
スプリットブレインを避けるためにデッドマスターをオフにします（議論の余地があります）。
1.6新しいマスターを復元する
クラッシュしたマスターサーバーからマネージャーにbinlogを保存します（可能な場合）
デッドマスターがSSHで接続できる場合は、最新のスレーブのend_log_pos（Read_Master_Log_Pos）の位置からバイナリログをコピーします。
新しいマスターの選出
一般的に、構成ファイルの設定に従って、誰を選ぶかを決定します。候補マスターをセットアップする場合は、候補マスターを設定します。一部のホストをセットアップする場合は、決して選択せず、no_master = 1を設定します。最新のスレーブを確認します（このスレーブは最新のリレーログ）。
新しいマスターを復元して昇格する
古いマスターbinlogによると、差分ログが生成され、ログが新しいマスターに適用されます。このステップでエラー（重複キーエラーなど）が発生した場合、MHAは回復を停止し、残りのスレーブも回復を停止します。
（2）MHAはどのようにしてすばやくマスターをオンラインに切り替えますか？
次の手順は、masterha_master_switch—master_state = aliveが行うことです。
2.1レプリケーション設定を確認し、現在のマスターステータスを確認する
構成ファイルにリストされているすべてのホストに接続すると、MHAが自動的に現在のマスターを確認します。構成ファイルでマスターを指定する必要はありません。
マスターでフラッシュテーブルコマンドを実行します（オプション）。これにより、FLUSH TABLES WITH READ LOCKの時間を短縮できます。
マスターもフェイルオーバーも監視しません。
以下の条件を満たしているか確認してください。
A.すべてのスレーブでIOスレッドが実行されていますか？
B. SQLスレッドはすべてのスレーブで実行されていますか？
C. Seconds_Behind_Masterが2秒未満かどうか（--running_updates_limit = N）。
D.マスターに2秒を超える長い更新ステートメントがないかどうか。
2.2新しいマスターを確認する
新しいマスターを設定する必要があります：-new_master_hostパラメーター。
元のマスターと新しいマスターのレプリケーションフィルター条件は同じである必要があります（binlog-do-dbおよびbinlog-ignore-db）。
2.3現在のマスターが書き込みを停止する
構成でmaster_ip_online_change_scriptを定義すると、MHAがそれを呼び出します。SET GLOBAL read_only = 1を設定すると、書き込みを完全に防止できます。
古いマスターでFLUSH TABLES WITH READ LOCKを実行して、すべての書き込みを防止します（–skip_lock_all_tablesはこの手順を無視できます）。
2.4他のスレーブが現在のマスターに追いつくのを待って、遅延なく同期する
この関数MASTER_LOG_POS（）を呼び出します。
2.5新しいマスターを書き込めることを確認する
SHOW MASTER STATUSを実行して、バイナリログファイルの名前と新しいマスターの位置を確認します。
master_ip_online_change_scriptが設定されている場合、それが呼び出されます。書き込み権限を持つユーザーを作成できます、SET GLOBAL read_only = 0。
2.6他のスレーブが新しいマスターを指すようにする
CHANGE MASTERとSTART SLAVEを並行して実行します。
MHAコンポーネントの
概要MHAソフトウェアは、マネージャーツールキットとノードツールキットの2つの部分で構成されています。
Managerツールキットには、主に次のツールが含まれています。
（1）masterha_check_ssh #MHAのSSH構成ステータスを確認します。
（2）masterha_check_repl #MySQLレプリケーションステータスをチェックします。
（3）masterha_manger #MHAを開始します。
（4）masterha_check_status＃現在のMHA実行ステータスを検出します。
（5）masterha_master_monitor＃マスターがダウンしているかどうかを検出します。
（6）masterha_master_switch＃フェイルオーバーの制御（自動または手動）。
（7）masterha_conf_host＃構成済みサーバー情報を追加または削除します。
Nodeツールキット（これらのツールは通常、人間の操作なしでMHA Managerスクリプトによってトリガーされます）には、主に次のツールが含まれます。
（1）save_binary_logs＃マスターのバイナリログを保存してコピーします。
（2）apply_diff_relay_logs＃差分リレーログイベントを特定し、それらの差分イベントを他のスレーブに適用します。
（3）purge_relay_logs＃リレーログをクリアします（SQLスレッドをブロックしません）。
注：メインライブラリのハードウェアの損傷とダウンタイムによって引き起こされるデータの損失を最小限に抑えるために、MHAの構成中にMySQL準同期レプリケーションを構成することをお勧めします。準同期レプリケーションの原則については、ご自身でご確認ください（不要）。