第21章高可用性
この章のほとんどの主流は、障害の治療戦略の一つのポイントだけでなく、故障ソリューションのシングルポイントを読者に紹介します：MySQLデータベーススイッチ。
21.1概要
可用性を稼働率を維持するために、システムのパーセンテージとして定義され、高可用性が高いサービスを利用可能な時間は、データが失われないことを意味し、システムの稼働時間の高い割合、および無その他の異常として理解することができます。
例えば、データベースは高流量の突然の衝撃に耐えるために予熱されていない、ステージの始まりは、応答時間が非常に長く、困難なサービスが提供されています。この時点で言うとすることができます。
次のように我々は一般的に、たとえば、パーセントの可用性と表現しました。
99.999％の可用性は、年間5分のダウンタイムを表します。
毎年恒例の可用性99.99％は、1時間のダウンタイムを表します。
99.9％は年間8時間のダウンタイムを表します。
彼らの戦略は非常に複雑になることがあり、コストの可用性が高いかもしれない増加、
我々は可能な限りバランスに必要なので、「ダウンタイム」（ダウンタイム）のコストと時間のコスト、「停止」、システム故障の確率と結果の損失の測定を減らします、入力のコストを比較し、過剰設計しないでください。
システムが容易になりますので、あなたがより良いユーザビリティデザイン戦略、小さな増加の可用性を作ることができるように、我々は、システムと非クリティカルセクションの重要な部分を分解することができます。
時々 、私たちは、単純な構造にし、我々はリスクを最小限に抑えるために、より信頼性の高いハードウェアとホストを使用することができ、「単一点」を予約していたしました。
このようなソフトウェアのバグとしてデータベース・サーバ・ハードウェア、ネットワークの障害やパフォーマンスの問題の一般的な可用性に影響を与える主な要因。
あなたが別の読み取りと書き込みのアーキテクチャを使用する場合も、コピーしたり、また、可用性に影響を与えることができるデータベース、一貫性のないデータから、遅延履歴データにつながる複製エラーに起因する可能性があります。
以下のような誤用の生産担当者は、誤ってデータベースサービスの可用性を減少につながる可能性があり、データベース・ファイルとデータベース・テーブルを削除しました。
上記の要因のために、我々は、可用性を高めるために、次の措置の一部を開発することができます。
1）またはテストと検証を行うために、新しいハードウェアとソフトウェアをライン上をアップグレードする前に。
2）合理的なバックアップ戦略、および定期的に回復検証を開発。
3）標準的な操作手順に厳密に従って、データベースは、本番環境とテスト開発環境を分離します。
4）ため、政策の複雑さを簡単に、信頼性の高い、となるようにアーキテクチャが困難とメンテナンスの問題との契約につながる可能性が、高可用性戦略を達成することは困難であり、複雑な問題を解決する最良の方法は、複雑な問題が発生しなくなっ作らないためにであることに留意してください。
5）優れたジョブの監視、可能な限り発生する前に警告を発することができるようになりますを実行します。
6）見直し、障害イベントの分析、再び起きてから失敗を避けるために試してみてください。
高可用性の問題は、十分な訓練を受けた保守要員が、それが失敗した後、失敗の確率、および缶を減らすことができます右のプロセス、規範や手順は、そこによく文書化されている技術だけでなく、管理の問題、ではありません高速回復。
障害の21.2シングルポイント
障害（SPOF）の一点は、システムの部分を指すことが動作停止した場合、それは停止作業にシステム全体を引き起こすであろう。
私たちのアーキテクチャでは、単一障害点を回避しようとしてください。
単一障害点を回避するために、我々は最初の包括的な評価の故障につながる可能性のあるシステムの主要なコンポーネントを見つける必要があり、我々は、単一障害点を回避し、または障害発生のシングルポイントの可能性を低減する方法を、下の可用性の要件を満たしています。
一般的に、我々は、冗長性と方法のさまざまなレベルの単一障害点を解決するために増加した冗長化の方法に依存しています。
装置の観点から、我々は、そのような複数のカードのような個々のコンポーネントの冗長ホストに行うことができる、我々はまた、全体冗長にすべての主要なコンポーネントホストすることができ
、より高いレベルでは、我々は全体のホストに対して冗長であり得ますI、冗長性や全体IDCの部屋。
組織運営の観点から、我々はまた、冗長な人事データ=ライブラリを維持することができます。
MySQLのマスタ-スレーブ・アーキテクチャは、増加は、可用性を高めるために冗長ノードからのものである、本質的です。
次の意志の詳細は、いくつかの一般的に単一障害点を解決するための技術を使用していました。
このようなライブラリーを読み込むグループのためとして1）ロード・バランシング・ソフトウェアおよびハードウェア機器、我々は異常図書館のに対処するための障害から、フロントエンドでバックエンドを負荷分散装置を置くことができ、あなたはまた、デバイス自体の高可用性、負荷分散を検討する必要があります。
2）共有ストレージの使用、ネットワークファイルシステム、分散ファイルシステムまたはディスク・コピー（DRBD）。
共有ストレージへのアクセスデータへの共有ストレージSANベースのデータストレージを使用してOracle RACなどの伝統的なデータベース製品、複数のデータベース・インスタンスの同時アクセス、
データベース・ホスト上のデータベースへの仮想IPアクセスを設定することにより、アプリケーションのデータベースホストの場合ダウンタイム、仮想IPを引き継ぐために、追加のデータベース・インスタンスは、アプリケーションがデータベースにまだアクセスすることができます。
MySQLは公式プログラムのDRBDは、RAIDのネットワークを実現導入しました。一部の人々は、共有データベース・ファイルを保存するために、ネットワーク・ファイル・システム、またはNFS分散ファイルシステムを使用します。
共有ストレージの使用は、比較的高いコストのために、より伝統的なアプローチであり、そしてインターネットアーキテクチャはほとんどそのようなプログラム、使用されていないので、共有メモリ自体はまた、単一のポイントになるかもしれ
ために、メインライブラリーデータのセキュリティを確保するために、何人かの人々を、バイナリログ許容される慣行である共有ストレージへの格納。
使用したネットワークRAID、それはDRBDではあるが実現可能であるが、現実にはあまり使用されなかった、現在のSSDは十分な速さである主な理由は、
DRBD自体がシステム全体のボトルネックとなり、ホストの浪費につながることができ、半分だけ理由ホストが利用可能です。だから、妥協案として、あなただけのDRBDとのバイナリログをコピーすることができます。
私はNFSは、データベースファイルの共有ストレージを使用していなかった、ネットワーク・ファイル・システムは、高スループットを達成することは困難であり、NFSは、シーンがいくつかのバックアップファイル共有に格納されている方が適しています。
一部の人々は、分散ファイルシステム自体の複雑さのために、データベース・ファイルを格納するために、分散ファイルシステムを使用することを選択し、あなたが、そのメンテナンススタッフとチームのスキルやその他の要因のコストを考慮する必要があり
、伝統的な方法は、データファイルを保存することができれば、それが推奨されていませんそのようなA「重い」プログラムの使用。
3）マスタに基づいは複製データベースから切り替えられます。
MySQLはMySQLデータベースを使用して、最も高い利用可能なソリューションは、マスタから切り替えられる現在
、障害が発生した場合に、一次ライブラリーの1つまたは複数のコピー（ライブラリによる）を加えることにより、冗長系のマスターコピーであります生産トラフィックは、サービスの正常な動作を保証するためのコピーに切り替えています。
ホストのパフォーマンスの発展に伴い、ホストとの間で高い可用性が主流の傾向に基づいています。マスターに基づいて詳細にセクション21.3は、複製データベースから切り替えられます。
切り替える21.3 MySQLデータベース
メインデータベース複製溶液ベースのスイッチングアーキテクチャは、高可用性のMySQLです。
プライマリ・データベースがダウンしている場合、我々はあなたがして、我々はトラフィックを適用することができ、ライブラリからベンチを使用し、一定の条件を満たすことができ、メインライブラリーからのアプリケーションの通常のみアクセスでき、マスター・アーキテクチャに設定ペアでデータベースを置くがからに切り替えライブラリは、サービスがまだ利用可能です。
データベースはMySQLのマスタースレーブのレプリケーション・アーキテクチャの依存切り替えているので、あなたは、MySQLの同期を確保するためのMySQLのレプリケーションの原則とメカニズムを理解する必要があるので、利用されています。
あなたはデータを可能な限りデータの損失を避けるために、ライブラリから同期されたことを確認する必要があります。
データベーススキーマは、マスターから構成されていてもよい、マスタは、メインフレームに構成されてもよいです。私たちは最も堅牢な、最も信頼性の高いソリューションである、マスター・スレーブ・アーキテクチャを使用することをお勧めします。
何人かの人々のデータベースをメインメインアーキテクチャに構成された理由は、彼らはそれが簡単にバックカットを切り替えることが可能と考えていることです。
主はアーキテクチャを構成し、プライマリキーの競合の問題をコピーするように注意する必要が間違った操作がメインのライブラリに同期されるため、ライブラリーから操作するときに非常に注意する必要があります。
主は唯一の便宜のためのフレームワークを切り替えるように構成され、実際には、まだ一つだけのマスターライブラリは、スペアとして使用することができ、他のノードにサービスを提供していることを確認する必要があります。
単一障害点、時には私たちは、このようなビジネスへの影響を回避するために、大きなテーブルにテーブル構造を変更するような他の目的のために切り替えることができることに加えて、すべてのトラフィックは、ライブラリから一時的に切り替えています。この場合、一次メインフレームは、より便利になるように構成されています。
トラフィックデータベースは、データベースのホストは、通常のサービスを提供できることを保証するために、ハンドオーバ後、容量管理を簡素化するために、マシンはできるだけ一貫としてスタンバイのハードウェアやソフトウェアの構成を確認する必要があります。
一般からのデータベースデータベースがなかったので、「暖かい」ホットデータは非常に最初の時間中にトラフィックを切り替え、メモリにロードされていない、あなたが事前にいくつかの暖かい-SQLのデータを実行することができ、彼らのパフォーマンスを受け入れることは難しいかもしれません。
より書き込みトランザクション動作のため、データの損失と矛盾するマスタおよびスレーブにつながる可能性があり、スイッチの故障のメインイベントで行われます
通常の状況下では、インターネットサービスの可用性は、データの整合性よりも高くなり、事業の損失はほとんど許容されます。
一部のデータはまた、コメントの一部の損失として、損失を許可されては絶対にデータの損失を必要としない場合、あなたは、プログラムのコストが高くなります実現し、許容可能である
ように、メインライブラリログの損失は、あなたが共有ストレージに必要ないかもしれないことを確実にするようログを格納するための主なライブラリーは、データがライブラリからに転送されたことを確認するために、完全同期または準同期技術の使用を変更する必要があります。
データベースを切り替えるために、我々は以下の方法をいくつか持っています。
1）プログラムに設定ファイルによって達成。
データベース内のルーティング情報を設定ファイルには、我々は、コンフィギュレーション・ファイルデータベースプログラムの実装は、トラフィックを切り替え変更することができ、ほとんどの場合、私たちは、アプリケーションを再起動する必要があります。
JAVAサービスは、デフォルトの設定として、我々は、アプリケーションサービスを再起動する必要があります。あまりにも多くの場合、サービスだけでなく、データベースの構成情報がデータベースに保存されています。
2）ネットワークのDNSを変更します。
我々は、このアプローチの障害が発生した場合の主なライブラリを切り替える実現するためのポイントにDNSを変更するために、ネットワーク内のIPによって、データベースサーバ、ネットワークDNS内本番環境で設定することができ、多くの場合、アプリケーションサービスを再起動する必要があります。
内部ネットワークのDNSのためには、コントロールのDBAチームに属し、メンテナンスおよび高可用性DNSサーバもコストですが、また、DNSのネットワークはまた、より少ないとので、この方法では、時間を要する変更することはできません。
3）ホストは修正ホストファイル。
データベース・サーバーのIPに対応するドメイン名を設定しますが、理想的なことができないの/ etc / hosts。サーバが保持したときに、多くのアプリケーションで統一されたhostsファイルのコストが高くなります。
4）そのようなMHA、MMMなどの高可用性を実現するためのツールのいくつかのセットを、それらがデータベース・ノードを監視条件生存、高可用性データベースプロファイルを達成するために、または一次ライブラリIPドリフト方法を変更することによって。
自動切り替え方式では、非常に信頼性がないとしてMMMは、単一障害点を処理する仮想IPが、多くの証明された生産を通じてドリフトし、必要であれば、唯一の手動切り替え機能を使用することをお勧めします。
MHAはPerlでMySQLのフェイルオーバー・ツールを書いて、仮想IPを変更することで、単一障害点に対処するための2つの方法がグローバル・コンフィギュレーション・ドリフトをしているサポートされ、多くの本番環境で実証された、プログラムは考慮に値するです。
また、IPの実装を切り替える仮想マシンをドリフト、データベース・ノードの可用性を監視するために、独自のスクリプトを書くことができ
、ハードウェアの信頼性に大きく依存している方法でIPドリフト、の欠陥、ホストを使用する必要がある、ネットワーク機器があることに注意することが重要。
本番環境では、仮想IPドリフトにつながっ動作しないため、ネットワークハードウェアであってもよいです。
5）大規模なデータベースクラスタの場合、シングル・ポイント・スイッチのより高度な処理の必要性、可能な限りのように自分のコントロールを超えた要因に依存するべきではありません、我々は、単一のスイッチを達成するために、別のプロキシプロキシの方法を使用することができます。
すべてのトラフィックダウンマスターデータベースノードの障害プロキシを介して、プロキシはインテリジェントバックエンドを扱う、あなたはそれに注意を払う必要がありますが正しくプロキシ自身の高可用性を処理する必要があるということです。
いくつかのインターネット企業を達成するためのプロキシの高コストはすでに、独自の洗練されたデータベースのプロキシを持っています。
プロキシがローカルIDC上のトラフィックのプロキシです理論的には、それはまた、IDCに他のデータベース・トラフィックを処理することができますが、ネットワーク遅延やセキュリティ上の懸念のために、一般的にIDCでのみローカルトラフィックエージェントをお勧めします。
あなたはIDCに渡ってスイッチにデータベースを設定する必要がある場合は、より信頼性の高いソリューションは、ユーザーが通常のIDCのアプリケーションサーバーへのアクセスを許可されたアプリケーション層、のスイッチトラフィックにあります。
6）クライアントを介して、単一の点で切り替えフレームは、プロキシモードに対して、このアプローチは、より軽量です。
21.4 IDC同期を越え
、時には我々は不安定なネットワーク層のために別のIDCでライブラリデータベースから展開冗長性のIDCレベルを、展開する必要があるあなたが遅延しない限り、高可用性を実現することは困難であり、データのデータ一貫性が少なく厳しいです。
より多くの中間リンク、ネットワークの信頼性が低いので、データセンター間でリアルタイムに動作しないようにしよう。あなたは長い距離、より信頼性の低いネットワークがあることを認識する必要があります。
このようなプロセスのリードとインフラ展開の書き込み分離、IDCなどIDCデータベースへのアクセス、中央ですべての書き込み要求、各IDC共有への読み取り要求全体に展開した場合、
あなたは、アプリケーション層でやさしいネットワークの異常に対処する必要がありますまたは遅延の問題によって引き起こされるコピーのレプリケーションの問題は、複数のリモート書き込みがある場合は、あなたも失敗した書き込みに起因するネットワークの問題に対処する必要があります。
だけでなく、マスター・スレーブ同期、ちょうど十分離れて、それはネットワークの品質を保証することは困難である、あなたは同期アプリケーションへの影響に注意を払うする必要があり、
あなたは可能な限り、ノード間のデータ交換を削減する必要があるかもしれません、タイムリーに派遣、ユーザーが他のノードにアクセスし、さらに専用の高品質なネットワークを使用。
要約：
この章では、プログラムのMySQLの保証、高可用性を紹介し、MySQLのマスタースレーブのレプリケーションは、ほぼすべての高可用性ソリューションの基盤です。
読者は、MySQLのレプリケーションの原理に精通している必要があります。
クロスIDCのデータ同期のために、多くの人々がその限界を認識しないかもしれない、DBAは本番環境でこのアーキテクチャを回避しようとしてください。