Re: Consumer bdb log explosion
[email protected] Tue, 4 May 2010 16:53:59 -0700 (PDT)
| Newsgroups | gmane.network.openldap.general |
|---|---|
| Message-ID | <[email protected]> |
------=_Part_163303_746177176.1273017239472
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Thank you Aaron and Quanah,
At Quanah's recommendation, I added the DB_CONFIG flag to auto-remove inactive files.
Essentially the ldap-hot-db-backup runs the db_archieve utility hourly!
The archive utility is supposed to backup transaction logs to a different file-system and delete the inactive files.
Hopefully this config change will reduce the excessive number of transaction logs and solve our problems.
The database is backed up every night using slapcat, and I can also recover from the backup directory.
I guess what I don't understand is why the transaction logs occasionally build up so fast. I don't have these problems on the provider (master).
We've had these problems off and on since we went to syncrpl last summer.
Thanks for your comments.
Mark
----- Original Message -----
From: "Aaron Richton"
Subject: Re: Consumer bdb log explosion
On Tue, 4 May 2010, Mark.Hendricks wrote:
> We are running slapd 2.3.43 (Using bdb db4-4.3.29-10.el5) with one provider and two consumers and syncrpl (kerberos/SASL based).
> Occasionally when heavy changes to the provider are made, the consumer bdb logs go crazy and fill up the bdb volume.
Remove unnecessary log files prior to volume fill, hopefully in
conjunction with a sane backup procedure (I don't know what
ldap-hot-backup is, but hopefully it eventually calls slapcat(8) and that
output gets put somewhere safe). I assume "10MB file per second" refers to
transaction log file size, which sounds like sufficient granularity to
remove in a timely fashion in most installations.
http://www.openldap.org/faq/data/cache/738.html
--
Mark Hendricks
Information Security Analyst
Information Technology Services
Humboldt State University
------=_Part_163303_746177176.1273017239472
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><head><style type=3D'text/css'>p { margin: 0; }</style></head><body><=
div style=3D'font-family: Times New Roman; font-size: 12pt; color: #000000'=
><style>p { margin: 0; }</style><div style=3D"font-family: Times New Roman;=
font-size: 12pt; color: rgb(0, 0, 0);"><style>p { margin: 0; }</style><div=
style=3D"font-family: Times New Roman; font-size: 12pt; color: rgb(0, 0, 0=
);">Thank you Aaron and Quanah,<br>At Quanah's recommendation, I added the =
DB_CONFIG flag to auto-remove inactive files.<br>Essentially the ldap-hot-d=
b-backup runs the db_archieve utility hourly! <br>The archive utility is su=
pposed to backup transaction logs to a different file-system and delete the=
inactive files.<br>Hopefully this config change will reduce the excessive =
number of transaction logs and solve our problems.<br><br>The database is b=
acked up every night using slapcat, and I can also recover from the backup =
directory.<br><br>I guess what I don't understand is why the transaction lo=
gs occasionally build up so fast. I don't have these problems on the =
provider (master).<br>We've had these problems off and on since we went to =
syncrpl last summer.<br><br>Thanks for your comments.<br>Mark<br>----- Orig=
inal Message -----<br>From: "Aaron Richton" <br>Subject: Re: Consumer bdb l=
og explosion<br><br>On Tue, 4 May 2010, Mark.Hendricks wrote:<br><br>> W=
e are running slapd 2.3.43 (Using bdb db4-4.3.29-10.el5) with one provider =
and two consumers and syncrpl (kerberos/SASL based).<br>> Occasionally w=
hen heavy changes to the provider are made, the consumer bdb logs go crazy =
and fill up the bdb volume.<br><br>Remove unnecessary log files prior to vo=
lume fill, hopefully in <br>conjunction with a sane backup procedure (I don=
't know what <br>ldap-hot-backup is, but hopefully it eventually calls slap=
cat(8) and that <br>output gets put somewhere safe). I assume "10MB file pe=
r second" refers to <br>transaction log file size, which sounds like suffic=
ient granularity to <br>remove in a timely fashion in most installations.<b=
r><br>http://www.openldap.org/faq/data/cache/738.html<br><br><br>-- <br>Mar=
k Hendricks<br>Information Security Analyst<br>Information Technology Servi=
ces<br>Humboldt State University<br></div></div></div></body></html>
------=_Part_163303_746177176.1273017239472--