Lines Matching refs:provider
20 terms have been deprecated in favor of {{provider}}/{{multi-provider}} and
21 {{consumer}}: A provider can accept external write operations and make them
24 provider/consumer roles are quite fluid: replication updates received in a
26 consumer can also act simultaneously as a provider. Also, a consumer need not
41 replica by connecting to the replication provider to perform
50 polls the provider for updates. In push-based replication the consumer
51 listens for updates that are sent by the provider in realtime. Since the
52 protocol does not require a history store, the provider does not need to
59 syncrepl consumer and provider maintain their content status, the
60 consumer can poll the provider content to perform incremental
62 consumer up-to-date with the provider content. Syncrepl
65 or a provider-side backup at any synchronization status. Syncrepl
67 with the current provider content.
70 In its basic refreshOnly synchronization mode, the provider uses
73 required for the provider to process periodic polling requests is
78 the pull-based synchronization, the provider can maintain a per-scope
80 synchronization, the provider uses a push-based synchronization.
81 The provider keeps track of the consumer servers that have requested
82 a persistent search and sends them necessary updates as the provider
86 changing the provider's configurations and without restarting the
87 provider server, if the consumer server has appropriate access
89 server can stop the replication also without the need for provider-side
111 polls the provider using an LDAP Search request with an LDAP Sync
113 to the provider copy at the time of polling using the information
114 returned in the search. The provider finishes the
121 in the provider. Subsequent updates to the synchronization content
122 in the provider cause additional entry updates to be sent to the
129 In the present phase, the provider sends the consumer the entries updated
130 within the search scope since the last synchronization. The provider
133 provider sends a present message consisting only of the name of the
138 to the provider, by replacing the entries modified at the provider, and
140 nor specified as being present at the provider.
143 same as in the present phase. The provider sends all the requested
146 the provider sends a delete message for each entry deleted from the
154 In the case that the LDAP Sync provider maintains a history store and
156 the last synchronization time, the provider can use the delete phase.
157 If the provider does not maintain any history store, cannot determine
160 the provider should use the present phase. The use of the present
168 At the end of the {{refreshOnly}} synchronization, the provider sends
172 synchronization to the provider.
174 When {{refreshAndPersist}} synchronization is used, the provider sends
179 the persist stage, the provider can also send a Sync Info message
180 containing the synchronization cookie at any time the provider wants
202 provider.
206 a session log in the provider which stores the
216 session log is not persistent over multiple provider invocations.
227 can work with any backends. The LDAP Sync provider can be configured
231 The LDAP Sync provider maintains a {{EX:contextCSN}} for each
233 provider content. It is the largest {{EX:entryCSN}} in the provider
240 The provider stores the {{EX:contextCSN}} of a context in the
244 time the provider reads the last saved {{EX:contextCSN}} into memory
251 Note that at startup time, if the provider is unable to read a
268 The consumer also stores its replication state, which is the provider's
273 with the provider server. It is also used as a provider-side
275 provider server in a cascading replication configuration. Since
276 the consumer and provider state information are maintained in the
278 be promoted to a provider (and vice versa) without any special
292 on the provider. Logically the entry must be deleted on the consumer
293 but in {{refreshOnly}} mode the provider cannot detect and propagate
294 this change without the use of the session log on the provider.
311 When any attribute value in a replicated object is changed on the provider,
323 on the provider. Not counting LDAP and TCP/IP protocol overhead, each time you
338 changelog of a selectable depth in a separate database on the provider. The replication consumer
347 main DB on the provider, it is important to backup/restore both the changelog
357 data to multiple provider ("Provider") Directory servers.
361 * If any provider fails, other providers will continue to accept updates
375 of the servers the same as for single-provider.
379 different usage patterns between the provider and the consumers.
385 * If connectivity with a provider is lost because of a network partition, then
391 writes to the clients that are partitioned from the single provider
399 guarantees of single-provider replication, while also providing the high
400 availability of multi-provider. In Mirror mode two providers are set up to
401 replicate from each other (as a multi-provider configuration), but an
403 the two servers. The second provider will only be used for writes if
404 the first provider crashes, at which point the frontend will switch to
405 directing all writes to the second provider. When a crashed provider is
407 on the running provider and resync.
412 * As long as one provider is operational, writes can safely be accepted
415 * Syncrepl also allows the provider nodes to re-synchronize after any downtime
424 is needed to manage which provider is currently active
434 before the provider can begin pushing changes. In some network configurations,
436 can be made, a provider-initiated push mode may be needed.
441 near (or collocated with) the provider that points to the consumer,
454 server, not in the provider server's configuration file. The initial
458 backup at the provider.
461 loading from the up-to-date backup of the provider content. The
463 to the current provider content. As a result, it is not
464 required to stop the provider server in order to avoid the replication
465 inconsistency caused by the updates to the provider content during
474 H4: Set up the provider slapd
476 The provider is implemented as an overlay, so the overlay itself
478 used. The provider has two primary configuration directives and
506 the performance of the session log on the provider.
556 > provider=ldap://provider.example.com:389
568 In this example, the consumer will connect to the provider {{slapd}}(8)
569 at port 389 of {{FILE:ldap://provider.example.com}} to perform a
574 appropriately in the provider to retrieve the desired replication
575 content. Also the search limits must be high enough on the provider
586 checking when it processes updates from the provider {{slapd}}(8).
593 H4: Start the provider and the consumer slapd
595 The provider {{slapd}}(8) is not required to be restarted.
599 when the first LDAP Sync search arrives at the provider. If an
623 Setting up delta-syncrepl requires configuration changes on both the provider and
705 > provider=ldap://ldapprovider.example.com:389
717 > # Refer updates to the provider
722 in your database that can be used to bind to the provider.
724 Note: An accesslog database is unique to a given provider. It should
758 This sets up syncrepl as a provider (since these are all providers):
784 > olcSyncRepl: rid=001 provider=$URI1 binddn="cn=config" bindmethod=simple
787 > olcSyncRepl: rid=002 provider=$URI2 binddn="cn=config" bindmethod=simple
790 > olcSyncRepl: rid=003 provider=$URI3 binddn="cn=config" bindmethod=simple
797 Now start up the provider and a consumer/s, also add the above LDIF to the first consumer, second c…
799 We still have to replicate the actual data, not just the config, so add to the provider (all active…
811 > olcSyncRepl: rid=004 provider=$URI1 binddn="$MANAGERDN" bindmethod=simple
814 > olcSyncRepl: rid=005 provider=$URI2 binddn="$MANAGERDN" bindmethod=simple
817 > olcSyncRepl: rid=006 provider=$URI3 binddn="$MANAGERDN" bindmethod=simple
839 {{EX:SID}} which must be unique for each replication provider is a
843 is not a valid {{SID}} for multi-provider replication, and you
851 slapd syncrepl provider, then the only change is the following two directives:
856 Note: You need to make sure that the {{serverID}} of each provider node is
861 The first step is to configure the syncrepl provider the same as in the
862 {{SECT:Set up the provider slapd}} section.
875 > provider=ldap://ldap-sid2.example.com
894 > provider=ldap://ldap-sid1.example.com
912 dedicated proxy software, 2. using a Back-LDAP proxy as a syncrepl provider
928 consistency guarantees of single-provider replication, while also providing the
929 high availability of multi-provider replication.
1010 > provider=ldap://localhost:9011/
1062 > # Refer updates to the provider
1100 If you do not have access to modify the provider directory configuration you can
1140 > provider=ldap://localhost:9011/