OK, but if I put a single connection string, how below setup suggested by quanah will work.
I have a single application which read as well as write to ldap.
****************************
You set up two pools in the load balancerPool 1 -> For apps that only do reads, and handles load distribution inwhatever method you feel best. Example DNS: ldap.example.comPool 2 -> For apps that write directly. Sticky session to a singleprovider unless it goes offline. Example DNS: ldap-provider.example.com If you look closely at my response, I noted that apps that do writes shoulduse the same pool for reads. This is generally due to the fact most appsI've run across do a read after write and may hit problems if the change isnot 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 firstpool uses a sticky setting, and always points to a single server for writeops (say A) unless its down, at which point it will fail over to the firstavailable server (say B). The second pool is for reads, and does whateveralgorithm 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 loadbalancer configuration. I would generally advise using delta-syncreplbetween nodes A, B, C D, all of which connect directly to one another anddon't interact directly with the load balancer at all.
***********************************
Regards
Chandan
On 3/10/21 6:08 PM, chandan jain wrote:
> but I have a single app which performs both read and
> write. App is using single connection string for binding with ldap.
Keep it like this and simply treat the application as a writing application.
> So shall I use two separate connection string, one for read and one
> for write in the application code ?
No! You will likely run into "interesting" read-after-write issues which
are hard to track down.
Ciao, Michael.