[Date Prev][Date Next] [Chronological] [Thread] [Top]

syncrepl simplification

There seems to still be a lot of unnecessary complexity in the syncrepl implementation. I'm rather skeptical of the value of having multiple consumer contexts within a single database. A single database like this cannot be used in a cascade to provide for other consumers, because there can only be one provider context and there is no assurance that the CSNs of the multiple consumers will be in any way coherent. As such, it makes the most sense to keep only one consumer context per database/naming context.

If we restrict the implementation to using only one consumer per context, then we can collapse the consumer contextCSN into the suffix entry, the same as was done with the provider context. Then we don't need to mess around with the slapadd options for promotion/demotion of provider/consumer since the same contextCSN info is used in all cases. This would allow us to remove the -p, -r, -w, and -i options from slapadd, and save a lot of administrative overhead re: promotion/demotion. (Actually I would keep the "-w" option to write the contextCSN. Saves time for the provider, and allows the resulting database to be slapcat'd and immediately slapadd'd into any consumers without any more fuss.)

Comments? I guess I'm looking for a compelling example of the usefulness of multiple consumers in a single database. I suspect any example can be accomodated using separate databases and the glue overlay, and the glue approach probably provides more efficient security/isolation anyway.

 -- Howard Chu
 Chief Architect, Symas Corp.       Director, Highland Sun
 http://www.symas.com               http://highlandsun.com/hyc
 Symas: Premier OpenSource Development and Support