Comments on: The MySQL Clone Wars: Plugin vs. Percona XtraBackup

By: Pep Pla

Pep Pla — Fri, 22 Jan 2021 15:16:19 +0000

In reply to banpei.

Hi,

I also tried to know what algorithm uses the clone plugin for compression. Regarding the low bandwidth test, I think it is not only bandwidth, but also latency what impacts streaming. Did you consider using any udp based transfer utility rather than using tcp based ones? I made tests and, in lan environments, it does not make any difference.

By: Pep Pla

Pep Pla — Fri, 22 Jan 2021 15:10:20 +0000

In reply to Edwin Wang.

Hi Edwin,

Current version of clone plugin does not support incremental cloning. I guess you could implement some sort of incremental cloning using clone plugin + binlog point in time recovery… or using the incremental feature of xtrabackup.

Keep in mind that you can’t apply incremental backups once your database has been opened. A better approach could involve filesystem snapshots.

Actually, it depends on what you want to do with “incremental cloning”.

By: banpei

banpei — Thu, 21 Jan 2021 08:51:11 +0000

Some time ago I did a couple of benchmarks for SSTs in Galera, where I was trying to optimize for cross-region SSTs and get them over as fast as possible. My conclusion was that the most determining factor is the compression algorithm. Xtrabackup uses Qpress (LZ4 based algorithm) by default to compress and this is one of the least CPU demanding algorithms. I wasn’t able to determine which compression algorithm MySQL Clone uses, but if it’s the Zstd algorithm it’s definitely more CPU bound. You can find my findings here: https://mysqlquicksand.wordpress.com/2019/09/27/putting-galera-sst-compression-on-the-benchmark/ or in my presentation: https://www.percona.com/sites/default/files/ple19-slides/day2-am/benchmarking-is-never-optional.pdf

Also the lowest bandwidth tier of 500mbit you chose is quite high for cross-region throughput: our limit between our DC and GCP was 300mbit the maximum we could achieve. It would be more interesting to have more benchmarks with lower bandwidth transfers.

By: Edwin Wang

Edwin Wang — Thu, 21 Jan 2021 00:09:05 +0000

Hey Pep, I am more interested in the incremental backup VS incremental cloning. I mean do you happen to verify the ability for the plugins as of incremental cloning? Thanks

By: Pep Pla

Pep Pla — Wed, 20 Jan 2021 09:51:43 +0000

In reply to lefred.

Hi,

I was not aware of that limitation. I haven’t been able to find any reference in the documentation to this behavior (5%). The documentation says that “During a cloning operation, the number of threads increases incrementally toward a target of double the current thread count”. I guess this limit is overridden using clone_max_concurrency and disabling autotune.

IMHO it is a bit counter intuitive to measure the number of threads (user threads? running? connected? background?… my recently installed 8.0 reports 44 threads in ps.threads…) to know how many threads can be allocated for a transfer. This could impose a penalty on servers designated as clone sources only, or clone processes that take place during low activity windows.

If you can share more information with me about this (and compression), I would be pleased to write: Episode II Attack of the MySQL Clones.

Cheers

By: lefred

lefred — Wed, 20 Jan 2021 07:57:00 +0000

Hi Pep Pla 😉

Thank you for the interest you bring to MySQL clone.

However, there is one point not covered in your blog post, maybe this is not clear, but clone has been developed to have not more than approximately 5% impact on user threads and therefor not optimized on idle servers.

I don’t see in your tests if there was load on the servers. If not, this is like a file copy over the net.

Cheers,