小さいクエリは通り、大きいクエリは失敗する：原因はどのパケットサイズか

小さいクエリは返り、大きいクエリはハングするか落ち、最初の直感はパケットサイズのどこかがおかしいというものだ。その直感はたいてい正しく、ほぼ常に間違った層を狙っている。三つの設定がパケットという語を共有し、データベースドライバーのトランスポート包装、データベースサーバーのメッセージ上限、IP 経路の最大転送単位という無関係な三つを測っている。片方を調整して別の原因による症状を直そうとするのが、五分の問題を一週間の調整に変える道だ。以下の順序が、私にとって最も時間を食わなかった順である。

三つの層、ひとつの共有語

以下の各行は所有者の異なる別々の単位であり、どれも他から推論できない。データベースのメッセージは多くの TCP セグメントと多くの IP パケットにまたがりうるので、その許容サイズを増やしても経路は広がらず、ドライバー設定を下げることはインターフェースの MTU を変えるのと同じ操作ではない。この語は三つの異なる設定ファイルに現れるため、検索すると無関係な三つの答えが返る。まずエラーの文面を読み、それからどのファイルを開くかを決めよ。

設定ファイルを開く前に、失敗した操作がどの層に属するかを書き留めよ。エラーの文面はたいていそれを言っており、その文面こそ人が飛ばす部分だ。

設定を変える前にプロバイダーを特定する

SQL Server では、アプリケーション、ドライバーまたはプロバイダー名、バージョン、有効な接続構成を記録する。診断スクリプトとデスクトップアプリは異なるプロバイダーを通じて同じサーバーに到達しうるので、片方に効く設定はもう片方について何も証明しない。プロバイダーの既定値は異なり、似た名前の接続文字列フィールドは、どのプロバイダーも同じように解釈する証拠ではない。

古い回避策がその構文を使っていたというだけで、保守されているドライバーを旧式のものに置き換えてはいけない。現在の文書はそうした古いコンポーネントに対する新規開発を勧めておらず、その制限を受け継ぐことは一つの設定のための悪い取引だ。

メッセージの拒否は経路の停止ではない

MySQL 8.4 では、通信パケットの文書が、適用される上限に対して大きすぎるステートメント、行、バイナリログイベントが拒否されることを説明しており、クライアントとサーバーの両方の上限が関係しうるが、それはデータベース層での拒否であり、ネットワークが巨大な IP パケットを運ばなければならないという主張ではない。実際のエラーと問題のメッセージの形を読め。多数の小さな行からなる大きな結果は、一つの巨大な行とは別のケースであり、失敗の仕方も異なる。

MariaDB の導入には、そのバージョン自身の文書化された上限と診断が必要だ。MySQL の既定値を MariaDB に写すのは、手順を増やした当て推量である。

経路の証拠は実際にどんな形か

経路サイズの問題には独自の指紋がある：特定の経路とアドレスファミリーに沿って再現するサイズ依存の転送失敗であり、トンネルのオーバーヘッドが関与し、発見のフィードバックが経路の許すとおりに振る舞う。タイムアウトだけでは、遅いクエリ、ドライバーの不具合、サーバー側の上限と区別できず、タイムアウトを MTU 問題の証拠とみなすことは、あなたを自信たっぷりに間違った層へ送る。

経路を試すなら、宛先、アカウント、作業負荷を固定し、唯一の変数が探っているサイズになるようにせよ。三つが変わったテストは、どれが重要だったかを何も教えない。

文書化された変数を一つ変え、それから記録する

宛先、アカウント、プロバイダー、作業負荷を一定に保ち、元の値を記録し、支持された変更を一つ適用し、結果を記録する。テストを一つ通す小さめの設定は、その試験したスタックについての有用な証拠であり、万能の最適値ではなく、元の失敗の原因を確定するものでもない。それらは別の主張であり、一つ目の主張だけが単一の実験で支えられる。

特定した上限をその層で解決し、それがどの層だったかを記す。その記録が、経路が問題だったのに次の人がドライバーを調整するのを止める。