Pantek Library
Hosting Provided By
CybrHost
High Speed Hosting

RE: Replication stopping with exactly the same characteristics as [Jesse]

From: Rick James <rjames(at)yahoo-inc.com>
Date: Mon Oct 29 2007 - 13:25:55 EDT


The malloc/free seems like a recipe for memory fragmentation and sluggishness. Can't it at least reuse a static area for small pieces (say, < 1M)?

> -----Original Message-----
> From: Mark Callaghan [mailto:mcallaghan@google.com]
> Sent: Monday, October 29, 2007 8:17 AM
> To: Kieffer, Tom
> Cc: replication@lists.mysql.com
> Subject: Re: Replication stopping with exactly the same
> characteristics as [Jesse]
>
> We had errors similar to this. They occurred because the
> master got memory
> allocation errors while trying to copy a large replication
> event to the
> slave. The master did not log an error for this, nor did it notice the
> memory allocation error. The slave got the truncation error
> and replication
> stopped. The problems on the master have been fixed in recent
> 5.0 branches.
>
> Large replication events are not streamed to slaves. They
> require contiguous
> memory allocation. Binlog dump threads on the master call
> malloc/free for
> every replication event copied to a slave.
>
> On 10/29/07, Kieffer, Tom <Tom.Kieffer@ds-plan.com> wrote:
> >
> > Hello,
> >
> >
> >
> > just came to the same problem than Jesse. Replication is
> stopping without
> > any
> > visible reason. Slave stays at "Waiting for master to send
> event". MySQL
> > writes to the error log:
> > Slave SQL thread exiting, replication stopped in log 'xxx'
> at position
> > yyy.
> > I have the "Data truncated error" ignored. Never understood
> why an entry
> > is
> > accepted on the master but throws a "Data truncated" error
> on the slave.
> > But
> > if replication stopped even with ignore_error this parameter doesn't
> > really
> > make sense.
> > Until now i couldn't figure out any solution whatsoever. I
> just issue a
> > "Start Slave" and replication continues where it stopped.
> > The data is not yet critical but may become so in the near
> future so i'm
> > worrying somewhat about the replication behaviour.
> >
> >
> >
> >
> >
> >
> >
> > Tom Kieffer
> >
> >
> >
> >
> >
> >
> >
>
>
> --
> Mark Callaghan
> mcallaghan@google.com
>

-- 
MySQL Replication Mailing List
For list archives: 
http://lists.mysql.com/replication
To unsubscribe:    
http://lists.mysql.com/replication?unsub=lists@pantek.com
Received on Mon Oct 29 13:26:23 2007

This archive was generated by hypermail 2.1.8 : Fri Jul 04 2008 - 00:24:09 EDT


Contact Us  Legal Notices  Order Services Online 
Pantek Home  Privacy Policy  IT news  Site Map  Pantek Library