MySQL/MariaDB Transactd 超 高可用運用 （THA）
MySQL/MariaDB用 NoSQLプラグイン Transactdでの高可用運用（Transactd High Availability）ツール「THA」と、対応したプラグイン（Version 3.5）の提供を開始しました。
MySQL/MariaDBのHAツールは既にいくつかありますが、THAはTransactdに合わせて最適化されると同時に、他にはない工夫がされています。
元々Transactdは、ミッションクリティカルでレスポンスを追及したエンタープライズアプリケーションのために開発されました。高可用運用はとても大事な課題であり、今回ようやくその課題を達成できました。
データアクセスにTransactd APIは使用しなくても、HAのためだけにTransactdプラグインを使用することも可能です。
THAについては、Transactdドキュメントの高可用運用に詳しく書かれていますので詳細はそちらをご覧ください。
ここでは主な内容を紹介します。
THAの主な機能
- マスター死活監視
- 自動フェイルオーバー（切替時間 数秒以内）
- 仮想ホスト名アクセスと実ホスト名解決
- スイッチオーバー
- THAの状態検査
THAの特徴
THAに必要なもの
- Transactd Plugin（MySQL 5.6以上 MariaDB 10.0.13以上）
- Transactd クライアント（C++/PHP/Ruby/COMのいずれも対応しています）
- THA管理マネージャ（haMgr）（Client utilities に含まれるコマンドラインプログラム）
これだけでTHAを開始できます。
最小限のアプリケーションエラーと持続性
一般的にフェイルオーバーのトリガーは、専用の監視デーモンやheartbeatなどを使用しますが、THAではそのようなものはありません。代わりに、アプリケーション内のTransactd クライアントが、受け取ったエラーの内容からサーバーの問題であるかを判断し、フェイルオーバーを開始します。
また、クライアントには、ネットワークエラーが発生した際にサーバー再接続する機能が組み込まれています。 再接続できた場合、カレントレコードやロック状態などを復元させます。
これによって、アプリケーションにエラーが返る前にマスターが切替えられ、再接続することで何事もなかったように処理を継続できます。（ただし、トランザクション中のエラーはこれらの処理を行いません。トランザクションがアボートされてから行われます。）
専用の監視デーモンなどの場合は監視サイクル（30秒など）があるので、障害発生から検出までの間のアクセスはすべてエラーになります。THAの場合はトランザクション中に限り（クライアントとの接続ごとに）その1つだけがエラーになります。
トランザクション中のアクセスエラーを正しく（アボート）処理すればアプリケーションはそのまま持続して実行を続けることができます。
アプリケーションの持続性で言えば、マスターダウンによるダウンタイムはゼロです。
これが「超高可用」と題した理由です。
ネームリゾルバー（THNR）
クライアントにはHAのためのネームリゾルバー（THNR）が内蔵されました。アプリケーションは接続先のホスト名を、実ホスト名でなく仮想名で指定します。THNRは指定された仮想ホスト名から実ホスト名に名前解決してアクセスを行います。これによって、マスターを切替えに付随したVIPの変更やARPキャッシュのクリアといったOSやネットワーク機器などに対する追加処理は一切不要です。
解決された名前はキャッシュされますので、名前解決のためのオーバーヘッドはほとんどありません。
フェイルオーバー
フェイルオーバーはMySQL/MariaDBのGTIDレプリケーションを使用してスレーブ群の中から1台をマスターに昇格させます。そして残りのスレーブのレプリケーション先を新マスターに切り替えます。
フェイルオーバーはクライアントにインストールされたhaMgrがTHNRから指令を受けて開始します。フェイルオーバーにかかる時間はスレーブの台数にもよりますが概ね1秒以内にすべて完了します。
THAの状態検査
フェイルオーバーは頻繁に起こるものではありません。いざというときに助けになる仕組みです。ところが、いざというときに正しく動作させるのは以外と難しかったりします。
そこで、haMgrにはフェールオーバーが正しくできる状態にあるかどうかをチェックする機能があります。定期的なタスクでチェックを行うことで問題時に確実にフェイルオーバーできるようにます。
