https://hdknr.github.io/blogs/tags/database/Recent content in Database on hdknr blogHugo -- 0.157.0jaMon, 08 Jun 2026 00:00:00 +0000https://hdknr.github.io/blogs/posts/2026/06/sqlite-wal-unable-to-open/Mon, 08 Jun 2026 00:00:00 +0000https://hdknr.github.io/blogs/posts/2026/06/sqlite-wal-unable-to-open/<h1 id="sqlite-のunable-to-open-database-fileが高負荷時刻に散発する問題を-wal-化で根治した話">SQLite の「unable to open database file」が高負荷時刻に散発する問題を WAL 化で根治した話</h1> <p>ある自立型トレーディングシステムの運用中に、SQLite が <code>OperationalError: unable to open database file</code> を散発的に投げる慢性バグを追い詰めて修正した記録です。「ディスクは空いている」「ファイルは存在する」のにエラーが出る、という一見矛盾した現象の正体と、その根治・緩和の二段構えの対策をまとめます。</p> <hr> <h2 id="wal-とは">WAL とは?</h2> <p>本題に入る前に、今回のキーになる <strong>WAL（Write-Ahead Logging）</strong> を簡単に押さえておきます。</p> <p>SQLite には書き込み中のクラッシュからデータを守るための「ジャーナル方式」が複数あり、<code>journal_mode</code> PRAGMA で切り替えます。</p> <ul> <li><strong><code>delete</code>（デフォルト）</strong> — ロールバックジャーナル方式。トランザクションを開始するたびに <code>元DB-journal</code> というファイルを<strong>新規作成</strong>して変更前の内容を退避し、コミット時に削除する。書き込み中は DB 本体を直接書き換えるため、<strong>読み取りと書き込みが互いをブロック</strong>する。</li> <li><strong><code>WAL</code></strong> — 先行書き込みログ方式。変更を DB 本体ではなく追記専用の <code>元DB-wal</code> ファイルに<strong>追記</strong>していき、後で「チェックポイント」で本体に反映する。<code>-wal</code> と <code>-shm</code>（共有メモリインデックス）は一度作られたら使い回されるため、<strong>トランザクション毎のファイル新規作成が発生しない</strong>。</li> </ul> <p>WAL の主な利点:</p> <table> <thead> <tr> <th>特徴</th> <th>効果</th> </tr> </thead> <tbody> <tr> <td>読み書きが互いをブロックしない</td> <td>reader はトランザクション中の writer を待たずに読める（その逆も）</td> </tr> <tr> <td>ジャーナルファイルを毎回作らない</td> <td>ファイル作成のオーバーヘッドと競合がなくなる</td> </tr> <tr> <td>書き込みが概ね高速</td> <td>fsync 回数を減らせる（特に <code>synchronous=NORMAL</code> 併用時）</td> </tr> </tbody> </table> <p><strong>WAL が向いているケース</strong>: 読み取りが多く・書き込みもそれなりにある、同一ホスト上の単一プロセス／複数プロセスからのアクセス。今回のように「書き込みデーモン 1 つ＋複数の reader」という構成は典型的な適用例です。</p> <p><strong>WAL の注意点</strong>: ① ネットワーク越しのファイルシステム（NFS など）では共有メモリが使えず非対応、② in-memory DB では効かない、③ <code>-wal</code> / <code>-shm</code> ファイルが DB 本体と併存するため、バックアップは単純な <code>cp</code> ではなく専用 API（後述）を使う必要がある。</p>