Hi Rick
Both master and slave have same hardware configuration. The queries are not run parallel
in master/slave. I agree there is only one thread running on the slave for the updates.
Thanks
Revathi R
--- On Tue, 4/3/12, Rick James <rjames@stripped> wrote:
> From: Rick James <rjames@stripped>
> Subject: Re: Seconds Behind Master increasing in slave
> To: replication@stripped
> Date: Tuesday, April 3, 2012, 3:14 AM
> * If the Slave is less powerful than
> the Master (eg no RAID vs RAID),
> hardware can contribute to the long delays.
> * If the queries on the Master are done in
> parallel,... Replication
> serializes the queries, thereby taking more elapsed time on
> the Slave.
> (Note: There is only one Update running on the slave,
> no matter how
> many are queued up.)
>
> On 4/2/12 1:58 PM, Arthur Fuller wrote:
> > The immediate suspect is that single update
> statement. Is it a massive
> > batch-update? If so, is it possible to break it down
> into several smaller
> > updates, run successively?
> >
> > Arthur
> >
> > On Mon, Apr 2, 2012 at 4:26 PM, David
Lerer<DLerer@stripped>
> wrote:
> >
> >> How long did the one update statement run?
> >> (A slow update, even if it is a single transaction,
> can slow down
> >> replication.
> >> David.
> >>
> >> -----Original Message-----
> >> From: Revathi Rangachari [mailto:masrrev@stripped]
> >> Sent: Monday, April 02, 2012 3:42 PM
> >> To: replication@stripped
> >> Subject: Seconds Behind Master increasing in slave
> >>
> >> Hi
> >>
> >> We have a master-slave setup. The slave acts
> only as a replicate and does
> >> not cater to any client requests.
> >>
> >> Over the last 24 hours there has been more than 4
> to 6 hours delay in the
> >> replication. The CPU, IO, memory usage all
> seem to be under control. I
> >> changed the SET GLOBAL
> innodb_flush_log_at_trx_commit = 0 ;
> >>
> >> The slave sql and io threads are running.
> >> show processlist shows only one update statement on
> a table.
> >>
> >> In spite of all this the slave still lags behind in
> replication by 5 hours.
> >>
> >> Any suggestion to improve the replication
> performance is highly
> >> appreciated.
> >>
> >> Thanks
> >> Revathi R
> >>
> >>
>
> --
> Rick James - MySQL Geek
>
>
> --
> MySQL Replication Mailing List
> For list archives: http://lists.mysql.com/replication
> To unsubscribe: http://lists.mysql.com/replication
>
>
