「バグを修正したい場合は、最も正確なテストケースを作成してください」-MySQLバグの発見に関するSveta Smirnova

今日のインタビューの主人公を紹介する必要はほとんどありません。 PerconaテクニカルサポートエンジニアのSveta Smirnovaは、MySQLのパフォーマンスのトラブルシューティングと最適化のエキスパートであり、ロシアおよび国際的なオープンソースコミュニティの積極的なメンバーであり、主要な業界イベントで定期的に講演を行い、最も関連性の高いMySQLブックの1つであるMySQLトラブルシューティングの著者です。 今後の夏のPG Day'17ロシアで、SvetaはMySQLパフォーマンスのデバッグに関する集中トレーニングコースを実施し、 レプリケーションのデバッグに関する講義を行います。



PG Dayの前夜、SvetaとMySQLのバグを報告および修正するプロセスの複雑さ、人気のあるフォークの世界の最新の傾向と傾向、JSONサポート機能の導入の歴史について話し、MySQLを使用するすべての専門家に役立つ資料、ブログ、書籍を選択しました。



PG Day専用に、トレーニングコースの特別なセクションがパフォーマンススキーマ専用になります。 その助けにより、ストアドプロシージャのデバッグ、MySQLサーバーのRAMの使用場所の追跡、接続ごとに現在の変数の表示、クエリのデバッグ、ロックの診断などを行うことができます。 Svetaは、 パフォーマンススキーマを調整 し、タスクに含まれる適切なツールを選択する方法を説明し ます 。







PG Day：あなたについて少し教えてください。 あなたは誰、何をしていますか。 専門職でどのくらい働いていますか、どのような資格がありますか？



Sveta：私は10年以上にわたってMySQL テクニカルサポートエンジニアとして働いています。 彼女は、後にSunが買収したMySQL AB、次にOracleで始めました。 Perconaでも同じことをしています。 MySQLのテクニカルサポートエンジニアになる前は、Web開発者として働いていました。 近年、私はクローズドクライアント向けのCRMシステムの開発に関連するプロジェクトを行ってきました。 これらはプライベートなものであり、PHPとMySQLでは側面からは見えません。 Web開発者として、さまざまなデータベースを使用しました。 可能な限り、MySQLを選択してください。



多くの場合、技術サポートとは、電話に座って愚かな質問に答えることです。 実際、MySQLの場合、 これは少し異なります。 レベルで測定した場合、私たちはL3です（より高いレベルがあるかどうかはわかりません-数値は気にしません）。 私たちは完全に異なることをします： 私たちはしばしばコードを調べ 、時には修正を書きさえします 。 不適切な動作からパフォーマンスの問題やMySQLのクラッシュまで、あらゆる状況を監視します。 より具体的には、 バグの優先順位に取り組んでいます。 Oracleでは、 MySQL Enterprise Backup Teamと緊密に連携しました。 バックアップソリューション（古い習慣ではない）などに引き続き興味があります。



PG Day：バグについて話しているので、挑発的な質問をします。 多くの場合、人々はMySQLのバグが何年もの間修正されていないことを訴えます。 それは本当ですか？ Oracleでバグがより速く修正されるように、バグレポートを正しくコンパイルする方法は？



Sveta：私は今Oracleにはいません。 彼女は、 問題が最終的に修正されるように、 問題を報告する方法 に関する特別な5分間の報告書を作成しました。 MySQLの世界（OracleのPercona）では、サポートグループは最初の段階でバグを処理します。 開発者ではなくサポートする理由 バグを投稿するとき、それが再現可能であること、それが本当に間違いであること 、そして予期された動作ではなく、文書化されていないことを確認する必要があるからです。 このバグは最新バージョンに関連しており、それを再現するのに十分な情報を提供していること。 これには多くの時間がかかります。 最初から再現可能なテストケースを提供できるほど、これらの質問への回答が早くなり、バグがMySQL Bugsデータベースで確認済みステータスになるか、Percona Bugsデータベースで確認済みになり、次の段階に進みます。



次のステップは2つの方法です。 すべてのバグは、いわゆるトリアージプロセスを通過します 。各バグは、開発者の計画に従って優先されます。 重大なエラーはすぐに修正されます。 開発者がエラーが多数のユーザーに問題を引き起こす可能性があることに気付いた場合、短時間で修正されます。 しかし、すべてのバグがそのようなわけではありません。 私の実践では、顧客からの苦情が多数発生しているにもかかわらず、開発者にとってバグがゴミのように見える場合がありました。回避策があると言われています。 クライアントが1000台のサーバーを持っているとは誰も考えていませんでした。各サーバーでこの回避策を使用するには、多くの時間と労力を費やす必要があります。 これは必ずしも明確ではありません。



そのような場合、PerconaとOracleの両方に、サポートのお客様向けにバグをエスカレーションするための委員会があります。 サポート契約を結んでいる場合、「このバグは私に影響を与えます。修正したいです」と書くことができます。 Perconaのバグは少なくなっています。 しかし、開発チームは小規模です。 これは何かの決定的な要因であることが判明する場合がありますが、何かではありません。 たとえば、バグ989があります。 それは10年間修正されました。 それを修正するために、ランタイムエンジンの一部を完全に書き換える 3つの作業ログを実装する必要がありました。 機能要求と呼ぶことはできませんが、新しい機能が作成され、それを修正するためにメタデータロックが実装されました。 それも起こります。



一般的なルール：バグを修正する場合は、できるだけ正確なテストケースを作成してください。 この場合、バグを報告してから、確認/検証されて開発が開始され、優先順位付けプロセスが経過するまで、時間は最小限になります。



PG Day：さまざまなMySQLオプションに関する質問。 現在の開発動向は何ですか、どの方向に向かっていますか？ これについてコメントできますか？



スヴェタ：私は保守的な人です。 MySQLには3つの主なオプションがあります。 1つ目は、Oracleが行うアップストリームであるOracle MySQL Serverです。 2つ目はPercona Serverで 、 以前のサーバーと100％互換性があります。 データディレクトリPercona Serverからデータを取得し、Oracle MySQL Serverで使用できます。逆も同様です。 Oracle MySQL Serverよりも高速な場合、いくつかの追加機能と最適化があります。 冗長スローログや監査ログなどの機能があり、これらはOracle MySQL Serverのエンタープライズバージョンにのみ存在します。 XtraBackupがあります -ところで、Oracle、Percona、MariaDBで動作します。 MariaDBは3番目のオプションです。 彼らは彼ら自身の道を進んだので、私はそれが今フォークと呼ぶことができるかどうかさえ知りません。 たとえば、オプティマイザーを実行する別のチームがあります。 Oracle MySQLと同じクエリを作成できますが、オプティマイザーは計画を異なる方法で作成し、異なる場合があります。



たとえば、 レプリケーション に関しては 、 GTIDは Oracle MySQL Serverとは完全に異なります。 Oracle MySQL ServerまたはPercona ServerからGTIDを読み取ることはできません。 MariaDBのデータディレクトリを取得して、PerconaまたはMySQLサーバーでGTIDを使用することはできません。 厳密に言えば、MariaDBは外部形式のGTIDを検出してもエラーを返しません。単に無視します。 その逆は真実ではありません。 彼らは少し横になりますが、原則として彼らへの移行は簡単です。 ただし、他のサーバーにはない機能があるため、または同じ機能が異なる方法で実装されているため、 元に戻すことはすでに困難です。



Drizzleのようなプロジェクトがありました-そのような最小限のMySQLサーバーで、そこからはカーネルのみが残っていました。 しかし、彼は現在成長していません。 FacebookのフォークやAlibabaの フォークなど、企業のフォークがあります。 これらはこれらの企業で使用されています。 たとえば、Alibabaには物理的な複製があります。 彼らがソースコードを開いたかどうかはまだわかりません、またはまだ約束します。 ただし、他のサーバーにはないものを試すことができます。 ただし、これらの企業により焦点を当てています。



Facebookによって開発されたストレージサブシステムMyRocksがあります。 すでにPercona ServerとMariaDBの両方にあります。 Percona Serverには試用版があり、テストエリアで利用できます。MyRocksの技術サポートはPerconaとMariaDBによって提供されます。 アマゾンのようなフォークもあります -彼らは独自のオーロラを持っています。 しかし、それらのソースは閉じられています。 MySQLソースはGPLの下でライセンスされており、製品を配布したくない場合でも使用できます。 GPLでこの瞬間を利用します。 ただし、Amazon Auroraでソースコードを確認することはできません。外部から何かを見つけることは非常に困難です。



PG Day：専有エンジンはイデオロギー的にInnoDBのような定評のあるエンジンの開発ですか、それとも根本的に新しい開発（例えば、MyRocks）ですか？



Light： MyRocksは独自のエンジンではなく、そのソースコードは公開されており、最近GPLになりました。 どうして始まったの？ InnoDBでは、インデックスはBツリーに保存されます 。 これは読書に最適です。 ただし、毎回「ツリー」を書き換える必要があります。 これを改善するために、RocksDBはLSMツリーを作成しました 。 その中で、データは最初にmemtableに書き込まれ、次に先書きlogに書き込まれます 。 一般に、MongoDB用とMySQL用の2つのRocksDB実装があります。 MyRocksはMySQLのサブシステムであり、FacebookのGitHubで長い間オープンソースで利用できました。 Facebookの「ツリー」で使用できます。 現在、MariaDBのPerconaリポジトリで利用できます。 機能はFacebook側で行われますが、MariaDBまたはPerconaのいずれかでサポートされます。 ところで、私たちも機能を実行します。



PG Day：InnoDBはまだ標準のMySQLサーバーエンジンですか？



スヴェタ ：はい。



PG Day：彼は安定を達成しましたか、それとも改善すべき点はありますか？



Sveta：改善の余地は確かにあります。 しかし、彼はこれらのエンジンの中で最も安定しています。 サポートエンジニアとして、InnoDBを使用するのが最も簡単です。 おそらく、私は彼と最も長く働いたが、新しいエンジンではなかったという事実による。 おそらく、ユーザーベースが大きいためです。 InnoDBの圧縮は、代替エンジンのTokuDBおよびMyRocksよりも悪いとしましょう。 バージョン8.0では、一定の負荷の下で読み取りコミットが開始され 、反復可能な読み取りよりもパフォーマンスが低下し、著しく悪化する状況を修正することを約束しました。 8.0で修正することを約束しましたが、これまでのところ利用できません。 彼らはベンチマークを示しましたが、コードはまだ利用できません。 もちろん、InnoDBで改善できることは他にもいくつかあります。



PG Day：あなたは、サポートエンジニアとして、多くの場合InnoDBで働いていると言いました。 定期的に使用する新しいバージョンの機能はありますか？



Sveta：私がお話ししたい私のお気に入りの機能はPerformance Schemaです。 残念ながら、そのようなことがあります。自分が開発者であるときは、どのバージョンでも入れて「更新する必要があります」と言うことができます。 また、サポートエンジニアの場合、古いバージョンではさまざまな話が起こります。 最近、バージョン5.1のクライアントがありました。これは10年間サポートされておらず、長い間サポートが終了しています。



5.7に新しいパフォーマンススキーマツールキットが登場したため、みんなに5.7にアップグレードしてもらいたいです。 以前のバージョンでは、メモリがどこに費やされていたのか、レプリケーションストレージスレッド、InnoDBまたは他の場所のいずれかで明確ではありませんでした。 この情報は現在入手可能です。 これで、ロックに関する詳細情報を取得できます。 以前は利用できなかった全く新しいメタデータロックです。 セッションでステータス変数を表示するためのツールがあります。 サーバーが何らかの作業を行うと、エンジンが書き込むデータの行数、または作成された一時テーブルの数を確認できます。 しかし、1000の接続がある場合、1000全体がまさにそのような合計であることを知っています。 最も活性の高い化合物の1つを見ることが興味深い場合、5.7以前はこれは不可能でしたが、5.7では可能でした。 5.7には多くのパフォーマンススキーマツールがあります。 今、これは私のお気に入りのツールです。 みんなに新しいバージョンに切り替えてほしい。



PG Day：移行といえば。 古いバージョンを持っている人はまだいます。 それは平凡な怠inessと無責任ですか、または古いバージョンから新しいバージョンへの移行に客観的な困難がありますか？



Sveta：移行の難しさはほとんどそのようなものです。 24時間、週7日働く必要がある企業がある場合、問題が発生します： ダウンタイムを最小限に抑える方法は ？ 第二の瞬間。 メジャーブランチからメジャーブランチにアップグレードする場合、 非互換性があります。 非互換性には、データストレージ形式とオプティマイザーによるクエリプランの構築に関連するものの2種類があります。



最初のタイプの非互換性は、非常に難しいケースには適用されません。 バージョン5.1から新しいものに移行する場合、 dump / reloadを実行する必要があります。 とても遅いです。 ブランチからブランチへの単純なアップグレードは簡単ですが、古いデータディレクトリを取得し、新しいバージョンを起動してmysql_upgradeを実行します。 最近のバージョンでは、Oracleはこのプロセスを最小限の労力で実現しています。 しかし、それでも問題が発生する場合があります。 または、テーブルを再構築する必要があります。ALTER TABLE 、 ENGINE = InnoDBを記述しますが、これも一般に高速ではありません。



別の瞬間。 アプリケーションによって行われた要求は、最初に記述されたバージョンに対して最適化されます。 興味深いことに、バグが修正され、オプティマイザーの動作が改善され、更新後に一部のクエリの動作が遅くなりました。 古典的なケースがありました。 あるクライアントは次のように書いています。「更新が完了し、リクエストの処理が遅くなりました。」 私は言います：「あなたのログを送ってください。」 彼は送信し、すべてのリクエストはF ORCE INDEXを使用して書き込まれます。 「FORCE INDEXを削除してみてください。」 彼は取り除いて言った：「はい、今では古いバージョンよりも速く動作します。」 これはすべて行う必要があります。



PG Day：あなたは、MySQLの問題のデバッグと解決を専門とする本「MySQL Troubleshooting」の著者です。 誰に役立つのでしょうか？



Sveta：私はMySQLサポートで働いており、バグを扱っていました。 人々は同じ質問をしました。 MySQLに問題がある場合の対処方法に関する情報を1か所に収集する必要があると思いました。 同じ質問に答えるのではなく、より複雑な問題を解決したかったのです。 本のアイデアは次のとおりです。 MySQLの使用方法、クエリの作成方法、開始方法を知っています。 しかし、問題があります。間違ったデータが返され、動作が遅くなります。 どうする 私はこの本にこの質問に答えてほしかった。



PG Day：この本は、幅広い人々を対象としています。 MySQLを扱う人は誰でも、愚かな質問をするのをやめるためにそれを読むべきですか？



Sveta：原則として、はい。 必ずしも愚かではありませんが、何をすべきかを把握できるだけです。 残念ながら、この本は2012年にリリースされたため、最新の機能はありません。 しかし、この原則は依然として重要です。MySQLに何らかの問題が発生した場合の対処方法を理解するには、本を開く必要があります。



PG Day：新機能の問題について、第2版の本を再発行する予定はありますか？



Sveta：私は今これをやっていませんが、計画しています。



PG Day：ところで、新機能について。 私の知る限り、あなたはMySQLでJSONサポートを実装する問題に貢献しました。 この経験について教えてください。 今では、データベースの世界では非常に流行の傾向です。



Sveta：実際、これらすべては非常に興味深いものです。 JSONサポートは、私がMySQLテクニカルサポートエンジニアになる前（2006年以前）に表示された作業ログです。 MySQLがサポートする機能について説明しました。 しかし、誰かがそれを動かさなければならず、プロジェクトをサポートするようにしました。 この問題に取り組んでみませんか？ MySQLはXML関数の経験を繰り返したくありませんでした。 機能は実装されましたが、コミュニティが望んでいたとおりに機能しませんでした。 彼らは私がUDF機能として設計プロトタイプを作ると決めました。 この設計プロトタイプは、MySQL Labsプロジェクトとして利用できました。 人々はそれを使用し、バグを送りました。 その後、最適化チームは、 設計プロトタイプに基づいて、サーバーレベルで機能を実装し、最適化されて迅速に機能するようにする必要があります。



2012年に、私は最初のバージョンを作成し、彼女は内部レビューに行きました。 それから彼らは私にすべてがやり直さなければならないと言った。 私はそれをやり直し、2013年にようやく一般に公開しました。 この時点で、新しい機能の要求が来ました。json_depth関数とjson_length関数が（コミュニティの要求で）登場しました。 私の発明や会社の発明ではありませんでした。 私はバグを修正し、新しい機能を追加しました。 デザインは洗練されました。 最後に、JSONのSQL標準の設計プロトタイプが登場しました。 現在承認されているかどうかわかりません。監視を停止しました。 構文が実装されました。



UDF関数には、最初はやや奇妙な構文がありました。 しかし、構文に何も取り組んでいませんでした。標準に何が起こるかが明確ではなかったからです。 MySQLがこれをサーバーコードに埋め込む場合、MySQLにあまり固有ではないことが判明するようにしたかったので、構文は非常に簡単に使用できました。 すべてがテストされると、オプティマイザーのチームがデータ型を作成しました。 プラグイン可能ではありません。 私は彼らの助けなしではこれをすることができませんでした。



PG Day：JSONの開発が継続され、機能が追加されましたか？



スヴェタ：はい。 まだリリースされていないバージョン8.0.2では、 JSON_SETおよびJSON_REPLACE関数のインプレース更新を行いたいと考えています。 JSONで現在何が起こっていますか？ 原則として、JSONは大きくて長いドキュメント（たとえば、1キロバイト）です。 いくつかの要素、たとえば本の名前を変更したいとします。 次に、この1キロバイトを完全に書き換える必要があります。 あまり効果的ではありません。 1キロバイトの書き換えは怖くない。 ただし、このような行を多数書き直す必要がある場合は、効率が悪くなります。 8.0.2の彼らは、インプレース更新を行ったこと、つまりJSONドキュメントのごく一部のみが更新されることを発表しました。 これは、JSONが進化していることを示唆しており、さらに興味深いことがあるでしょう。



PG Day：このような詳細で詳細な話をどうもありがとう。 PG Dayの夏に行うマスタークラスの小さな発表をお願いします。 MySQLのパフォーマンスのデバッグに焦点を当てます。 マスタークラスは、大きくて膨大な8時間もの予定です。 どのプロファイルスペシャリストが彼に役立つでしょうか？



Sveta： MySQLのパフォーマンスに問題があり、 MySQLを高速化するために何かをしたい人に役立ちます。 マスタークラスでは、基本から始めて、デバッグを進める前に知っておくべきこと、動作が遅いものを正確に把握する方法について説明します。 テストサーバーとは何ですか 、それを使用してパフォーマンスの問題をデバッグする方法。 4つの主要な部分があります。 遅いクエリとその最適化です。 . , MySQL.



-, , DBA . - . , , - . – , , . , MySQL Command-Line , Linux. , , .



? - : SQL- , . . .



PG Day: . , , , , . , ?



: , MySQL . — « MySQL », Oracle MySQL. . — Percona Database Performance Blog . Percona. , Percona . Oracle, Percona Blog, .



, “MySQL Troubleshooting” . “High Performance MySQL” , . , — “MySQL High Availabilityˮ . — MySQL replication team：チャールズベル、マッツキンダール、ラースタルマン。MatsはMySQLチームを退職しました。Charlesは、MySQLユーティリティに関与しています。Larsは、レプリケーションチームよりも大きなチームのマネージャーです。それにもかかわらず、彼らはそれについて書いた：どのように異なる複製が行われるか、どのような「レーキ」とは、それらを回避する方法。半分の本がこれに専念しています。ハーフブックは、MySQL Fabricになったソリューション専用です。



また、MySQLを含むすべてのデータベースに適した「SQL Antipatterns」という著者、Bill Karwinという本もあります。まだ本があります。しかし、私はおそらくこれにこだわるでしょう。