sync_client errors out after 2.3.16 -> 2.5.9 upgrade
ktm at rice.edu
Fri Aug 12 13:12:31 EDT 2016
On Wed, Aug 10, 2016 at 12:30:03PM +1000, ellie timoney wrote:
> On Tue, Aug 2, 2016, at 02:14 PM, Kenneth Marshall via Info-cyrus wrote:
> > On Tue, Aug 02, 2016 at 12:34:13PM +1000, Bron Gondwana wrote:
> > > 2.3.2 wasn't version 10, it was version 7! It would have upgraded through 8, 9, 10 - and maybe you needed to reconstruct to get GUIDs for those versions - that sounds familiar.
> > >
> > > Bron.
> > >
> > Hi Bron,
> > Is there a way to identify mailboxes with no GUID? Then I could target
> > them
> > for reconstruction first.
> > Regards,
> > Ken
> Hi Ken,
> I don't suppose you still have mailboxes with no GUID? Or have you
> already found and "reconstruct -G"ed everything?
> I've attached a patch that does two things, which are kind of the same
> * If the mailbox on either end of the replication is of a version < 10,
> then the operation will fail cleanly and early with an "Operation is not
> supported on mailbox" error (rather than trying to do the replication,
> then crashing out like it currently does) -- though I don't believe this
> case will affect you, as I believe your mailboxes are all at least
> version 10.
> * If the mailbox on either end of the replication contains any index
> records that do not have a GUID set, then the same will occur, and (in
> addition to the above error) a warning will be logged to syslog like:
> <mailbox>: missing guid for record <number> -- needs 'reconstruct
> So with this patch, you should be able to avoid these crashes, and also
> identify mailboxes that need "reconstruct -G" just by checking for the
> warning in syslog.
> Are you able to try this out?
I tried the patch and it did print the warnings on the replica. Unfortunately,
it looked like it was looping on the master (sync_client) and the updates that
could be made were not. I had to rollback to the dying version.
More information about the Info-cyrus