We have a 3 node N-Way Multi master set running 2.4.31. I have been looking and trying to find a way to have asynchronous replication because synchronous replication is not required and we believe is actually slowing us down. I read in one article that by default n-way multi-master was doing asynchronous replication. But then another article kind of mucked that up. I ran through all of my db files with db_stat to get the internal pages and page size to be sure that my DB_Config was set with a large enough paging space and from my calculations it has more than enough. Not enough to cache the entire db, but enough.
So how can I be sure that we are using asynchronous replication with the n-way mulri master configuration.
Thank you, Eric Speake Web Systems Administrator O'Reilly Auto Parts
This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS � 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you.
--On Friday, September 27, 2013 2:46 PM -0500 espeake@oreillyauto.com wrote:
We have a 3 node N-Way Multi master set running 2.4.31. I have been looking and trying to find a way to have asynchronous replication because synchronous replication is not required and we believe is actually slowing us down. I read in one article that by default n-way multi-master was doing asynchronous replication. But then another article kind of mucked that up. I ran through all of my db files with db_stat to get the internal pages and page size to be sure that my DB_Config was set with a large enough paging space and from my calculations it has more than enough. Not enough to cache the entire db, but enough.
So how can I be sure that we are using asynchronous replication with the n-way mulri master configuration.
What you should do is use delta-syncrepl based MMR with OpenLDAP 2.4.36. Delta-syncrepl based MMR only replicates the exact changes that occurred, rather than the entries, vastly reducing the amount of data being transferred between nodes. I would also recommend switching to back-mdb with OpenLDAP 2.4.36, as it handles writes at *least* 50 times faster than back-hdb/back-bdb.
I've already told you *multiple* times that there are known bugs with the MMR code in 2.4.31, and you will end up having data issues, yet you continue to ignore this. Why, is beyond me. Stop wasting your time and everyone else's by insisting to run out of date code with known bugs.
--Quanah
--
Quanah Gibson-Mount Lead Engineer Zimbra Software, LLC -------------------- Zimbra :: the leader in open source messaging and collaboration
From: Quanah Gibson-Mount quanah@zimbra.com To: espeake@oreillyauto.com, openldap-technical@openldap.org Date: 09/27/2013 03:49 PM Subject: Re: Synchronous or asynchronous replication Sent by: openldap-technical-bounces@OpenLDAP.org
--On Friday, September 27, 2013 2:46 PM -0500 espeake@oreillyauto.com wrote:
We have a 3 node N-Way Multi master set running 2.4.31. I have been looking and trying to find a way to have asynchronous replication because synchronous replication is not required and we believe is actually
slowing
us down. I read in one article that by default n-way multi-master was doing asynchronous replication. But then another article kind of mucked that up. I ran through all of my db files with db_stat to get the internal pages and page size to be sure that my DB_Config was set with a large enough paging space and from my calculations it has more than enough. Not enough to cache the entire db, but enough.
So how can I be sure that we are using asynchronous replication with the n-way mulri master configuration.
What you should do is use delta-syncrepl based MMR with OpenLDAP 2.4.36. Delta-syncrepl based MMR only replicates the exact changes that occurred, rather than the entries, vastly reducing the amount of data being transferred between nodes. I would also recommend switching to back-mdb with OpenLDAP 2.4.36, as it handles writes at *least* 50 times faster than back-hdb/back-bdb.
I've already told you *multiple* times that there are known bugs with the MMR code in 2.4.31, and you will end up having data issues, yet you continue to ignore this. Why, is beyond me. Stop wasting your time and everyone else's by insisting to run out of date code with known bugs.
--Quanah
--
Quanah Gibson-Mount Lead Engineer Zimbra Software, LLC -------------------- Zimbra :: the leader in open source messaging and collaboration
If I could get 2.4.35 or 2.4.36 to build a debian package as required by our company I would use a newer version. Every time I run the build it errors out in the config. So I have tried. I can't do just a build I have to be able to create the package for our puppet implementation.
Is there an update 2.4 admin doc out there that shows how to do this in a dynamic setup instead of the slapd.conf. Our MMR is working great with the exception of one app that rebuilds groups and keeps them up to date. this application going against a single 2.4.21 version finished in an hour and after 8 hours it is not completing. Other than the replication, everything is pretty much the same as far as cacheing and other DB tuning settings.
Sorry that I am wasting your time. Eric -- This message has been scanned for viruses and dangerous content, and is believed to be clean. Message id: 0001A600A4C.AD92D
This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS � 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you.
--On Friday, September 27, 2013 4:09 PM -0500 espeake@oreillyauto.com wrote:
If I could get 2.4.35 or 2.4.36 to build a debian package as required by our company I would use a newer version. Every time I run the build it errors out in the config. So I have tried. I can't do just a build I have to be able to create the package for our puppet implementation.
If you are having problems with Debian's dpkg system, then I would advise contacting the debian folks etc about how to properly build dpkg's. That certainly is not an OpenLDAP specific issue. I would note that Debian's default packages for OpenLDAP have a lot of problems (like linking to GnuTLS instead of OpenSSL among other things).
So if you are just trying to "upgrade" what Debian already ships, that is a bad starting point. I would advise creating your own fresh .deb's that install into your own location, so as not to conflict with the system libraries.
--Quanah
--
Quanah Gibson-Mount Lead Engineer Zimbra Software, LLC -------------------- Zimbra :: the leader in open source messaging and collaboration
--On Friday, September 27, 2013 10:40 PM -0500 espeake@oreillyauto.com wrote:
That is what I have done so far was a fresh install and not part of a distro. And I have everything working with the exception of this one application. And it appears that tuning the DB should be what fixes it. According to the documentation from the openldap site I should need about 150 MB for the cache setting in my DB_config. It was already set at 512MB The is a setting dealing with the number of records that can be open at onetime ad it is set to 50000. I thoguht about moving that to 100000 and the other one, I have to appologize I am at home right and don't have all of the information in front of me, to 300000 or three times the open records as recommended in the admin guide.
I just need to be pointed to a little more information on tuning the DB.
Again, you need to run a current release if you want to do MMR. Period. No amount of tuning the DB is going to fix this particular problem.
Once you get on a current release, you can switch to MDB, which doesn't need all the tuning malarkey BDB does. So you get to resolve two problems at once.
I don't even know what "a fresh install" even means. A fresh install of OpenLDAP? Then I would assume you did it with 2.4.36. But you constantly say you are running 2.4.31.
--Quanah
--
Quanah Gibson-Mount Lead Engineer Zimbra Software, LLC -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-technical@openldap.org
-
espeake＠oreillyauto.com -
Quanah Gibson-Mount