Hi!
I am running OpenLDAP 2.4.47 with significant write activity (in the hundreds of modify/add/del ops per second), and a large volume of data compared to available RAM (about 20G)
For backups, I am trying to do a live slapcat dump to maintain availability, and encountered the growth in MDB database size described in those ITS:
http://www.openldap.org/its/index.cgi/Software%20Bugs?id=7904 http://www.openldap.org/its/index.cgi/Software%20Bugs?id=8226
I am however a little puzzled over the rtxnsize option. My understanding is that this option splits large read transactions (such as backups) into smaller transactions, allowing freed pages to be reused before the end of the full operation. This is critical for me because backups take more than 10 minutes and a significant portion of my MDB file (100G) gets filled up during that time.
However, setting rtxnsize to a smaller value from the default does not seem to have any effect on the growth of my MDB file. I have made several tries with different rtxnsizes from 1M to 100, starting from a freshly rebuilt MDB database every time.
I saw that the rtxnsize option was added to handle an issue with replication, so perhaps it was never supposed to help in my particular case. For the whole duration of a slapcat backup, I see the same transaction ID from the slapcat process in mdb_stat -r.
I noticed that using ldapsearch for backups behaves much better (MDB only grows by a few thousand pages in my workload), but takes a while longer, regardless of the rtxnsize setting
Is it normal that rtxnsize does not affect slapcat dumps while slapd is running, or am I missing something?
How would you handle live backups of a database with lots of write activity?
Maxime Besson wrote:
Hi!
I am running OpenLDAP 2.4.47 with significant write activity (in the hundreds of modify/add/del ops per second), and a large volume of data compared to available RAM (about 20G)
For backups, I am trying to do a live slapcat dump to maintain availability, and encountered the growth in MDB database size described in those ITS:
http://www.openldap.org/its/index.cgi/Software%20Bugs?id=7904 http://www.openldap.org/its/index.cgi/Software%20Bugs?id=8226
I am however a little puzzled over the rtxnsize option. My understanding is that this option splits large read transactions (such as backups) into smaller transactions, allowing freed pages to be reused before the end of the full operation. This is critical for me because backups take more than 10 minutes and a significant portion of my MDB file (100G) gets filled up during that time.
The rtxnsize option only affects LDAP Search operations.
--On Friday, March 29, 2019 8:40 PM +0000 Howard Chu hyc@symas.com wrote:
Maxime Besson wrote:
Hi!
How would you handle live backups of a database with lots of write
activity?
Sadly Howard did not answer the above question you had, so I'll give you the best solution I can think of based on what's currently available:
Have a secondary server (a replica) of the first. Using cn=config, delete the syncrepl statement from the replica, run slapcat, then re-add the syncrepl statement when you're done. As long as the server is under heavy write traffic and backups take signficant time, you will unfortunately heavily fragment the DB.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
On 3/29/19 8:51 PM, Quanah Gibson-Mount wrote:
Have a secondary server (a replica) of the first.> Using cn=config, delete the syncrepl statement from the replica, run slapcat, then re-add the syncrepl statement when you're done. As long as the server is under heavy write traffic and backups take signficant time, you will unfortunately heavily fragment the DB.
You mean a dedicated backup replica? If yes, would less indexing on this backup replica also help?
If I understand ITS#7904 and ITS#8226 correctly the backup replica would potentially also cause search operations with large result sets. Yes, rtxnsize helps for those. But I believe it would also help if the backup replica is faster while catching up the changes missed during slapcat.
Ciao, Michael.
Quanah Gibson-Mount quanah@symas.com schrieb am 29.03.2019 um 20:51 in
Nachricht <A26081897ABCFAFC0B8B8F1A@[192.168.1.39]>:
‑‑On Friday, March 29, 2019 8:40 PM +0000 Howard Chu hyc@symas.com wrote:
Maxime Besson wrote:
Hi!
How would you handle live backups of a database with lots of write
activity?
Sadly Howard did not answer the above question you had, so I'll give you the best solution I can think of based on what's currently available:
Have a secondary server (a replica) of the first. Using cn=config, delete the syncrepl statement from the replica, run slapcat, then re‑add the syncrepl statement when you're done. As long as the server is under heavy write traffic and backups take signficant time, you will unfortunately heavily fragment the DB.
Hi!
I wonder: Is there a more elegant solution that lets one "pause" a replication? Such a feature sounds useful for various reasons.
Regards, Ulrich Windl
‑‑Quanah
‑‑
Quanah Gibson‑Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
On 3/29/19 8:51 PM, Quanah Gibson-Mount wrote:
Have a secondary server (a replica) of the first. Using cn=config, delete the syncrepl statement from the replica, run slapcat, then re-add the syncrepl statement when you're done. As long as the server is under heavy write traffic and backups take signficant time, you will unfortunately heavily fragment the DB.
Thanks for your suggestion!
In your proposed scenario, is there a difference between removing olcSyncRepl from the replica, and stopping the replica completely, other than the replica being unavailable for read queries during backup ?
My understanding is that in both cases, replication would have to catch up with the master with a full present phrase (unless I use a large enough session log).
Since ITS#8486 and OpenLDAP 2.4.46, it seems that having a large session log is a viable option, but how large could those modification allow the sessionlog to grow? 100K ? 1M entries ?
Regards,
--On Monday, April 01, 2019 3:19 PM +0200 Maxime Besson maxime.besson@worteks.com wrote:
On 3/29/19 8:51 PM, Quanah Gibson-Mount wrote:
Have a secondary server (a replica) of the first. Using cn=config, delete the syncrepl statement from the replica, run slapcat, then re-add the syncrepl statement when you're done. As long as the server is under heavy write traffic and backups take signficant time, you will unfortunately heavily fragment the DB.
Thanks for your suggestion!
In your proposed scenario, is there a difference between removing olcSyncRepl from the replica, and stopping the replica completely, other than the replica being unavailable for read queries during backup ?
Yes, that would work as well.
My understanding is that in both cases, replication would have to catch up with the master with a full present phrase (unless I use a large enough session log).
If you're not using delta-syncrepl (Which is the only replication method I endorse) then yes, that's correct.
Since ITS#8486 and OpenLDAP 2.4.46, it seems that having a large session log is a viable option, but how large could those modification allow the sessionlog to grow? 100K ? 1M entries ?
The sessionlog contains the entry ID of the entries modified, up to the full size of the sessionlog or the total number of entries in the database (i.e., an entry won't be listed more than once in the list). So if you had a sessionlog larger than the number of entries, and every single entry in your DB was modified, it would match the number of entries in the DB. Otherwise, it'll be smaller than that. The sessionlog is also not persistent, so it gets reset on a restart of the master.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
openldap-technical@openldap.org
-
Howard Chu -
Maxime Besson -
Michael Ströder -
Quanah Gibson-Mount -
Ulrich Windl