私の最初の記事25と27では、スタンバイスイッチングプロセスを紹介します。内容を説明することで、あなたは非常に明確にする必要があります。メインの2倍-Mアーキテクチャでは、スタンバイスイッチだけで、バックアップクライアントライブラリへのトラフィックを削減する必要があります。主に、建築からスタンバイスイッチを、よりクライアントトラフィックを提示するだけでなく、スタンバイデータベース、ライブラリから新しいプライマリライブラリを取る必要性に切り替えています。
2つのシナリオを切り替えるスタンバイは、一方が自動的に受動スイッチを切り替えています。主なライブラリは、HAシステムが主催するためのパッシブ切り替えがしばしば問題となっています。
これはまた、我々は今日議論している問題を提起：メインライブラリに問題をどのように決定しますか？
あなただけの罰金選択1を実行して、でもMySQLの上で、これは非常にシンプルなああです、と言うだろう。しかし、正常に返さ1を選択し、それがメインのライブラリは何の問題は権利ではないことを意味しますか？
1分析を選択
実際には、プロセスがまだライブラリであることだけを、1つの成功したリターンを選択して、メインのライブラリは問題ありません説明することはできません。さて、このシナリオを見てみましょう。
set global innodb_thread_concurrency=3;
CREATE TABLE `t` (
`id` int(11) NOT NULL,
`c` int(11) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB;
insert into t values(1,1)
复制代码 ブロックされた図1のクエリ
私たちは、innodb_thread_concurrencyの目的はInnoDB内の並列スレッドの上限を制御することにあるパラメータを設定します。新しい要求を受信したときに、他の言葉では、同時実行スレッド数がこの値を達成するために一度、InnoDBは、それは、スレッドが終了するまで待機している状態になります。
ここで、私はそれはInnoDBが唯一の3つのスレッドを並列に実行することができ表し、3に設定innodb_thread_concurrency。この例では、最初の3つのセッションでスリープ（100）ので、これらの3つのステートメントは、大規模なクエリをシミュレートするために、「実行」状態になっています。
あなたは内部のセッションD、参照、1が正常に実行することが可能であるが、文トンルックアップテーブルがブロックされます選択します。我々はインスタンスを検出するために、1を選択し、この時間は、問題が検出されていない、正常であれば、です。
InnoDBのでは、このパラメータのinnodb_thread_concurrencyのデフォルト値は、同時スレッドの数に制限を意味し、0です。しかし、それは同時スレッドの数は間違いなく不可能で制限するものではありません。マシンのCPUコアの数が限られ、全体バーストのスレッドなので、コンテキストスイッチングコストが高すぎることになります。
したがって、通常の状況下で、我々は、128から64までの間の値にinnodb_thread_concurrencyセットを提案します。この時点で、あなたは疑問を持っている必要があり、128に十分なセットをやって同時実行スレッド数の最大値は、すべての同時接続ラインの数は数千人を回します。
この疑問の理由は混同される同時接続および同時クエリを。
同時接続および同時クエリは同じ概念ではありません。結果は、あなたのPROCESSLISTを示して数千の接続を見て、同時接続を指します。「現在実行されている、」ステートメントは、我々は同時クエリを呼んでいます。
同時接続数は、影響力の何千に達し、それはそれのいくつかのメモリを占め以上で、大きさではありません。同時クエリのが高すぎるCPUキラーであるので、私たちは、同時クエリで心配する必要があります。私たちは、パラメータinnodb_thread_concurrencyを設定する必要がある理由はここにもあります。
その後、あなたはまた、innodb_thread_concurrencyは、問題のホットスポットは、同じ行を更新し、128に設定した場合、我々はすぐに置かれていない、ホット・アップデートとデッドロック検出時の最初の7件の記事での話ということを思い出してシステム全体がそれをハングアップされないように128は、排出しますか？
実際には、スレッドが待機した後、ロックに入り、カウントが同時スレッドによって低減される（また、ギャップを含むロック）、すなわち、他の行ロックは、スレッド128の内部ではありません。
MySQLは、このデザインは非常に有意義です。ロックにスレッドがCPUを食べるために待機していたので、もっと重要なことは、システム全体のロックアップを防止するために設計されなければなりません。
なぜ？また、同時スレッドの数を占めたスレッドがロック待ちであることを仮定し、このシナリオを想像することができます。
- スレッド1が実行を開始、トランザクションはTRX1を開始更新T集合C = C + ID = 1、、この状態のままです。このとき、スレッドはアイドルではなく、内部の同時実行スレッドです。
- 等待ち状態に行ロックため、スレッド2から129件のスレッドが更新TセットC = C + 1、ID = 1を実行します。だから、待機状態で128件のスレッドがあります。
- あなたが衰えないスレッドカウントのロック待ち状態にある場合、InnoDBはフルとスレッドの数は、実行するためにエンジンに他の文を防ぐことになると思いますので、スレッド1は、トランザクションをコミットすることはできません。他の128件のスレッド間、ロック待ち状態で、システム全体がブロックされています。
図2は、この条件であることを示しています。
図2のシステムロックアップ状態（同時ステートメント占有数に等しい行ロックを想定）
これは、システム全体がロックされている、すべての要求のInnoDBの時間に応答しません。すべてのスレッドが待機状態にあるので、次に、CPUによって占有明らかに無理であり、0です。だから、我々はそれが合理的かつ必要である、ロックを待っているの過程で遭遇した状況、同時スレッドの数マイナス1つのデザインに、InnoDBのデザインで言います。
ロックとスレッド数の他の並列スレッドがすることではありませんが、それは実際には最初の3総務トン選択眠りから（100）上の例のように、クエリを実行している、または同時スレッドをカウントする場合数えます。
実行ステートメントはinnodb_thread_concurrencyセットの値を超えている間、この場合、この時間は、システムが実際に死ぬが、検出システムを介して1を選択しなければならない、またはシステムが通常考えます。
したがって、我々はそれを変更するには1を選択し、判定ロジックを使用します。
ルックアップテーブルを決定するために
あまりににより使用不能に同時スレッドのInnoDBの数をシステムを検出することができるようにするために、我々は、アクセスのInnoDBのシーンを見つける必要があります。一般的には、そのようなデータの1行のみ置く名前health_check、として、テーブルにその後定期的にシステム・ライブラリ（MySQLデータベース）を作成することです。
mysql> select * from mysql.health_check;
复制代码あまりにも多くの同時実行スレッドが使用できないデータベースにつながるため、この方法を使用して、我々はケースを検出することができます。
しかし、我々はすぐに、すなわち、次の質問に遭遇する：スペースがいっぱいになって、このアプローチは悪くなります。
私たちは、更新トランザクションは、バイナリログを書き込むようにすることを知っているし、ディスク使用量一度binlogの場所までの100％、その後、コミット時にコミットされたすべてのトランザクションのUPDATE文と文はブロックされます。しかし、この時間は、システムは正常にデータを読み取ることができます。
そこで、我々はモニター文を入れて、それを改善します。次に、我々は、更新ステートメントの後に施行されたクエリを見てみましょう。
更新判定
更新したいので、一般的な方法は、検出の最後の実行時間を示すために使用されるタイムスタンプフィールドを置くことで、意味のあるフィールドを置くことが必要です。に似たこの更新文：
mysql> update mysql.health_check set t_modified=now();
复制代码検出ノードとライブラリの利用可能性は、プライマリスタンバイ・データベースが含まれている必要があります。更新は、メインのライブラリを検出した場合、ライブラリは、検出機器を更新する必要があります。
しかし、ライブラリはバイナリログの検出を書くために準備されます。我々は、マスターとスレーブデータベースA及びBにおいて、一般的に二重構造のMとして設計されるので、検出されたスタンバイ・データベース・コマンドB上で実行されるだけでなく、バックメインギャラリAにされます
メインライブラリA及びBがマスタにつながる可能性がある発生する可能性があり、同じ更新コマンドラインの競合、及びバックアップ同期にライブラリによって調製される場合は、停止します。だから、今ではmysql.health_checkこのテーブルは、データの唯一の1行にすることはできませんようです。
プライマリと矛盾しないこととの間で更新を行うために、我々はmysql.health_checkテーブルに複数の行を堆積させることができる、とAで、SERVER_ID Bは主キーです。
mysql> CREATE TABLE `health_check` (
`id` int(11) NOT NULL,
`t_modified` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (`id`)
) ENGINE=InnoDB;
/* 检测命令 */
insert into mysql.health_check(id, t_modified) values (@@server_id, now()) on duplicate key update t_modified=now();
复制代码MySQLが提供しているため、プライマリおよびバックアップライブラリ各検出コマンドが競合していないことを確認するようにSERVER_IDメインライブラリとライブラリ装置は、異なる（またはそれがエラーになり、マスタとスレーブの関係の作成）でなければなりません。
更新判定は、比較的一般的なシナリオですが、まだいくつかの問題があります。このうち、「遅い判断は、」DBA頭痛せてきました。
あなたは不思議に思われる必要があり、それが失敗するかタイムアウト、あなたは判断が遅い問題があるだろう、なぜスタンバイスイッチングを開始することができる場合、更新ステートメントを？
実際には、サーバーIOリソースの割り当てに関連する問題があります。
まず、検出ロジックのすべてがタイムアウトN.が必要です 以上のN秒が返されていない後、更新文を実行し、彼らはシステムが利用できないと思います。
あなたはログディスクIOの使用量は、シーンの100％を持って想像することができます。このとき、システムの応答が非常に遅い、ショットがスタンバイスイッチを持っている必要があります。
しかし、あなたが知っている、100％のIO IO利用率は、システムが動作していることを示し、リソースへのアクセスを持っているために、各IO要求は、そのタスクを実行します。そして、我々はupdateコマンドのテストを使用して、いくつかのリソースを必要とし、資源に成功提出するIOを取得する時間であるかもしれない、とタイムアウトがN秒に達しない前に、テストシステムに戻りました。
表情検出システム、更新コマンドがタイムアウトしていないので、彼は、「通常のシステム」という結論を得ました。
言い換えれば、通常の業務システムのSQLクエリのこの時間は非常にゆっくりと実行されていますが、見てまでのDBA、HAシステムがまだ正常に動作し、かつメインライブラリが使用可能な状態にあるということです。
我々は上記の方法のすべてを言うという理由だけで、この現象の理由は、外部の検出に基づいています。自然な疑問がある外部感がランダムです。
外部検出が定期的にポーリングを必要とするため、システムが問題となっているかもしれないが、それは次の検出は、文の実行を開始するまで、我々は問題を見つけるかもしれない待つ必要があります。そして、あなたの運が十分でない場合、それは最初のポーリングではないかもしれないまた、これは遅いスイッチングの問題につながることがわかりました。
だから、次は私は、MySQL内で見つかった方法とデータベースの問題を紹介したいと思います。
内部統計
MySQLは、私たちに伝えることができれば、この問題のためのディスク使用率は、毎回内部IO要求は、その後、我々は方法データベースの問題ははるかに信頼性があるかどうかを判断します。
実際には、performance_schemaライブラリのMySQL 5.6バージョンはfile_summary_by_event_name統計テーブル内の各時間IO要求を提供します。
file_summary_by_event_nameテーブルには、我々はEVENT_NAME =「待つ/ IO /ファイル/ InnoDBの/ innodb_log_file」この行を見て、データの多くの行を持っています。
図行3 performance_schema.file_summary_by_event_name
この線画は、統計REDOログ書き込み時間が表現され、最初の列はタイプEVENT_NAME統計を示しています。
データの次の3つのセットが、統計は、時間がログ操作をやり直すことを示しています。
5の最初のグループ、IO統計のすべてのタイプ。前記、COUNT_STAR IOユニットがピコ秒であり、4つの特定の統計的用語に続くすべての総数である。プレフィックスSUM、MIN、AVG、MAX、名前の合計を指す、最小値、平均値と最大値を示唆しています。
6の第2のグループは、統計情報を読み込まれます。最後の1つのSUM_NUMBER_OF_BYTES_READ統計では、REDOログから読み込まれたバイト数の合計です。
6の第3のグループは、統計は、書き込み動作です。
最後に、データの第4セット、他のタイプのデータの統計。REDOログには、あなたは彼らがにfsyncの統計だと思うことがあります。
file_summary_by_event_nameテーブルperformance_schemaライブラリで、binlogの対応EVENT_NAME =この行 "/ IO /ファイル/ SQL /ビンログを待ちます"。統計各フィールドのロジック、および各フィールドには、REDOログと同じです。ここでは、私は詳細には触れません。
我々は、データベースを操作するたびに、performance_schemaは、これらの統計情報に追加情報を必要とするため、私たちは、この統計を開くと、パフォーマンスの損失です。
あなたはすべてのperformance_schema用語を開くと私のテスト結果は、パフォーマンスはおそらく10％程度低下します。だから、私はあなたがちょうど彼らが統計を必要とするアイテムを開き示唆しています。あなたは、以下の方法により、特定のアイテムの統計を開閉することができます。
あなたは、時間のREDOログ監視を開きたい場合は、この文を実行することができます：
mysql> update setup_instruments set ENABLED='YES', Timed='YES' where name like '%wait/io/file/innodb/innodb_log_file%';
复制代码あなたは今、REDOログを開いて、これら二つの統計をBINLOGている、それはこの情報は、そのインスタンスの状態の診断に使用される方法次第であると仮定？
非常に単純な、あなたは値MAX_TIMERのデータベースを介してかどうかの問題を決定することができます。たとえば、しきい値を設定することができ、単一のIO要求時間が異常に属する200ミリ秒を超え、その後、同様の検出ロジックとして次の文を使用します。
mysql> select event_name,MAX_TIMER_WAIT FROM performance_schema.file_summary_by_event_name where event_name in ('wait/io/file/innodb/innodb_log_file','wait/io/file/sql/binlog') and MAX_TIMER_WAIT>200*1000000000;
复制代码珍しいた後、あなたが必要な情報を取得し、次の文を通じてします：
mysql> truncate table performance_schema.file_summary_by_event_name;
复制代码空の統計を前に。だから、モニタの背面には、この異常が再び表示された場合は、累積値の監視を追加することができます。
概要
今日、私はいくつかの方法のMySQLインスタンスの健康状態だけでなく、問題の論理的な進化と多様な方法の存在の検出を紹介します。
あなたが感じるかもしれ読んだ後、この方法は、それがまだ解消されていない1を選択し、実際MHA（マスターハイアベイラビリティ）の非常に広い範囲を使用して、デフォルトの方法が使用されています。
MHAは唯一の接続であるもう一つの別の方法は、「接続が成功した場合は、メインのライブラリは問題ありませんだと思う。」ということです しかし、私の知る限りでは、非常に少ないが、この方法を選択してください。
実際には、すべての改善プログラムは、追加の損失が直接判断を下すために「正しいか間違って」を使用しません、あなたは実際の状況に応じてビジネスを比較検討する必要があります。
私は個人的には、システム・テーブルを更新するための優先順位で、その後、情報検出performance_schemaの増加とともに、プログラムする傾向があります。
最後に、我々は時間の質問に行ってきました。
今日、私はお聞きしたいです：ビジネスシステムは、一般的に、高可用性の要件を持っている、あなたは、サービスを開発し、維持しなければならなかった、どのようにサービスを判断しない問題はそれではありませんか？
あなたはコメント欄に書き込むために使用されるあなたの方法論や分析を置くことができ、私は次の記事で共有し、分析するために一緒に興味深いプログラムを選択します。聴いてくれてありがとう、あなたは一緒に読むためにもっとたくさんの友達にこの共有を送るために歓迎されています。
時間の問題について
問題は、このような読み取りと書き込みの別々のプログラムとしてGTIDサイトが何をした場合、以前の期間は、DDLの時間を行うには大きなテーブルで何が起こるのだろうということです。
メインライブラリでこの文は、ライブラリで10分、提出後に実行することを想定すると、10分（大口取引の典型的な）に広がっていきます。だから、GTID情勢メインライブラリDDL再提出し、Kucharを準備する時間後に、それが表示されるように10分を待ちます。
このように、読者は、メインのライブラリを取る、これらの10分に分離機構をタイムアウトします。
そのような期待の中に操作すると、メインのライブラリにDDLを行い、その後、次に要求がメインライブラリにカットされている読んで、主なライブラリがすべてのビジネスのお問い合わせをサポートしていることを確認、および、時間の低いピーク営業期間でなければなりません。ライブラリによって他の遅延キャッチした後、その後、ライブラリによってバック読み出し要求にカット。
この思考の質問では、私は主に大規模なトランザクションのピア・プログラムの影響サイトですに集中したいです。
もちろん、この問題を解決するために、GH-OSTのソリューションを使用することは良い選択です。
ます。https：//juejin.im/post/5d05bdb7f265da1b7004a785で再現