TokuDBtips:MySQLbackups_MySQL

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了TokuDBtips:MySQLbackups_MySQL，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含4854字，纯文字阅读大概需要7分钟。

内容图文

• Getting to know TokuDB for MySQL
• Percona Server with TokuDB: Packing 15TB into local SSDs

So, yes, we are using Percona Server + TokuDB as a main storage engine inPercona Cloud Toolsto store timeseries data.

And, yes, Percona Server + TokuDB is available GAPercona Server 5.6.19-67.0 with TokuDB (GA).

Just having good performance is not enough to make it into production; there are also operational questions and one such question is about backups. I want to explain how we do backups for Percona Server + TokuDB inPercona Cloud Tools.

I should say up front, that weDO NOThave support for TokuDB inPercona XtraBackup. TokuDB internals are significantly different from InnoDB/XtraDB, so it will be a major project to add this to Percona XtraBackup and we do not have any plans at the moment to work on this.

It does not mean that TokuDB users do not have options for backups. There is Tokutek Hot back-up, included in theTokutek Enterpise Subscription. And there is a method we use inPercona Cloud Tools: LVM Backups. We usemylvmbackupscripts for this task and it works fairly well for us.

There is however some gotchas to be aware. If you understand an LVM backups mechanic, this is basically a managed crash recovery process when you restore from a backup.

Now we need to go in a little detail for TokuDB. To support transactions that involve both TokuDB and InnoDB engines, TokuDB uses a two-phase commit mechanism in MySQL. When involved, the two-phase commit requires binary logs presented for a proper recovery procedures.

But now we need to take a look at how we setup a binary log in Percona Cloud Tools. We used SSD for the main data storage (LVM partition is here) and we use a Hardware RAID1 over two hard-drives for binary logs. We choose this setup as we care about SSD lifetime. In write-intensive workloads, binary logs will produce a lot of write operations and in our calculation we will just burn these SSDs, so we have to store them on something less expensive.

So the problem there is that when we take an LVM snapshot over main storage, we do not have a consistent view of binary logs(although it is possible to modify backup scripts to copy the current binary log under FLUSH TABLES WITH READ LOCK operation, this is probably what we will do next). But binary logs are needed for recovery, without them we face these kind of errors during restoring from backup:

2014-DD-MM 02:15:16 16414 [Note] Found 1 prepared transaction(s) in TokuDB2014-DD-MM 02:15:16 16414 [ERROR] Found 1 prepared transactions! It means that mysqld was not shut down properly last time and critical recovery information (last binlog or tc.log file) was manually deleted after a crash. You have to start mysqld with --tc-heuristic-recover switch to commit or rollback pending transactions.2014-DD-MM 02:15:16 16414 [ERROR] Aborting

The error message actually hints a way out. Unfortunately it seems that we are the first ones to have ever tried this option, astc-heuristic-recoveristotally broken in current MySQLand not supposed to work… and it would be noticed if someone really tried it before us(which gives me an impression that Oracle/MySQL never properly tested it, but that is a different story).

We will fix this inPercona Server soon.

So the way to handle a recovery from LVM backup without binary logs is to start mysqld with –tc-heuristic-recover switch(unfortunately I did not figure out yet, should it be COMMIT or ROLLBACK value, hehe).

The proper way to use LVM backup is to have a corresponding binary log file, like I said it will require a modification to mylvmbackup script.

I should say this is not the only way we do backups in Percona Cloud Tools. In this project we usePercona Backup Serviceprovided by thePercona Managed Services team, and our team also usesmydumperto perform a logical backup of data.

While it works acceptably to backup hundreds of gigabytes worth of data(it is just a sequential scan, which should be easy for TokuDB), the full recovery is painful and takes unacceptably long. So mydumper backup(recovery)will be used if we ever need to perform a fine-grained recovery(i.e only small amount of specific tables).

So I hope this tip is useful if you are looking for info about how to do backups for TokuDB.

内容总结

以上是互联网集市为您收集整理的TokuDBtips:MySQLbackups_MySQL全部内容，希望文章能够帮你解决TokuDBtips:MySQLbackups_MySQL所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端