SiteOps
トップメディアダッシュボード更新履歴
記事一覧

libSQL/Tursoで `database is locked` が出たとき、最初の30分でやること

libSQL/Turso（SQLite互換）の `database is locked` を、止血→分類→証拠集めで最短復旧に寄せる30分チェックリスト。

著者: 川原更新: 2026-05-16障害対応RSS
Xで共有FacebookLinkedIn
料金相談

libSQL/Turso（SQLite互換）で database is locked が出たとき、最初の30分でやるべきことは「どこがロックしているか」を当てにいく前に、影響を止血して、再現性のある切り分けに移ることです。

特に「突然エラーが増えた」「一部のユーザーだけ失敗する」系は、原因が1つに見えても、実際は次のどれかで対処が変わります。

  • ロックが長すぎる（重い処理/長いトランザクション/遅いI/O）
  • 同時書き込みが多すぎる（キュー無しで並列に書いている）
  • リトライ戦略が雑（即時リトライで雪だるま）
  • どこでロックしてるか分からない（ログ/計測が足りない）

この記事は、まず売上やUXの劣化を止めて、次の1時間で“直す場所”を外さないためのチェックリストです。

0. まずやらないこと（3分）

  • いきなりDB設定を大きく変える（WAL/PRAGMAなど）
  • いきなり「再試行回数」を増やす（余計に混む）
  • いきなりアプリ全体をロールバックする（切り分けが消える）

最初の30分は「止血 → 分類 → 証拠集め」だけやります。

1. 症状を1行で固定（3分）

次のテンプレに埋めて、状況を固定します。

  • いつから: （例）デプロイ後 / 特定バッチ開始後 / 何もしてないのに
  • どこで: （例）特定API / 特定ジョブ / 管理画面
  • 何が: database is locked（または書き込み系のタイムアウト）
  • 影響: 失敗率 / 影響ユーザー / 収益に関わる導線か

2. 30分で確定する「分類」（10分）

同じエラーでも、直す場所は3つに分かれます。

  1. 長いトランザクション/重い処理がいる（ロックが“長い”）
  2. 書き込みが集中してる（ロックが“多い”）
  3. 失敗の扱いが悪い（リトライ/タイムアウトが“悪手”）

この分類さえできると、次の1時間で外しません。

3. まず止血（10分）

できるだけ「機能は残しつつ」失敗を減らします。

3-1. 書き込みを“1箇所に寄せる”

  • 複数の経路（API/ジョブ/バッチ）が同じテーブルに同時に書いているなら、まず書き込み経路を1つに寄せる（一時的に他を止める/キューに逃がす）
  • 重要度の低い更新（ログ/集計/閲覧履歴など）は一時的に書き込みを止める

3-2. リトライを「短時間で増やさない」

即時リトライは混雑を増やします。止血の鉄板は以下です。

  • リトライは指数バックオフ（すぐ再試行しない）
  • 失敗時は同じリクエストを同期で待たせない（キューに入れて後で再処理）
  • ユーザー影響の大きい操作は**“失敗を早く返す”**（タイムアウト長すぎは悪化）

3-3. トランザクションを短くする（まずは疑い）

最初の30分は原因特定より、「長いトランザクションを作りやすい場所」を潰します。

  • DB更新の前後で、外部API呼び出し/ファイルI/O/重い計算をしていないか
  • 1リクエストで複数テーブルを更新しすぎていないか

4. 証拠を集める（7分）

次の1時間で修正するために、最低限の証拠を取ります。

  • どのSQL/どの操作で出たか（エラーに operation名 を付ける）
  • どのユーザー/どのサイトか（tenant/site id）
  • どの経路か（API/cron/queue worker）
  • いつから増えたか（発生時刻の境界）

ログが弱いなら、「今すぐ直す」ではなく “直せる状態にする” のが最短です。

5. 30分で出す結論の型

最初の30分で、次のどれかに落とします。

  1. ロックが長い: 長い処理/長いトランザクションを短縮（I/Oを外に出す）
  2. ロックが多い: 書き込みの集中を緩和（キュー/優先度/経路統合）
  3. 扱いが悪い: リトライ/タイムアウト/非同期化を見直す（雪だるま防止）

SiteOpsで初動を速くする（相談/導入）

  • まずは ダッシュボード で、影響が出ているサイト（どの異常から触るべきか）を先に列挙します
  • 相談したい場合は お問い合わせ から状況を送ってください（止血の順番を一緒に整理できます）
  • 料金と導入の流れは 料金ページ にまとめています

関連

  • /media/first-30-minutes-hub
  • /media/stripe-mrr-drop-first-30-minutes
  • /media/cloudflare-deploy-not-reflected-first-30-minutes

この記事を書いた人

川原

SiteOps編集チームの公開窓口として、検索、アクセス、収益データをもとにした運営判断の知見をまとめています。

著者情報

関連記事

Cloudflare 502 Bad Gatewayが出たとき、最初の30分でやること障害対応更新: 2026-05-18Cloudflare 504 Gateway Timeoutが出たとき、最初の30分でやること障害対応更新: 2026-05-18Cloudflare 520（Web server returned an unknown error）が出たとき、最初の30分でやること障害対応更新: 2026-05-18
前の記事github.com が引けない（Could not resolve host）の最初の30分でやること次の記事GA4のアクセスが突然0になったとき、最初の30分でやること

次にやること

複数サイトの検索、アクセス、収益データをまとめて見直すなら、SiteOpsのダッシュボードでサイト別に確認できます。

料金を見る相談したい / お問い合わせ