Sync Gatewayの機能全般について、以下の記事も合わせてご参照ください。
概要
Sync GatewayのSync関数は、ドキュメントのチャネルへのルーティング及びドキュメント書き込み時のチャネルへのユーザアクセス制御に関係しています。アプリケーションの仕様変更等に伴い、Sync関数を変更する場合、変更後のSync関数によって、バケット内の既存のすべてのドキュメントを再処理して、ルーティングとアクセスの割り当てを再計算する必要が生じる場合があります。
この目的のために、Admin REST APIは、データベース内のすべてのドキュメントの再処理を開始する再同期エンドポイントを提供しています。
エンドポイント定義
/{tkn-db}/resync
応答メッセージには、再同期を実行した結果として行われた変更の数が含まれています。
再同期実行必要性判断基準
Sync関数への変更が書き込みセキュリティにのみ影響する（ルーティング/アクセスには影響しない）場合は、再同期操作を実行する必要はありません。
再同期操作では、すべてのドキュメントがすでにデータベースに書き込まれている状況で行われます。
そして、Admin REST APIである再同期操作を実行する場合、Sync関数の実行コンテキストはadminユーザーです。そのため、Sync関数内で書き込み操作を管理するために、requireUser、requireAccessおよびrequireRoleを使用している場合であっても、これらのメソッドは常に成功します。
チャネル/アクセスルールを変更する場合でも、Sync関数変更以降に、書き込まれたドキュメントにのみそれらのルールを適用したい場合は、再同期操作を実行する必要はありません。
Sync関数の更新、再同期実施手順
Sync関数を更新し、再同期を実行する際の手順を以下に整理ます。
-
Sync関数を更新します。
-
新しい構成をSync Gatewayプロセスに反映します（構成ファイルの更新など必要に応じ、Sync Gatewayを再起動します）。
-
データベースをオフラインにします。次の管理RESTAPIエンドポイントを使用します：
/{tkn-db}/_offset -
データベースを再同期します。次の管理REST APIエンドポイントを使用します：
/{tkn-db}/resync -
データベースをオンラインに戻します。次の管理RESTAPIエンドポイントを使用します：
/{tkn-db}/_online
影響
再同期は、データベース内のすべてのドキュメントを新しい関数で処理する必要があるため、コストのかかる操作です。
すべてのドキュメントがスキャンされるまでユーザーのフルアクセス権限がわからないため、データベースはこのプロセスが完了するまで要求を受け入れることができません。したがって、Sync関数の更新により、データベースがオフラインのとき（つまり、/{tkn-db}/_offlineと/{tkn-db}/_onlineの呼び出しの間）にアプリケーションのダウンタイムが発生します。
アクセス取り消しの反映タイミング
Sync関数を変更してユーザーのドキュメントへのアクセスを取り消す場合、新しい設定は、そのドキュメントの新しいリビジョンがSync Gatewayに保存されたときにのみ有効になります。再同期操作を実行しても、現在のドキュメントへのアクセスは取り消されません。
複数Sync Gatewayインスタンス運用時の考慮点
複数のSync Gatewayインスタンスが負荷を共有しているクラスター環境では、すべてのインスタンスが同じ構成を共有する必要があるため、プロセスを停止するか、/{tkn-db}/_offlineエンドポイントを使用してすべてのインスタンスをオフラインにする必要があります。
その後、構成更新後、データベースを更新できるように1つのインスタンスを起動する必要があります。この時点で複数のインスタンスが実行されている場合、それらは互いに競合します。最初のインスタンスがデータベースの更新を終了した後、他のインスタンスを開始できます。
Sync関数更新/再同期によるダウンタイム回避のためのワークアラウンド
更新中にデータベースへのアクセスを確保する必要がある場合は、事前にSync Gatewayのバケットの読み取り専用バックアップを作成してから、バックアップバケットで読み取り専用モードでセカンダリSync Gatewayを実行できます。更新が完了したら、メインのSync Gatewayとバケットに切り替えます。
関連情報