Quanah, Thanks a lot!
The replication is just fine after loading the LDIF with operational attributes. No overload in consumer to sync database now. Regards, Rodrigo. Quanah Gibson-Mount wrote: > --On Thursday, May 07, 2009 10:36 AM -0700 Rodrigo Costa > <[email protected]> wrote: > >> >> Quanah, >> >> My understanding is that attrs doesn't need to exist in config since by >> default all attributes are shared. > > I think that is what I said. You should not specify the attrs= line > in the syncrepl stanza on the replica, and just use the default. That > way, the entire database is replicated in full to the replica. > >> My original plan was to remove some tasks from the provider, like >> backup, running a slapcat in the consumer(slave). Based in the >> requirement to load the consumer(slave) using a master LDIF dump I'm not >> sure if this is really feasible. > > Why is it a requirement to use a master LDIF dump? I never said that. > What I said, is that you are required to have a fully formed LDIF file > to load LDAP servers that will be syncing (I.e., an LDIF file with the > operational attributes, vs a generated LDIF file from a program that > is missing them.). If you do a slapcat from an existing server, then > it should be fully formed. > >> My idea was : >> 1)Have a provider/consumer running; >> 2)Execute LDIF and binary backups in the consumer(slave) >> 3)In a case of problem in the master just let a HA SW move the master to >> slave and then load "old master" using the slave LDIF file(recovering >> procedure). >> >> Is this feasible? > > Yes, this is pretty standard procedure, minus the binary backups. You > could of course just set up mirror mode or multi-master, as well... > > --Quanah > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > >
