NetVault Plug-in for MySQL 4.4

Incremental and Differential Backups on the slave server will require that you enable the “--log-slave-updates” option in MySQL. This option tells the slave to log the updates performed by its SQL thread to its own Binary Log. For this option to work, the slave must also be started with the “--log-bin” option to enable Binary Logging. Normally, this option is used to chain replication servers; however, it can also be used for Binary Log backups enabling PIT Recovery of a replicated environment without the complications of purging Binary Logs on the master server before they have been applied to the slaves.

Replication configuration backups

Using the Relay Log Index Path option, you can specify the full path name to the Relay Log Index file to include it in backups. By default, the status files, “master.info” and “relay-log.info,” reside in the same location. If you use the Relay Log Index Path option and the default file names and locations are retained, all these files are backed up and restored automatically by the plug-in for a slave replication server.

Restoring replication servers

You can use Full, Incremental, and Differential Backups from the MySQL Replication Slave Instance to perform disaster recovery for the MySQL Replication Master Instance. After the Master Instance has been restored, the DBA can use the same set of backups to restore each Slave Instance to the same level as the Master Instance, and then restart Replication, or the DBA can reinitialize the Slaves Instances using other initialization methods provided in the MySQL Reference Guide.

You can use Individual Database/Table backups from both the master and the slave to restore individual databases/tables to the master. If a DBA wants to resynchronize an individual table or database on a slave, Dell recommends that the DBA use MySQL’s Replication process for resynchronization instead of restoring to the slave and then trying to get the slave back in sync with the master.

Using the plug-inin a Failover Cluster environment

•

MySQL Server Failover Clustering – an overview

•

Installing the plug-in

•

Licensing the plug-in

•

Configuring the plug-in

•

Backing up data

•

Restoring data

MySQL Server Failover Clustering – an overview

MySQL Failover Clustering (Active/Passive) is designed to provide high-availability for an entire MySQL Server instance. For example, you can configure a MySQL Server instance on one node of a failover cluster to fail over to any other node in the cluster during a hardware failure, OS failure, or a planned upgrade.

A failover cluster is a combination of one or more nodes (hosts) with one or more shared disks. Various resources hosted by the nodes, such as IP, shared storage, and an application (MySQL in this case) can be grouped together to create a Clustered Service. A Virtual Service appears on the network as if it were a single computer running an application, but provides failover from one node to another node if the current node becomes unavailable.


	IMPORTANT: In NetVault Backup terminology, a clustered service is accessed by a Virtual Client. The references to Virtual Client in Plug‑in for MySQL are basically references to the Clustered Service in the MySQL Server Failover Cluster environment.