TITLE

SQLiteに16年以上潜んでいたデータ競合 ― Tailscaleが見つけた「WAL-Resetバグ」の追跡

投稿日：2026.08.13

6か月で19件 ― シャード単位で止まった新規接続

Tailscaleの制御プレーンは、複数の「シャード」で構成されています。ここで約6か月の間に、個別のデータベース破損インシデントが19件発生しました。影響はシャード単位に限られ、tailnetへの新規デバイス接続やAPI利用が数分から1時間以上停止する形で現れています。一方、既存デバイス間のP2P接続(データプレーン側)は影響を受けず、通信自体は継続していました。

チェックポイントとwriteが交差する一瞬 ― バグの仕組み

原因は、SQLiteのチェックポイント処理とwriteトランザクションの間で起きる稀なデータ競合でした。チェックポイント中に書き込みが発生するタイミングが重なると、実際にはデータベースファイルへ書き込まれていないページを、SQLiteが「コピー済み」と誤認してしまいます。誤認されたページは永久に失われ、データベースが破損します。

チェックポイントとwriteトランザクションが交差し、ページが永久に消失する競合の概念図

この競合はごく限られたタイミングでしか発生しません。だからこそ、SQLiteのソースコードに少なくとも16年間、気づかれずに存在し続けていたのです。

高頻度チェックポイントとベンダー協業が突破口になった

Tailscaleが原因を突き止められた背景には、2つの要因があります。1つは、Tailscaleが制御プレーン側でSQLiteの手動チェックポイント制御を行い、一般的なSQLite利用よりも高頻度にチェックポイントを実行していたことです。頻度が高い分、このバグに遭遇する確率もそれだけ高くなっていました。もう1つは、SQLiteとのプロフェッショナルサポート契約を通じて、SQLiteコア開発チームと詳細な技術協議を重ねられたことです。

自然には再現しないバグを、あえて起こす

SQLite開発チームは、チェックポイント処理中の追加トレース情報を記録できる仮想ファイルシステム層のラッパー「tmstmpvfs」を作成しました。次に破損インシデントが発生した際、このトレースログの解析から原因を特定できています。もっとも、原因が分かった後も一筋縄ではいきませんでした。開発チームはこのバグを自然発生的には再現できず、発生条件を意図的に起こす特別なテストロジックをSQLiteに追加する必要があったのです。この経緯はHacker Newsのフロントページでも大きな関心を集め、2026年8月12日から13日にかけて615ポイントを獲得しています。

私たちが読み取るべき教訓

このエピソードから読み取れるのは、Tailscaleの場合、高頻度チェックポイントという非典型的な運用をしていたからこそ、このバグに遭遇する頻度も上がり、原因の絞り込みにつながったという点です。同じ運用をしていなければ、このバグは今も気づかれないままだったかもしれません。もう一つ効いたのは、原因を追う手段(tmstmpvfsのような追加トレーシング)そのものを、SQLiteとのプロフェッショナルサポート契約という形で事前に築いていた関係の上に、事後すぐ作れたことです。オープンソースの基盤技術を本番で使う企業にとって、この事後構築を可能にしたのは平時のベンダー関係であって、観測性ツール自体を先回りして揃えていたわけではありません。

まとめ

このバグを踏まえて次に確認すべきは、自社が依存するデータベースエンジンのバージョンがSQLite 3.51.3以降かどうかです。チェックポイント頻度を上げるような非典型的な運用を行っている場合は特に、修正版への追随を優先することをお勧めします。加えて、原因不明の障害に遭遇した時にベンダーへ直接技術協議を持ちかけられる関係(サポート契約の有無)を平時に確認しておくことが、今回のようなケースでは決め手になります。トレースの仕組み自体は、その関係があれば必要になった時点から作り始めても間に合います。

出典:

※ この記事は AI を使用しています。Leadeas が自社開発した AI エージェント基盤で下書きを作成し、人間のレビューを経て公開しています。AI ネイティブ開発会社として自社の技術をそのまま実演する目的で、この手法を用いています。(詳しくは AI 利用ポリシー)