この記事の主な目的は、ビッグ データ プラットフォームにおけるメタデータ データベース MySQL の異常な障害を解決することです。アプリケーションの応答が遅い問題を分析した結果、クラスター コンポーネント HIVE とメタデータ データベース MySQL の原因が判明しました。ログ分析、ツールの検出、専門家の指導などの一連の方法により、問題の根本原因はビッグ データ クラスター内のテナントの不規則な使用であることが最終的に特定され、問題は徐々に解決されました。この記事では、事例分析が同様の問題に遭遇した同僚の参考になることを願って、障害の場所と解決策のアイデアを詳細に説明します。
この記事は、twt コミュニティ専門委員会の調査に基づいています。
1. 障害の背景
マーケティング担当者がアプリケーション側でターゲット顧客グループを構築すると、大幅な遅延が発生することがわかります。フィードバックと予備的な検証と位置付けの後、バックエンドがビッグ データ クラスター サービスを呼び出したときに応答がないことが判明しました。この状況により、その後の世帯の肖像画、グループのアップロード、番号の報告、対象顧客に思い出させる必要がある複数のアプリケーションに遅れが生じました。一部の専門分野からの苦情も引き起こした。
2. トラブルシューティングのアイデア
1. 故障箇所:
HIVE コンポーネントに関する問題は、次の 2 つのカテゴリに分類されます。
1.ハイブメタストア
hivemetastore のクラスター監視ページまたはログ分析を使用して、hivemetastore の同時実行数などのパラメーターの制限を確認します。
2.ハイブサーバー2
1) 最近追加された新しいタスクがあるかどうかを調べ、異常な SQL ステートメントやその他のプログラムがあるかどうかを分析します。
2) クラスターの監視ページまたは hiveserver2 のログ分析を通じて、パラメーターに問題があるかどうかを確認します。
3) ハイブのメタデータ データベース テーブルを監査および分析して、監査テーブルやその他の情報など、注目する必要がある多数のパーティション テーブルまたは大規模なフル テーブル スキャン テーブルがあるかどうかを確認します。
2. トラブルシューティング:
MySQL メタベースの問題の原因がハイブ コンポーネントであることがわかったので、次の点から始めることをお勧めします。
1. ハイブコンポーネントから開始します
a. 最近新しいタスクがあるかどうかを確認します。コードが監査されていないタスクや、SQL が標準化された方法で記述されていないタスクは、多くのリソースを占有し、その結果、クラスターの応答が遅くなります。
b. hiveserver2 と hivemetastore のパラメータを確認し、ログを分析して、パラメータの問題が原因でクラスタ コンポーネントが遅くなっていないかどうかを確認します。
2. MySQL データベースから始めます
a. MySQL サーバーのハードウェア リソースをチェックし、CPU、メモリ、IO、ネットワーク カード、その他の情報をチェックして過剰な使用がないかどうかを確認します。
b. ハイブのメタデータ データベースのインベントリ分析を実行して、データベースの速度低下の原因となる、多くのリソースを消費する長い接続や SQL ステートメントが存在していないかどうかを確認します。
3. YARN コンポーネントから始める
a) テナントキューリソースの割り当てが適切かどうかを確認します。
b) 異常状態のタスクが多数存在していないか確認してください。
3. ケースの説明:
1. MySQLメタデータデータベースの異常障害問題の発見方法
1) 5 月 6 日 18:30 に、運用保守担当者は対象顧客グループの作成作業が遅れていることを発見しました。検証の結果、クラスタの応答効率が遅いことが作業の遅れの原因でした。
2) 5 月 6 日 19:00 から 23:40 まで、spark ログ、hiveserver ログ、NameNode ログ、hivemetastore ログを分析した結果、例外は見つかりませんでした。CM 監視ページでは、クラスター検査指標に異常は見つかりませんでした。
3) 5 月 6 日 23:55、運用保守担当者は、mysql メタデータ データベースに長時間の接続セッションが多数存在し、Innod ロックの数が増加し続け、解放されていないことを発見しました。
4) 5月7日0時30分、運用保守担当者がインフラ部門の同僚に原因究明を依頼したところ、メタデータデータベース（MySQL）内でビッグデータテナントの長時間接続が複数存在し、影響を受けていることが判明した。データベースのパフォーマンスによるクラスタ タスクへの影響 送信応答効率; 検証後、長い接続セッションと解放されていない Innod ロックがテナント user_yddsj (ビッグ データ テナント) のタスクによって開始されました。
5) 5 月 7 日 0:12、運用保守担当者はビッグデータ テナントのメーカーにクリーンアップするよう電話をかけ、ビッグデータ テナントのメーカーに長時間の接続セッションをクリーンアップするよう電子メールで支援を求めました。
6) 5 月 7 日午前 0 時 30 分、H 社のビッグデータ製品ラインの専門家がこのプロセスを支援するために招待され、ビッグデータ製品ラインの専門家によるリモート分析の結果、最初の原因は同時実行性の不足であることが判明しました。メタストアの同時実行性はソースコードレベルで決定され、調整（同時実行数の増加）後、テスト環境のデプロイ、デバッグ、検証が複数回行われ、20:30に正式環境にリリースされました5月7日21時30分にhivemetastoreサービスの再起動が完了しました。再起動後、クラスターの機能は通常の状態に戻ります。ただし、追跡と監視を行った後、クラスター サービスのパフォーマンスは 23:45 頃から低下し続け、同時ハイブメタストア数の影響は排除されました。その夜、専門家が翌日のサポートのためにサイトに招待されました。
7) 5 月 8 日 8:10、H 社の多くの専門家が湖南電信サイトに到着し、障害の原因を特定するために協力しました。統合専門家は、MySQL データベース ホストの IO 使用率が引き続き 99% に達していることを発見しました。 ;
8) 5月8日8時30分、MySQL専門家の測位により、5月7日に発見された長時間接続セッションと未解放のInnodロックがまだ解放されていないことが確認され、これらのセッションが指すターゲットテーブルはuser_yddsj.volte_mwです。メタデータ情報をクエリした後、このテーブルには 20,000 を超えるパーティションがあり、テナントの実行プログラムはテーブル全体をスキャンします。その結果、MySQL データベース ホストの IO 使用率は引き続き高くなっています。
9) 5月8日11時19分、運用保守担当者は局担当者と連携し、テーブルuser_yddsj.volte_mwのパーティションをクリーンアップするようビッグデータテナントに通知しました。事務局担当者およびビッグデータテナントの確認の結果、クラスターの正常なサービスを早急に復旧するため、ビッグデータテナントのクラスターサービスを停止し、アプリケーションを停止することといたしました。
10) 5 月 8 日の 11:40 に、ビッグ データ テナントは user_yddsj.volte_mw テーブル パーティションのクリーンアップを開始しました。12:30 に、ビッグ データ テナント テーブルのパーティションのクリーンアップが完了したという通知を受け取りました。
11) 5 月 8 日 13:30、運用および保守担当者による 1 時間以上の観察の後、クラスターのサービス応答とパフォーマンスは正常に戻りました。メタデータ データベースへのアクセス効率が通常に戻ります。
図 1: 基本サポート部門の同僚が、接続時間が長い問題の特定を支援します
図 2-1: ビッグ データにオープンなテナントであるユーザーに対応する、長時間接続に関連するステートメント
図 2-2: ビッグ データにオープンなテナントであるユーザーに対応する、長時間接続に関連するステートメント
図 2-3: ビッグ データ テナントを受け入れるユーザーに対応する、長時間接続に関連するステートメント
図 3: 5 月 8 日の MySQL データベースのホスト IO 最高水位
図 4-1: 5 月 8 日の MySQL データベースの長い接続ステートメント。20,000 を超えるテーブル パーティションを持つビッグ データ テナント テーブル user_yddsj.volte_mw を見つけます。
図 4-2: 5 月 8 日の MySQL データベースの長い接続ステートメント。20,000 を超えるテーブル パーティションを持つビッグ データ テナント テーブル user_yddsj.volte_mw を見つけます。
図 4-3: 5 月 8 日の MySQL データベースの長い接続ステートメント。20,000 を超えるテーブル パーティションを持つビッグ データ テナント テーブル user_yddsj.volte_mw を見つけます。
図 4-4: 5 月 8 日の MySQL データベースの長い接続ステートメント。20,000 を超えるテーブル パーティションを持つビッグ データ テナント テーブル user_yddsj.volte_mw を見つけます。
図 4-5: 5 月 8 日の MySQL データベースの長い接続ステートメント。20,000 を超えるテーブル パーティションを持つビッグ データ テナント テーブル user_yddsj.volte_mw を見つけます。
図 4-6: 5 月 8 日の MySQL データベースの長い接続ステートメント。20,000 を超えるテーブル パーティションを持つビッグ データ テナント テーブル user_yddsj.volte_mw を見つけます。
図 4-7: 5 月 8 日の MySQL データベースの長い接続ステートメント。20,000 を超えるテーブル パーティションを持つビッグ データ テナント テーブル user_yddsj.volte_mw を見つけます。
図 4-8: 5 月 8 日の MySQL データベースの長い接続ステートメント。20,000 を超えるテーブル パーティションを持つビッグ データ テナント テーブル user_yddsj.volte_mw を見つけます。
図 5: 5 月 8 日のビッグ データ テナント実行プログラムのフル テーブル スキャン問題の特定
図 6: 5 月 8 日 13:30 に 1 時間以上観察した後、クラスター サービスは通常の状態に戻りました。
3. 障害の概要
1. 問題解決
一時的な措置:
1) テーブル パーティションをクリーンアップし、メタデータ データベース MySQL への負荷を解放します。
恒久的な措置:
1) 構築されたテーブルを再評価し、テーブル設計、特にパーティション設定を再構築します。
2) 同様の事態が起こらないよう、テーブルの清掃ルールを設定します。
2. まとめ
1) ビッグ データ テナントは HDFS ファイルのみをクリーンアップしましたが、HIVE テーブル パーティション情報はクリーンアップしませんでした。
2) ビッグ データ テナント実行プログラムには MySQL フル テーブル スキャンがあります。
3) ビッグデータプラットフォームのテナント申請プログラムはテナント管理規定に含まれていない
4) ビッグ データ プラットフォームのクラスター テーブル パーティションのメタデータには監視がありません。
4. 問題を回避するための最適化
MySQLを実行するメタデータデータベースの異常障害に対する復旧計画の立て方（完了時間制限：省略）
1) ビッグ データ テナントは、HIVE テーブル パーティション情報をタイムリーにクリーンアップし、自動クリーンアップ スクリプトを構成します。
2) ビッグ データ テナントは実行プログラムを調整し、volte_mw テーブル パーティションの変換を完了し、大パーティション + 小パーティションに設計し、実行プログラムの変換を完了します。
3) ビッグデータ プラットフォームは、オンラインのテナント アプリケーションをテナント管理仕様に組み込みます。
4) ビッグ データ プラットフォームには、クラスター テーブル パーティションのメタデータ監視が追加されます。