Percona is glad to announce the release candidate of Percona XtraBackup 8.0-3-rc1 on October 31 2018. You can download it from our download site and apt and yum repositories.
This is a Release Candidate quality release and
it is not intended for
production. If you want a high quality, Generally
Available release, use the current stable version (the
most recent …
The second alpha build of Percona XtraBackup 8.0.2 is now available in the Percona experimental software repositories.
Note that, due to the new MySQL redo log and data dictionary formats, the Percona XtraBackup 8.0.x versions will only be compatible with MySQL 8.0.x and Percona Server for MySQL 8.0.x. This release supports backing up Percona Server 8.0 Alpha.
For experimental migrations from earlier database server versions, you will need to backup and restore and using XtraBackup 2.4 and then use mysql_upgrade from MySQL 8.0.x
PXB 8.0.2 alpha is available for the following …
[Read more]Experimental Build of Percona XtraBackup 8.0 released
An experimental alpha version of Percona XtraBackup 8.0.1 is now available in the Percona experimental software repositories.
A few things to note about this release:
In this blog post, I’ll look at point-in-time recovery (PITR) options for MySQL, MariaDB and Percona Server for MySQL.
It is a common good practice to extend data safety by having additional measures apart from regular data backups, such as delayed slaves and binary log backups. These two options provide the ability to restore the data to any given point in time, or just revert from some bad accidents. These methods have their limitations of course: delayed slaves only help if a deadly mistake is noticed fast enough, while full point-in-time recovery (PITR) requires the last full backup and binary …
[Read more]In this blog post, we’ll look at options for migrating database charsets to utf8mb4.
Migrating charsets, in my opinion, is one of the most tedious tasks in a DBA’s life. There are so many things involved that can screw up our data, making it work is always hard. Sometimes what seems like a trivial task can become a nightmare very easily, and keeps us working for longer than expected.
I’ve recently worked on a case that challenged me with lots of tests due to some existing schema designs that made InnoDB suffer. I’ve decided to write this post to put together some definitive guide to enact charset conversion with minimal downtime and pain.
The ability to restore MySQL logical backups is a significant part of disaster recovery procedures. It’s a last line of defense.
Even if you lost all data from a production server, physical backups (data files snapshot created with an offline copy or with Percona XtraBackup) could show the same internal database structure corruption as in production data. Backups in a simple plain text format allow you to avoid such corruptions and migrate between database formats (e.g., during a software upgrade and downgrade), or even help with migration from completely different database solution.
Unfortunately, the restore speed for logical backups is usually bad, and for a big database it could require days …
[Read more]In this blog, I’ll look at how to do MySQL point in time recovery (PITR) correctly.
Sometimes we need to restore from a backup, and then replay the transactions that happened after the backup was taken. This is a common procedure in most disaster recovery plans, when for example you accidentally drop a table/database or run an update/delete without the “where” clause and lose data.
The usual way is to get a copy of your binlogs and use mysqlbinlog to replay those transactions. But this approach has many pitfalls that can make the whole PITR process a nightmare. Some examples:
Hello again! On August 16, we delivered a webinar on MySQL backups. As always, we’ve had a number of interesting questions. Some of them we’ve answered on the webinar, but we’d like to share some of them here in writing.
What is the best way to maintain daily full backups, but selective restores omitting certain archive tables?
There are several ways this can be done, listed below (though not necessarily limited to the following):
Join Percona’s, Technical Services Manager, Jervin Real as he presents Lock, Stock and Backup: Data Guaranteed on Wednesday, August 16, 2017 at 7:00 am PDT / 10:00 am EDT (UTC-7).
Backups are crucial in a world where data is digital and uptime is revenue. Environments are no longer bound to traditional data centers, and span multiple cloud providers and many heterogeneous environments. We need bulletproof backups and impeccable recovery processes. This talk aims to answer …
[Read more]This blog discusses newly added options for Percona XtraBackup 2.4.8 and how they can impact your database backups.
To avoid issues with MySQL 5.7 skipping the redo log for DDL, Percona XtraBackup has implemented three new options (
xtrabackup --lock-ddl
,
xtrabackup --lock-ddl-timeout
,
xtrabackup --lock-ddl-per-table
) that can be used to place MDL locks on tables while they are copied.
So why we need those options? Let’s discuss the process used to get there.
Originally, we found problems while running DDLs: Percona XtraBackup produced corrupted backups as described in two reports:
