dbtrail

$ duckdb -init views.sql
D SELECT c.tier, count(*) AS orders, round(sum(o.total), 2) AS revenue
  FROM demo.orders o
  JOIN demo.customers c ON c.id = o.customer_id
  GROUP BY c.tier ORDER BY revenue DESC;
┌──────────┬────────┬───────────────┐
│   tier   │ orders │    revenue    │
│ varchar  │ int64  │ decimal(38,2) │
├──────────┼────────┼───────────────┤
│ platinum │ 539848 │   59426197.40 │
│ gold     │ 539752 │   59353658.54 │
│ silver   │ 539056 │   59295443.48 │
│ bronze   │ 538385 │   59242795.95 │
└──────────┴────────┴───────────────┘

このクエリは Parquet ファイルを読み取りました。MySQL プライマリには一切アクセスしていません。

ソースから数分遅れます。高可用性ではなく、バックアップでもありません。 制限事項

---

理由

プライマリ上でレポート、ダッシュボード、アドホック分析を実行すると、アプリケーションとリソースを奪い合います。全件スキャンによってワーキングセットがバッファプールから押し出され、長時間の読み取りによって purge が滞り、数百万行に対する GROUP BY では一時テーブルがディスクに書き出されます。レポート用レプリカを導入すれば、別の MySQL の費用とパッチ適用が必要になりますが、それでも行指向ストレージの速度でしか応答できません。

DBTrail は、こうしたクエリのために独自のコピーを mysqld の外部に列指向形式で用意します。

仕組み

1. 最初のコピーではテーブルを一度だけ読み取ります（mydumper を使用します）。
2. その後は binlog のみを使用します。 DBTrail はレプリカと同じ方法で、レプリケーションプロトコル経由で接続します。プラグインも、データベースホスト上のエージェントも、トリガーも必要ありません。そのため、Amazon RDS と Aurora で動作します。
3. スケジュールに従ってコピーを更新します。 DBTrail は記録された変更を新しい Parquet スナップショットに反映します。更新間隔は 5 分ごとから 1 日 1 回まで設定できます。テーブルの構造が変わらない限り、ソースを再読み込みすることはありません（制限事項を参照）。
4. DuckDB でクエリできます。 自動生成される views.sql によって、ソーステーブルと同じ名前（shop.orders）のビューがテーブルごとに作成され、最新のスナップショットを参照します。

Docker Compose のスタック 1 つと、フォルダーまたは S3 バケットがあれば利用できます。構築するパイプラインも、運用するウェアハウスも、Kafka も必要ありません。DuckDB による分析を参照してください。

数値

ソース：RDS MySQL 8.4、TPC-C データセット、7,300 万行、約 10 GB。sysbench-tpcc の負荷は毎秒 180 トランザクションです。DBTrail 0.84 を 5 分ごとに更新して、2026 年 9 月 18 日から 20 日に測定しました。6 つのレポートクエリの合計時間：

クエリの実行場所	合計時間
MySQL	22 分 28 秒
Airbyte CDC でデータを取り込んだ ClickHouse	12.6 秒
DBTrail + DuckDB	4.6 秒
MyDuck Server	2.7 秒

6 つのクエリのうち、地区と月でグループ化する 2 テーブル結合は、MySQL で 3 分 52 秒、コピー上では 0.9 秒でした。このデータセットでは MyDuck のほうが高速でした。データを DuckDB 独自の形式で保持するため、読み取れるのは DuckDB のみです。

フレッシュネスは、毎秒約 340 トランザクションの負荷と 5 分間隔のスケジュールで別途測定しました。コミットから DuckDB で参照可能になるまでの時間は 2.7～13.2 分、中央値は 5.9 分でした。

測定方法、コスト比較、ClickBench の結果： MySQL 分析レプリカの紹介。

得られるもの

分析用コピー

• MySQL にかかる重いクエリをオフロードします。 コピー上で、DuckDB の独立したプロセス内で実行されます。mysqld から外に出るのは binlog のみです。
• すぐに開ける DuckDB。 views.sql は 1 つで、テーブルごとにビューを 1 つ用意します。DuckDB は、ノート PC、ノートブック、BI 用マシンなど、お使いのマシン上でこれを実行します。
• 所有権はそのまま、ファイルを開けます。 ディスクまたは S3 上のプレーンな Parquet と、Hive パーティション分割された変更履歴を利用できます。独自仕様のものはありません。
• ほかのエンジンにも対応。 bintrail export iceberg でスナップショットを Iceberg にエクスポートし、Spark、Trino、Athena で利用できます。Iceberg エクスポートをご覧ください。

views.sql を通じてコピーを開いてください。 Parquet ファイルを直接読み込むエンジンでは、各テーブルは最後に全件書き込みされた時点の状態として表示され、その隣に保存された変更ファイルが反映されないことがあります。ビューを使えば、それらが適用されます。

同じストリームから、タイムトラベルと復旧を実現

DBTrail は、MySQL サーバー上の変更を変更前と変更後の両方で保持し、望まない変更を元に戻す SQL を書き出します。コピーと同じ binlog から読み取るため、インストールした日から利用できます。

• すべての行のすべてのバージョン。 ウェブインターフェースまたは reconstruct CLI から、過去の任意の時点における行やテーブルの状態を確認できます。オプションの MySQL ポート（ベータ版）を使うと、任意の mysql クライアントから AS OF SQL で同じ内容を照会できます。タイムトラベル SQLをご覧ください。
• 正確に元に戻します。 破損した行だけを元に戻す SQL を生成します。recover-cascade は、バイナリログより下位で ON DELETE CASCADE によって削除された子行も再構築します。DBTrail が SQL を書き出し、お客様が内容を確認して実行します。クエリと復旧をご覧ください。
• 復旧結果を検証します。 bintrail verify は、2 つのスナップショットとインデックスを使い、ソースに触れることなく、復旧によって元の状態を再現できるか確認します。bintrail status は、キャプチャで埋められなかったギャップを通知します。検証をご覧ください。
• ウェブインターフェースと MCP。 サーバーを追加し、スナップショットをスケジュールして、ブラウザーで変更を確認できます。Claude Desktop または任意の MCP クライアントを接続し、自然な言葉で質問できます。すべてのツールは読み取り専用です。 5 分間ガイドをご覧ください。

お使いの環境を何も接続せずに、30 秒でタイムトラベルをお試しください。

docker run --rm -p 6033:6033 ghcr.io/dbtrail/bintrail-demo

デモ画像をご覧ください。

制限事項

信頼できるコピーとは、その限界を把握しているコピーです。

• 高可用性ではありません。 アプリケーションがこのコピーを参照することはありません。 このコピーへのフェイルオーバーもありません。
• バックアップではありません。 履歴はインストールした日から始まります。 物理バックアップは引き続き保管してください。
• デフォルトでは秒単位ではなく、数分遅れます。 コピーは設定したスケジュールで 更新され、SQL ポートはコピーに対して応答します。ウェブインターフェースで サーバーごとに選択できるフレッシュモードでは、その後キャプチャによって インデックス化されたデータも読み取ります。通常は数秒遅れで、一部のメモリと速度を 使用します。
• 完全な行イメージを含む ROW バイナリログが必要です。 binlog_format=ROW と binlog_row_image=FULL が必要です。bintrail doctor は両方を確認し、修正方法を 表示します（RDS と Aurora では、パラメーターグループで設定してください）。
• 一部の変更では全件読み取りが必要です。 カラムの追加、削除、名前変更、型変更、 またはテーブルの TRUNCATE、DROP、RENAME を行うと、DBTrail がデータベースを 再度読み取るまでスケジュール更新が一時停止します。再読み取りは最大で 1 日に 1 回 です。この読み取り中は短時間ロックが発生します。開始時にグローバル読み取りロックが 発生するか、RDS と Aurora では読み取り対象のテーブルがロックされます。新しい テーブルは個別の読み取りによって追加されます。インデックスやその他の日常的な変更では 再読み取りは発生しません。
• 履歴の保存にはバケットが必要です。 S3 がない場合、行履歴の保持期間はデフォルトで 48 時間です（--rotate-retain で変更できます）。コピー自体は残り、ローカルディスクに テーブルごとの最新のスナップショット 3 件が保存されます。
• MySQL 9.6 より前のバージョンと MariaDB では、連鎖削除に対応しています。 外部キーによって削除された行はバイナリログに記録されません。recover-cascade は その大部分を再構築し、DBTrail が次にデータベースを全件読み取りするまで、コピーには それらの行が保持されます。
• MySQL サーバーではありません。 レポートは DuckDB で実行され、MySQL クライアントから 実行するものではありません。オプションの MySQL ポート（ベータ版、TLS なし）では、 過去の時点で行またはテーブルがどのような状態だったか、あるいは 2 つの時点の間に 何が変更されたかだけを確認できます。
• 運用はお客様ご自身で行います。 DBTrail と小規模なインデックス用 MySQL は、 お客様のマシン上で稼働します。ディスクとバックアップの管理はお客様が行います。

全項目はこちら：制限事項。

対応するもの

ソース	分析用コピー	行履歴と取り消し
MySQL 8.0、8.4	対応	対応
Percona Server for MySQL 8.0、8.4	対応	対応
Amazon RDS for MySQL	対応（検証済み）	対応（検証済み）
Amazon Aurora MySQL	対応（検証済み）	対応（検証済み）
Google Cloud SQL for MySQL	動作する見込みです。問題があればご報告ください	動作する見込みです
MariaDB 10.11 以降。Amazon RDS for MariaDB を含む	対応	対応。MariaDB ソースを参照してください
PostgreSQL 14 以降	1 回限りのコピーのみ。スケジュール更新には未対応です	ベータ版。PostgreSQL ソースを参照してください

DBTrail はディスク上のバイナリログファイルを必要としないため、マネージドクラウド データベースでも動作します。

インストール

クエリを実行するマシンに Docker Compose と DuckDB が必要です。

curl -fsSL https://raw.githubusercontent.com/dbtrail/dbtrail/main/install.sh | sh

Docker Compose スタックをダウンロードして起動し、DBTrail が応答するまで待機してから、次の手順を表示します。

1. サインインします。 http://127.0.0.1:8090 を開き、ユーザー名と パスワードを作成して、Create & sign in を押します。
2. 接続します。 + Add server をクリックし、MySQL のホストとポートを入力して、 Find it を押します。フォームに DBTrail のユーザーを作成する SQL が表示されます。 MySQL で実行してから、I ran it を押します。残りの確認は DBTrail が行い、 自動的に起動します。
3. 最初の変更を確認します。 MySQL の行を変更します。1 分以内に Overview の Recent changes に表示され、SQL を実行して変更を元に戻す Undo が表示されます。
4. 最初のコピーを作成します。 Snapshots で Read database now を押します。 通常、DBTrail がテーブルを直接読み取るのはこのときだけです。
5. スケジュールを設定します。 Snapshots の Settings タブにある Update the copy で、実行頻度（例：5 分ごと）を選択し、Turn on を押します。 初回以降の各実行では、ソースを読み取るのではなく、記録された変更を反映します。
6. クエリを実行します。 Snapshots で Download を押し、続けて Download the data を押します。.tar.gz を展開し、スナップショットフォルダー内で duckdb -init views.sql を実行します。更新され続けるコピーを読み取る方法については、 DuckDB でクエリを実行するを参照してください。

コマンドラインを使いたい場合は、コマンドラインのクイックスタートを参照してください。

開発者

DBTrail は、Percona の元 MySQL テクニカルリードである Daniel Guzman-Burgos が開発しています。

ドキュメント

はじめに	リファレンス	運用
インストール	DuckDB による分析	デプロイ · キャパシティ
スタートページ · コマンドラインのクイックスタート	ダンプとベースライン · Iceberg エクスポート	ローテーションとステータス
DBA ガイド	クエリとリカバリー · タイムトラベル SQL	Docker
30 秒デモ	リカバリーの検証 · ウェブインターフェース	S3 へのアップロード · S3 IAM ポリシー · アップグレード
制限事項	ストリーミング · インデックス作成 · DDL の追跡	サーバー ID
	AI アシスタントの接続 · MCP サーバー	Parquet のデバッグ
	MariaDB ソース · PostgreSQL ソース

プライバシー

bintrail は DBTrail のコマンドラインツールです。お使いのインフラ内だけで動作します。データベースのデータが外部に送信されることはありません。行、スキーマ、テーブル名、クエリ、ホスト名、DSN、ファイルパスも送信されません。

公式リリースビルドでは、メタデータのみの使用統計が報告されます。実行されたコマンド、成功したかどうか、大まかなエラー分類、お使いのバージョンとプラットフォームが対象です。デフォルトで有効ですが、次の 1 行で無効にできます。

bintrail telemetry off      # or: DO_NOT_TRACK=1, BINTRAIL_TELEMETRY=off
bintrail telemetry show     # prints what would be sent; sends nothing

いかなる種類の識別情報も保存・送信されないため、これらの統計がお使いのマシンやお客様と結び付くことはありません。ご自身でビルドしたバイナリには報告先のアドレスがコンパイル時に含まれず、何も送信できません。TELEMETRY.md には、すべてのフィールドと設定、および両方を保証する CI テストが記載されています。

プライバシーポリシーでは、何も報告しない Claude Desktop 拡張機能（.mcpb）と、AI クライアントがお使いのデプロイ環境にクエリを実行する際のデータの流れについて説明しています。

ライセンス

Apache-2.0：商用利用や本番環境での利用を含め、あらゆる用途で無料で利用できます。 コントリビューションを歓迎します。CONTRIBUTING.mdをご覧ください （CLA が必要です。最初の PR では自動的に案内が表示されます）。

ご自身で運用する代わりに、インデックスサーバーの運用（規模の調整、バックアップ、アップグレード、オンコールでの稼働維持）を任せたい場合は、 dbtrail.comのマネージドサービスをご利用ください。SUPPORT.mdでは、 自分で構築する場合と運用を任せる場合の違いを説明しています。