SQLite 用データベース リモート コピー ツール

$ sqlite3_rsync ORIGIN REPLICA ?OPTIONS?

1. ORIGIN または REPLICA のいずれかは、「USER@HOST:PATH」の形式にすることができます。もう 1 つは単純な PATH です。このユーティリティにより、REPLICA が ORIGIN のコピーになります。

   1. REPLICA がまだ存在しない場合は作成されます。

   2. ssh
      は通信に使用されるため、「USER@HOST」は SSH エイリアスである可能性があります。

   3. ORIGIN または REPLICA のいずれかがリモートである必要はありません。 ORIGIN と REPLIA の両方がローカルの場合、sqlite3_rsync ユーティリティは正常に動作します。

2. このユーティリティの実行中は、両方のデータベースが「ライブ」になっている可能性があります。このユーティリティの実行中、他のプログラムはどちらかの側でデータベースにアクティブに接続できます。このユーティリティの実行中に、他のプログラムは ORIGIN に書き込み、REPLICA から読み取ることができます。

   REPLICA は、sqlite3_rsync コマンドの開始時に存在していた ORIGIN のスナップショットのコピーになります。このコマンドの実行中に他のプロセスが ORIGIN の内容を変更した場合、それらの変更は ORIGIN に適用されますが、REPLICA には転送されません。したがって、REPLICA は、ある瞬間における ORIGIN の完全に整合性のあるスナップショットになります。

3. 同期には、次のような帯域幅効率の高いプロトコルが使用されます。 rsync
   （その名前の由来です）。

1. データベース ファイルは両方とも次の場所にある必要があります。 ウォール モードであり、同じページサイズを持つ必要があります。

2. sqlite3_rsync の実行中、REPLICA は読み取り専用です。このユーティリティの実行中に REPLICA に対してクエリを実行できますが、トランザクションの書き込みは実行できません。

3. このユーティリティを呼び出すたびに、単一のデータベースのみが同期されます。標準の「rsync」のように、ワイルドカードを使用してさまざまなデータベースを同期することは（まだ）できません。

4. ORIGIN または REPLICA の少なくとも 1 つがローカル マシン上に存在する必要があります。これらを両方とも他のマシン上のデータベースにすることはできません。

5. リモート システムでは、このユーティリティを SSH のデフォルトの $PATH 内のディレクトリの 1 つにインストールする必要があります。の
   /usr/local/bin 多くの場合、ディレクトリが適切な選択となります。あるいは、 --exe
NAME フラグは、バイナリのリモートの場所を指定するために使用できます。 --exe /opt/bin/sqlite3_rsync。

6. レプリカはオリジナルに非常に近いコピーですが、正確なコピーではありません。すべてのテーブル (およびインデックス) の内容は、レプリカ内でバイト単位で同一になります。ただし、若干の変更が生じる可能性があります。 データベースヘッダー。特に、レプリカにはオリジナルとは次のような違いがあります。

   1. の チェンジカウンター データベース ヘッダーのバイト 24 ～ 27 がレプリカ内で増加する可能性があります。

   2. の 有効なバージョン番号 データベース ヘッダーの 96 ～ 99 のバイト数は、元のデータベースへの最後の書き込み者のバージョン番号ではなく、コピーを作成した sqlite3_rsync プログラムの SQLite バージョン番号になります。

7. Windows では、USER@ プレフィックスのない 1 文字の HOST は、ホスト名ではなく Windows ドライブ文字として解釈されます。

実行可能ファイルを $PATH 上のどこかに置くだけで、sqlite3_rsync をインストールできます。リモート システムと同期している場合は、sqlite3_rsync 実行可能ファイルがローカル システムとリモート システムの両方にインストールされている必要があります。 sqlite3_rsync 実行可能ファイルをリモート システムにインストールする場合は、それが SSH で使用される $PATH 上にあることを確認してください。多くの場合、sqlite3_rsync 実行可能ファイルを /usr/local/bin ディレクトリに置くのが良い選択です。

残念ながら、MacOS では、ssh のデフォルトの PATH は「/usr/bin:/bin:/usr/sbin:/sbin」であり、MacOS ではこれらのディレクトリに新しいプログラムを追加することはできません。したがって、リモート Mac と同期しようとしている場合は、sqlite3_rsync に –exe コマンド ライン引数を追加して、リモート側で sqlite3_rsync をインストールした場所を指定する必要があります。例えば：

sqlite3_rsync sample.db mac:sample.db --exe /Users/xyz/bin/sqlite3_rsync

このドキュメントの執筆者は、Windows 上で SSHD を実行することに成功したことがありません。おそらく彼はそれを理解し、将来のリリースでリモート Windows マシンとの間でデータベースを同期する手順を提供できるようになるでしょう。

このプロトコルは、レプリカが各ページの暗号化ハッシュをオリジン側に送信し、オリジンがハッシュが一致しないページの完全なコンテンツを送り返すものです。

レプリカに R ページが含まれているとします。レプリカとオリジンがすでに同一である場合、約 R*20 バイトのハッシュがレプリカからオリジンに送信され、些細なオーバーヘッドとハウスキーピング トラフィックを除けば、ネットワーク上を移動するものは何もありません。したがって、ページ サイズが 4096 バイトのデータベースの場合、このユーティリティの実行に必要な最小帯域幅はデータベースの約 0.5% に相当します。最悪の場合の同期は、レプリカとオリジンが完全に異なり、共通のページがない場合に発生します。この場合、ネットワーク トラフィックの合計はデータベース サイズの約 100.5% になります。

前の段落の計算では、SSH が実装する圧縮は考慮されていません。ほとんどの SQLite データベースは圧縮可能であるため、完全な同期にかかる帯域幅コストはおそらくデータベース サイズの 100.5% 未満です。ただし、暗号化ページ ハッシュは圧縮できないため、最適な場合でもデータベース サイズの約 0.5% (ページ サイズ 4096 バイト) よりも優れることはありません。ページ サイズが大きくなると、必要な最小帯域幅が減少します。最適なケースは、ページ サイズが 65,536 バイトのデータベースのデータベース サイズの約 0.03% です。

通常の rsync は SQLite トランザクションを理解できません。 Rsync は ORIGIN のコピーを REPLICA に作成しますが、そのコピーは一貫性がない可能性があります。コピーの一部は 1 つのトランザクションからのものであり、他の部分は別のトランザクションからのものである可能性があります。データベースのコピーが破損している可能性があります。

rsync の実行中に他のプロセスがデータベースに接続されておらず、データベースに
ホットジャーナルそうすると、rsync はデータベースの一貫したコピーを作成します。ただし、これらの条件が両方とも満たされることを保証できない場合、rsync は破損したコピーを生成する可能性があります。一方、sqlite3_rsync ユーティリティは常に一貫性のあるコピーを生成します。