syncrepl
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2021/04/11 06:14 UTC 版)
「OpenLDAP」の記事における「syncrepl」の解説
基本的な同期操作は RFC 4533 に記述されている。このプロトコルは、変更ための無停止データベースが必要ないように定義されている。変更内容は、各エントリに格納される変更シーケンス番号（CSN）情報により区別され、最新の削除を追跡するのに有用な任意のセッションログにより最適化されている。レプリケーションクライアント（コンシューマ）がレプリケーションサーバー（プロバイダ）に「コンテンツ同期検索」を送信する操作モデルとなっている。（特に以前にプロバイダと同期していた場合）コンシューマは、この検索でクッキーを提供することができる。 RFC 4533 の OpenLDAP 実装では、このクッキーには、プロバイダから受信した最新のCSN（contextCSNと呼ばれる）が含まれている。 次に、クッキーによる既知の内容に基づいてコンシューマを同期状態にするために、プロバイダは、未変更の全エントリ、および、追加・変更・削除された全エントリを検索または、同期情報の結果として返す。なお、未変更のエントリはリフレッシュステージの現在のフェーズでのみ使用される。更新フェーズではすべての現在の属性を追加する。クッキーが存在しないか、コンシューマが完全に同期していないことを示している場合、プロバイダはリフレッシュ段階で、それが持つ各エントリの追加を送信する。理想的な場合、応答時のリフレッシュステージには、コンシューマがプロバイダと最後に同期した時刻以降に発生したわずかな変更・削除が対象となる。しかし、プロバイダに保持されているセッションログの状態が限られているため、現在の全エントリが必要になることがある。コンシューマがプロバイダと最後に同期した後、プロバイダが削除したものを処理するために、変更されていないすべてのエントリが必要となる。 検索は、refresh または refreshAndPersist モードで実行できる。リフレッシュステージは常に最初に発生する。リフレッシュステージでは、present と delete の2つのフェーズが発生し、present は常に delete の前に発生する。フェーズは、フェーズの完了を示す同期情報の応答によって区切られる。リフレッシュおよび持続ステージもまた、同期情報の応答によって区切られる。存在または削除されるエントリのグループをよりコンパクトに表現する最適化は、これらのエントリの entryUUID 値のリストを識別する syncIdSet を含む同期情報の応答を使用する。 present フェーズは、delete フェーズと以下のように区別される。変更されていないエントリは、present フェーズでのみ返される。削除されるエントリは、delete フェーズでのみ返される。追加エントリ（変更されたエントリのすべての属性を示す）は、どちらのフェーズでも返すことができる。したがって、present フェーズの最後において、コンシューマをプロバイダと同期させるためにコンシューマは次のエントリを削除しなければならない。 コンシューマが追加エントリで識別できなかったエントリ プロバイダには存在ないことを示すための present フェーズ中の現在の応答のエントリ persist ステージが始まると、プロバイダは、リフレッシュステージ完了後の追加、変更、および削除の全エントリの検索結果を送信する。persist ステージは無期限に続き、検索には最終的な「完了」応答がない。対照的に、リフレッシュモードでは refresh ステージのみが発生する。refresh ステージは、persist または delete フェーズ（現在アクティブなフェーズのいずれか）も完了応答で終了する。
※この「syncrepl」の解説は、「OpenLDAP」の解説の一部です。
「syncrepl」を含む「OpenLDAP」の記事については、「OpenLDAP」の概要を参照ください。
- syncreplのページへのリンク
