You are here

Recovery

Download Backup/Recovery Manager

Undefined

FromDual Backup and Recovery Manager for MySQL and MariaDB

The fromdual_brman is an easy to use interface to make Backup, Restore and Point-in-Time-Recovery for MySQL, Galera Cluster, MariaDB and Percona Server. Integrates mysqldump, mysql, xtrabackup and mysqlbackup (MySQL Enterprise Backup).

MySQL table Point-in-Time-Recovery from mysqldump backup

Sometimes we face the situation where we have a full MySQL database backup done with mysqldump and then we have to restore and recover just one single table out of our huge mysqldump file.
Further our mysqldump backup was taken hours ago so we want to recover all the changes on that table since our backup was taken up to the end.

In this blog article we cover all the steps needed to achieve this goal for MySQL and MariaDB.

FromDual Backup Manager for MySQL 1.2.1 has been released

FromDual has the pleasure to announce the release of the new version 1.2.1 of the popular Backup Manager for MySQL and MariaDB (fromdual_bman).

You can download the FromDual Backup Manager from here.

Get rid of wrongly deleted InnoDB tables

Taxonomy upgrade extras: 

Precaution: Before you try this out on your production system do a BACKUP first! FromDual Backup Manager can help you with this.

Situation

A MySQL user has delete its InnoDB table files for example like this:

shell> rm -f $datadir/test/test.*

Analysis

We do some analysis first:

Backup Manager for MySQL, MariaDB and Percona Server (mysql_bman)

About

The MySQL Backup Manager (mysql_bman) is a wrapper script for standard MySQL backup tools. The Problem with MySQL backup tools is, that they have many options and thus are overcomplicated and errors are easy made.

mysql_bman has the intention to make backups for MySQL easier and technically correct. This means it should per default not allow non-consistent backups or complain if some functions or parameters are used in the wrong way to guarantee proper backups.

Privileges of MySQL backup user for mysqldump

Taxonomy upgrade extras: 

Some MySQL customers do not want to use the root user for mysqldump backups. For this user you have to grant the following minimal MySQL privileges:

mysqldump --single-transaction (InnoDB)

CREATE USER 'backup'@'localhost' IDENTIFIED BY 'secret';
GRANT SELECT, SHOW VIEW, RELOAD, REPLICATION CLIENT, EVENT, TRIGGER ON *.* TO 'backup'@'localhost';

mysqldump --lock-all-tables (MyISAM)

GRANT LOCK TABLES ON *.* TO 'backup'@'localhost';

If we missed a privilege please let us know.

To zip, or not to zip, that is the question

Taxonomy upgrade extras: 

Abstract: In this article we have a look at the compression options of common zipping tools and its impact on the size of the compressed files and the compression time. Further we look at the new parallel zip tools which make use of several cores.

MySQL Restore and Recovery methods

Undefined

Backup is for sissies! Let's have a look what we can do when we are not a sissy...

First of all: Your life is much easier when you have a proper backup process implemented and verified the restore procedure of your MySQL database.

But what if you have no backup in place and did a DROP TABLE. What shall we do?

We assume our data we just dropped are located on the following device:

FromDual Download

Undefined

FromDual provides software for operating MySQL, Galera Cluster, MariaDB and Percona Server.

FromDual will offer standard RPM and DEB repositories soon...

Use our software selector or choose direct links from the menu on the left.

Galera Cluster for MySQL

Highly-Available (HA) synchronous real multi-Master Replication Cluster for MySQL. Today the state of the art MySQL HA solution.

Which table is hit by an InnoDB page corruption?

InnoDB is known to have crash-recovery capabilities and thus is called a crash safe storage engine (in contrary to MyISAM). Never the less under certain circumstances it seems like InnoDB pages can get corrupt during a crash and then a manual crash-recovery is needed.

Can you trust your MySQL backup?

Taxonomy upgrade extras: 

Today a customer with corrupted data files showed up. When we enquired a bit more he told us that he had a broken I/O controller. This is one of the worst things which can happen to you!

The reason is the following: When a I/O controller starts to die it often does not happen immediately. The controller dies slowly producing more and more corrupt data. When you just write data without checking or reading them it can take days or even weeks until you discover the problem.

MySQL Cluster restore

Recently the question came up if it is faster to restore a MySQL cluster when all nodes are up or only ONE node from each node group during restore.

The answer from our gurus was: All nodes up during restore! I wanted to find out why. So I set up the following cluster and started to measure:

MySQL Cluster set up

Cluster set-up

Subscribe to RSS - Recovery