performance of innobackupex - streaming vs. local snapshot
David Stainton
Is anyone else noticing that it is much more efficient to use
innobackupex to write a snapshot locally instead
of streaming over the network to another server?
Not only is the local snapshot quicker to create... but it also lags
the slave far less.
That is, when using innobackupex to create a local snapshot on the
slave, the slave only falls
behind in replication a little. However when streaming over the
network using innobackupex like this or equivalent:
innobackupex-1.5.1 --stream=tar ./ | pv | ssh root@slave2 'tar -C
/data -ixvf -'
the slave falls significantly behind in replication... This makes it
prohibitively expensive to use the streaming mode.
Does anyone actually use the innobackupex streaming mode in production?
I am curious if any percona users have a similar or differently
experience regarding innobackupex!
Does anyone have any idea why I am seeing this lose in performance?
David
David Stainton
Yeah that sounds about right... I'll soon get around to testing and
see if it is the ethernet interface saturation which is causing the
slave replication lag.
Cheers,
David
On Thu, Jan 6, 2011 at 4:52 PM, Justin Swanhart <gree...@gmail.com> wrote:
> Hi David,
>
> Perhaps you are saturating your network connection with the streaming backup?
>
> --Justin
>> --
>> You received this message because you are subscribed to the Google Groups "Percona Discussion" group.
>> To post to this group, send email to percona-d...@googlegroups.com.
>> To unsubscribe from this group, send email to percona-discuss...@googlegroups.com.
>> For more options, visit this group at http://groups.google.com/group/percona-discussion?hl=en.
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups "Percona Discussion" group.
> To post to this group, send email to percona-d...@googlegroups.com.
> To unsubscribe from this group, send email to percona-discuss...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/percona-discussion?hl=en.
>
>
Vadim Tkachenko
Another possible reason could that tar4ibd used for stream is eating
some CPU, as it
does additional checksums calculation.
We build xtrabackup 1.5 with -O3 option, that may help in this case.
--
Vadim Tkachenko, CTO, Percona Inc.
Phone +1-888-401-3403, Skype: vadimtk153
Schedule meeting: http://tungle.me/VadimTkachenko
David Stainton
Yes it does appear to be CPU bound.
One CPU core is almost 100% utilized most of the time.
Mainly utilized by tar4ibd and ssh...
We use gigabit ethernet... and the transfer rate is about 50MB per second...
We could expect to get perhaps twice that throughput so I don't think
it is network bound.
Obviously this situation could be improved if we replaced ssh with netcat...
But then we'd only have TCP's relatively weak checksum to guarantee
data integrity
across the network.
In my recent test, the mysql slave did not fall behind in replication.
I'll have to test this in a different shard that gets more writes.
David
Robin Bowes
> Hi,
>
> Yes it does appear to be CPU bound.
> One CPU core is almost 100% utilized most of the time.
> Mainly utilized by tar4ibd and ssh...
>
> We use gigabit ethernet... and the transfer rate is about 50MB per second...
> We could expect to get perhaps twice that throughput so I don't think
> it is network bound.
>
> Obviously this situation could be improved if we replaced ssh with netcat...
> But then we'd only have TCP's relatively weak checksum to guarantee
> data integrity
> across the network.
>
> In my recent test, the mysql slave did not fall behind in replication.
> I'll have to test this in a different shard that gets more writes.
Are you using any compression? I found that gzip used a lot of CPU
comnpared to lzop.
I also use a ssh with a less cpu-intensive cipher, eg:
-c blowfish
R.
--
"Feed that ego and you starve the soul" - Colonel J.D. Wilkes
http://www.theshackshakers.com/