Thanks quanah for detailed explanation you have sorted the confusion.
I have last doubt that read and write bifurcation for ldap connection
string is to be handled in application code . It has nothing to do on the
ldap end. I mean I need to define
for writes in the application code.
On Wed, Mar 10, 2021, 23:19 Quanah Gibson-Mount <quanah(a)symas.com> wrote:
--On Wednesday, March 10, 2021 10:38 PM +0530 chandan jain
> Understood quanah, but I have a single app which performs both read and
> write. App is using single connection string for binding with ldap. So
> shall I use two separate connection string, one for read and one for
> write in the application code ?
If you look closely at my response, I noted that apps that do writes
use the same pool for reads. This is generally due to the fact most apps
I've run across do a read after write and may hit problems if the change
not there (i.e., due to replication delays).
> Also, as per the configuration setup suggested by you, how the
> replication need to be setup, I mean mirror mode across write pool
> members and another mirroring for read pool members from one of write
> pool member.
I don't understand this question. There's a single set of servers, say A,
B, C, D. There are two pools configured in the load balancer. The first
pool uses a sticky setting, and always points to a single server for write
ops (say A) unless its down, at which point it will fail over to the first
available server (say B). The second pool is for reads, and does whatever
algorithm you think best (say round robin), and bounces between A, B, C, D.
What replication mechanism is in use has nothing to do with the load
balancer configuration. I would generally advise using delta-syncrepl
between nodes A, B, C D, all of which connect directly to one another and
don't interact directly with the load balancer at all.
Packaged, certified, and supported LDAP solutions powered by OpenLDAP: