<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Dear Bron<br>
<br>
After about 3 hours the messages stopped.<br>
<br>
I notice a massive change in db_stat -c when comparing 2.3.16 to 2.4.5
the earlier version seemed to hold locks for ages for example the
number of current would be about 40+ depending on concurrent
connections now it is Zero <br>
<br>
Thanks to ALL<br>
Stephen Carr<br>
<br>
<br>
Bron Gondwana wrote:
<blockquote cite="mid:20101204090109.GA32049@brong.net" type="cite">
<pre wrap="">On Sat, Dec 04, 2010 at 01:59:33PM +1030, Stephen Carr wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Dear All
I had a problem last week upgrading 2.3.16 to 2.4.4 due to a CRC bug.
I have now updated from 2.3.16 to 2.4.5 with no major problems but I am
getting a massive number of records of the type below - I will have to
monitor the log size.
The sync_client and replica have the same time ( actually the replica
gets it date off the sync_client every 2 minutes).
Also I get a very few like this
Dec 4 13:58:12 brooks sync_client[17782]: inefficient replication (17 >
15) user.user1
Dec 4 13:58:14 brooks sync_client[17782]: inefficient replication (12 >
10) user.user2
</pre>
</blockquote>
<pre wrap=""><!---->
you might get them at the start. Unless you have immediate expunge
turned on, you shouldn't get too many after that.
</pre>
<blockquote type="cite">
<pre wrap="">Dec 4 13:55:09 brooks sync_client[17782]: RECORD MISMATCH WITH REPLICA:
more recent on replica
Dec 4 13:55:09 brooks sync_client[17782]: master uid:31107 modseq:1
last_updated:1276248211 internaldate:1276248211 flags:(\Seen)
Dec 4 13:55:09 brooks sync_client[17782]: replica uid:31107 modseq:1
last_updated:1287574229 internaldate:1276248211 flags:(\Seen)
</pre>
</blockquote>
<pre wrap=""><!---->
There you go - higher "last_updated" on the replica. This isn't really
a problem - it will clean up with time as the last_updated fields get
in sync between the two ends.
I did debate not counting last_updated for the purpose of replication
sync, but decided it's actually useful for determining which end is more
recent, and you can't do that if the replica always looks newer!
Bron.
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Stephen Carr
Computing Officer
School of Civil and Environmental Engineering
The University of Adelaide
Tel +618-8303-4313
Fax +618-8303-4359
Email <a class="moz-txt-link-abbreviated" href="mailto:sgcarr@civeng.adelaide.edu.au">sgcarr@civeng.adelaide.edu.au</a>
CRICOS Provider Number 00123M
-----------------------------------------------------------
This email message is intended only for the addressee(s)and
contains information that may be confidential and/or copyright.
If you are not the intended recipient please notify the sender
by reply email and immediately delete this email. Use, disclosure
or reproduction of this email by anyone other than the intended recipient(s) is strictly prohibited. No representation is made
that this email or any attachments are free of viruses. Virus
scanning is recommended and is the responsibility of the recipient.</pre>
</body>
</html>