MySQL Enterprise Backup - BnR Scenarios

MySQL Enterprise Backup
Backup & Restore Scenarios
Keith Hollman
Principal Solution Architect
keith.hollman@oracle.com
Copyright – © 2020 Oracle

Safe harbor statement
The following is intended to outline our general product direction. It is intended for information
purposes only, and may not be incorporated into any contract. It is not a commitment to deliver
any material, code, or functionality, and should not be relied upon in making purchasing
decisions.
The development, release, timing, and pricing of any features or functionality described for
Oracle’s products may change and remains at the sole discretion of Oracle Corporation.

Introduction
Full Backups
Incremental & Optimistic backups
Restores
Real Use Cases & Tuning MEB
Program agenda
1
2
3
4
5

 Logical
 mysqlpump (5.7 upwards)
 A modern highly parallel data pump
 mysqldump
 Data Export and Import Wizard
 Part of MySQL Workbench
 Physical
 MySQL Enterprise Backup
(MEB)
One size does Not fit all “Use Cases”
- Pick the right tool(s) for the job(s)
Introduction
 OS Backups
 “Cold” File System Backups
 Snapshots
 For example LVM, other Filesystems
or HW based
 Continuous
 Replicas (MySQL Replication)
 Often with slave lag
 Binlog Tools
 Transportable Tablespaces

Why backups?
 Data is your most valuable IP. You have to protect it from loss
 Disaster Recovery
 Hardware, Software, Developer or DBA error
 Migration and Upgrades – Change Hardware
 Create replica’ s for HA setup
 Archival – requirements to keep data for X number of years
 Move chunks of data
 Setup Test Environments

Backup & Recovery can be trickier than it
appears
 Requires some forethought and planning
 How do you backup your critical production systems?
 While servers are performing critical business functions
 And downtime is not acceptable
 Where negative performance impacts are not acceptable
 Finding proper backup storage is critical

What you can use depends on what you
are backing up
 Size – A tiny table or a Massive Database
 Activity – Is the Database very busy or is it an inactive database
 Try not to overlap busy database periods with backups if possible
 For logical you might find “l get locking collisions”
 For physical the backup will be larger
 It collects data to make everything consistent – this takes space
 Recovery may take longer – it must apply the data to make consistent.
 Cost – Is the data in the database compressed?
 Most databases are highly compressible – however if your database
contains compressed cell data – recompressing won’t help and will slow
things down

Recovery
 How fast do you need to recover?
 Immediate
 Replication
 ASAP
 Physical is several orders of magnitude faster
 Doesn’t matter (its Archival)
 Then cost and size more of a factor
 Doesn’t matter (its Logical)
 Will be slower but flexibility is more important

Cost/Benefit
 Do the math
 Is it archived?
 Writing to a media manager or tape
 Writing to Cloud Storage
 Long term disk or other media cost
 Compression can save you $s

Full Backups

Backup options
 Like all backup options full, incremental, partial, etc. a full backup can be
done to disk, to image, to cloud (image), to tape (image).
 Backups can be converted from a previously backed up instance, without
connecting to the original instance:
 Convert an ‘on disk’ backup to an image backup (to disk, to tape, to cloud)
 Convert a tape, cloud or on disk image backup to a backup-dir ‘on-disk’
backup
 Once the backup has been executed, we can validate the contents.
 Additionally, irrespective of the backup options used like compression, the
contents can be listed.
 Adding --with-timestamp helps avoid overwriting previous backups.

Full backup
 There are various options available:
 To disk / datadir:
mysqlbackup -ubackup --socket=/var/lib/mysql/mysql.sock --backup-dir=/opt/mysql/backup/full backup
Using an existing backup image, without needing to connect to the instance:
mysqlbackup --backup-dir=/opt/mysql/backup/full_img2dir
--backup-image=/opt/mysql/backup/full_img/full_backup.img image-to-backup-dir
 To image (single file containing all backed up data):
mysqlbackup -ubackup --socket=/var/lib/mysql/mysql.sock --backup-dir=/opt/mysql/backup/full_img
--backup-image=full_backup.img backup-to-image
mysqlbackup -ubackup --socket=/var/lib/mysql/mysql.sock --backup-dir=/opt/mysql/backup/
--backup-image=full_backup.img --with-timestamp backup-to-image
Using an existing backup directory, without needing to connect to the instance:
mysqlbackup --backup-dir=/opt/mysql/backup/full --backup-image=full_backup.img --with-timestamp
backup-dir-to-image

Full backup (cont)
 To cloud (image):
mysqlbackup -ubackup --socket=/var/lib/mysql/mysql.sock
--cloud-service=openstack
--cloud-container=kh
--cloud-object=full_meb_backup.mbi
--cloud-user-id=Storage-mysqlsales:keith.hollman@oracle.com
--cloud-password=password
--cloud-tempauth-url=https://mysqlsales.storage.oraclecloud.com
--backup-dir=/home/vagrant/backup/cloud
--compress=true --backup-image=- backup-to-image
 To tape (image):
mysqlbackup -ubackup --socket=/var/lib/mysql/mysql.sock --sbt-lib-path=/usr/local/oracle/backup/lib/libobk.so
--backup-image=sbt:test1 --backup-dir =/home/vagrant/backup/sbttest backup-to-image
mysqlbackup -ubackup --socket=/var/lib/mysql/mysql.sock --sbt-lib-path=/usr/openv/netbackup/bin/libobk.so64
--backup-image=sbt:test2 --backup-dir =/home/vagrant/backup/sbttest backup-to-image
 Contents: Validating, listing
mysqlbackup --backup-image=/home/vagrant/backup/incre/incr_backup1.mbi validate
mysqlbackup --backup-image=/home/vagrant/backup/full/full_backup.img list-image

Partial Backups
 First of all:
https://dev.mysql.com/doc/mysql-enterprise-backup/4.1/en/partial.html
Typically, a partial backup is more difficult to restore than a full backup, because the backup
data might not include the necessary interrelated pieces to constitute a complete MySQL
instance. In particular, InnoDB tables have internal IDs and other data values that can only be
restored to the same instance, not a different MySQL server. Always fully test the recovery
procedure for any partial backups to understand the relevant procedures and restrictions.
 Depending on the need and environment requirements, partial backups vs
full-backups & partial restores have different capabilities.
 Options include backing up specific databases, tables, excluding tables from
backups, transportable tablespaces.
 Compress, encryption, with-timestamp, etc. options are all still valid.

Partial Backups
 Each partial backup explicitly uses --include-tables & --exclude-tables to
determine the subset of data we want to backup:
 All tables from “sakila” database:
--include-tables=^sakila.*$
 Everything except the tables whose name starts with ‘film’ in a database:
--exclude-tables=^sakila.film.*
 Just a single table:
--include-tables=^sakila.film$
 All tables, instance wide, whose name starts with ‘film’:
--include-tables=^*.film.*

Transportable Tablespaces
 This option can be used to transport tables from one instance to another or
to restore tables back into the same instance.
 The tables have to pre-exist in the instance for the restore to work correctly,
as the data dictionary needs to have knowledge of the tables.
use-tts={with-minimum-locking|with-full-locking}
 with-minimum-locking Hot copies of tables are done, and redo
 with-full-locking Tables locked in read-only mode. Without redo.
 Used together with --include-tables and --exclude-tables.
 Can’t be used for Incremental backups.

Time to back it up
 Full backup exercise
 To disk, to image, to cloud (w/ creating cloud container)
 To tape (no SBT-compatible library available? Review –sbt options.)
 Validate & List and some Admin & pointers…
 Partial backups (using ‘sakila’)
 A database schema
 Tables from a specific database starting with ‘film’
 Excluding tables from a specific database.
 Converting an existing database partial backup to a table-specific backup.
 A ‘simple’ single table backup.
Try it out!

Incremental &
Optimistic
Backups

 Incremental backups save time
and space.
 Only backup data changed since
last full or incremental backup.
 mysqlbackup --incremental
 Uses various options to measure
‘since last backup’:
start-lsn
incremental-base=history:last_backup
incremental-base=dir:/var/mysql/backup
By default, incremental backup also copies all non-InnoDB
data files and .frm files. To backup only InnoDB incremental
data, use the --only-innodb option along with --incremental
option.
Incremental backups are always taken in uncompressed
format.
There are two types of incremental backups.
The --incremental option specifies an incremental backup
where all pages in InnoDB datafiles modified since the given
LSN are copied to the backup.
The second method is invoked by the --incremental-with-
redo-log-only option, and it relies entirely on InnoDB log; no
InnoDB datafiles are copied at all, only redo log from the given
LSN to the current checkpoint. The redo-log-only incremental
backup is possible only when the log at start LSN is not yet
overwritten by newer log records in the circular InnoDB log.
For non-InnoDB tables and data incremental backups and full
backups behave in the same way.
Incremental Backups

Incremental backup / Optimistic
 There are 3 options:
 Start-lsn:
--incremental
--start-lsn=9513913
--backup-dir=/home/vagrant/backup/incre --backup-image=incr_backup1.mbi backup-to-image
 Using mysql.backup_history:
--incremental
--incremental-base=history:last_backup
--backup-dir=/home/vagrant/backup/incre --backup-image=incr_backup1.mbi backup-to-image
 Using backup-dir instead:
mysqlbackup --defaults-file=/etc/my.cnf
--incremental
--incremental-base=dir:/var/mysql/backup/22MAR
--incremental-backup-dir=/home/admin/temp_dir
--backup-image=incr_backup1.mbi backup-to-image

 We can also take an incremental backup that does an optimistic scan of
changed blocks in innodb datafiles.
 Careful: This is NOT an optimistic backup but a faster incremental backup:
https://dev.mysql.com/doc/mysql-enterprise-backup/4.1/en/backup-incremental-
options.html#option_meb_incremental
--incremental=optimistic
--start-lsn=3032459
--backup-dir=/home/vagrant/backup/temp_dir
--backup-image=incr_backup2.mbi --with-timestamp
backup-to-image
--incremental=optimistic
--incremental-base=history:last_backup
--backup-dir=/opt/mysql/backup/partial/incr_opt
--backup-image=partial_backup_film_incr_opt.img backup-to-image

 Large instances can take time to backup but there can also be inactive tables or
some very specific hot tables. Optimistic backups are done in 2 phases:
Optimistic and Normal.
 The Optimistic phase doesn’t backup redo, undo nor system information for inactive
tables as they’re not expected to change and therefore doesn’t lock the instance whilst
backing up.
 Normal phase considers that all tables not backed up in the Optimistic phase, are “busy
tables” and therefore backs them up as normal.
 There are various options available:
 optimistic-time considers that all tables that have been modified since this time as busy
and will be backed up normally. And those unmodified, will be backed up as Optimistic.
 optimistic-busy-tables considers the tables identified as busy, and hence will be
backed up in the Normal fashion.
 If both options are specified, tables identified as optimistic-busy-tables will be backed
up as normal even if they haven’t been modified since the optimistic-time.

 Examples:
 optimistic-time=YYMMDDHHMMSS
mysqlbackup --defaults-file=/etc/my.cnf --optimistic-time=180511020000 backup-to-image
mysqlbackup --defaults-file=/etc/my.cnf --optimistic-time=now backup-to-image
 optimistic-busy-tables="^sakila.film.*"
mysqlbackup --defaults-file=/etc/my.cnf --optimistic-busy-tables="^sakila.film.*" backup
 optimistic-time & optimistic-busy-tables
mysqlbackup --defaults-file=/etc/my.cnf --optimistic-busy-tables="^sakila.film.*" --optimistic-
time=180511020000 backup
 Full Optimistic backups can be used in conjunction with Incremental
optimistic backups, but not run together. i.e. Run a Full Optimistic backup on
Sunday and then 6 consecutive days of Incremental optimistic backups.
 optimistic-time can’t be used in the same mysqlbackup command as
incremental=optimistic.

 Incremental:
 Find the End LSN from the last Full.
 Run an incremental backup, with LSN, without LSN & no LSN & w/o
backup_history.
 Feel free to change the data in between incremental backups.
 Optimistic:
 Consider tables from a specific time only as ‘busy’.
 Consider all tables as of backup execution as busy.
 Specify a set of known tables as busy.
 Take an optimistic backup of selected busy tables from a specific time.
Try it out!

Restores

Restore
 As it all depends on the situation we’re trying to recover from,
which implies that depending on the backup type we have, we
will want to restore in a specific manner.
 Remember that we can convert available backups from & to on-disk,
image, cloud & tape.
 eg. We may only have a full backup with incrementals on disk, but want to
do a partial recovery PITR of a deleted table.
 The copy-back option.
 copy-back: For a backup-dir restore only.
 copy-back-and-apply-log: Copies the backup to disk and applies the logs
that were generated from changes made whilst the backup was running.

Restore
 Over-writing the lost instance directly:
mysqlbackup -–defaults-file=my.cnf --datadir=/opt/mysql/restore/full copy-back-and-apply-log
 From disk, to a different path / datadir:
mysqlbackup --defaults-file=/etc/my.cnf --backup-dir=/opt/mysql/backup/full
--datadir=/opt/mysql/restore/full_restore copy-back-and-apply-log
 From image:
--backup-dir=/opt/mysql/backup/full_img --backup-image=full_backup.img
--datadir=/opt/mysql/restore/full_restore_img copy-back-and-apply-log
 From cloud:
mysqlbackup --cloud-service=openstack --cloud-container=kh
--cloud-user-id=Storage-scmsyqlteam:keith.hollman@oracle.com --cloud-password=password
--cloud-ca-info=/etc/ssl/certs/ca-bundle.crt --cloud-tempauth-url=https://em2.storage.oraclecloud.com
--cloud-trace=1 --cloud-object=56Backup.mbi --datadir=/opt/mysql/restore/full_restore_cld
--backup-dir=/u01/backup/56backup --backup-image=- copy-back-and-apply-log

Restore Options
 A partial restore, using include or exclude:
--backup-dir=/opt/mysql/backup/full_img --backup-image=full_backup.img
--datadir=/opt/mysql/restore/full_restore_img
--include-tables=^sakila.film.*$ --exclude-tables=^sakila.film$ copy-back-and-apply-log
 A partial restore using “extract”:
 Extract a table, database or list of each to the same or different datadir.
mysqlbackup --cloud-service=openstack --cloud-container=MEB_wkshp_test
--cloud-user-id=Storage-mysqlsales:keith.hollman@oracle.com --cloud-password=password
--cloud-ca-info=/etc/ssl/certs/ca-bundle.crt
--cloud-tempauth-url=https://mysqlsales.storage.oraclecloud.com
--cloud-trace=1 --cloud-object=full_meb_backup.mbi --backup-image=-
--src-entry=datadir/nexus --dst-entry=/u01/data/mysql/nexus extract
 This can obviously be used with any image/cloud restore.

Restore Options (cont)
 From tape:
 Restore should be done in the same way as for MMSs described before:
restore the image to a directory first, then apply-log and finally copy-
back.
 Restore from a Transportable Tablespace backup and rename the
table:
 need to fulfill use-tts requirements & be aware of constraints with unique
names.
--backup-dir=/opt/mysql/backup/partial_img_tts --backup-image=partial_tts_backup.img
--include-tables=^nexus.replicant$
--rename='nexus.replicant to sakila.stars' copy-back-and-apply-log

Restore Point In Time
 In order to recover up until a specific Point In Time, we’ll need:
 The latest Full backup.
 The Incremental backups, if required.
 The Binary logs that hold all DML since the last incremental up until the
‘recovery need’.
 mysqlbinlog utility.
 The “End LSN” from the last incremental backup.
 The date & time for recovery to stop at.

Restore examples
 Full restore on-top-of / replacing a complete datadir / instance.
 Do we need to force overwriting?
 Clone the currently working instance to the same server but in
different directories.
 Find out what’s in an image backup, and do a partial restore..
 .. Or even just extract something.
 And for a , rename a table, from a transportable tablespace
backup!
 For super heros PITR…
Try it out!

Real Use Cases
& Tuning MEB

Real use cases
 Restore for Replication / Cloning
 InnoDB Cluster or any replication scenario: For a node restore, once
restore has been done, we’ll need to run “reset master;” on the slave and
then run:
cat /opt/mysql/backup/full/meta/backup_gtid_executed.sql
SET @@GLOBAL.GTID_PURGED='31ee1d75-537c-11e8-bd31-080027b46af9:1-34';
 Migration between MySQL Server versions
 MEB versions can help here, to also migrate from on-premise to cloud.
 Encryption
 Using a key store like OKV or similar, employing the following options
when running a backup or restoring: --encrypt / --decrypt / --key / --key-file

Real use cases
 Compression
 In order to sabe space, but also be able to list the contents of a MEB-
compressed backup, we can use different compression options,
algorhithms & levels depending on need (eg. speed vs space): --compress /
--uncompress, --compress-method & --compress-level
 Restoring & renaming a table
 Whether from Full&Incremental backups or TTS backups, many options
are available to restore a dropped table in order to get the data back into
the system.
 MySQL NDB Cluster
 Please don’t get confused, but NDBCLUSTER tables can NOT be backed
up using MEB.

Performance Tuning MEB
 --read-threads=#(3, 1-15) applies to copy-back, extract and backup
 --process-threads=#(3, 1-15) applies to extract and backup. apply-log only gets 1
 --write-threads=#(3, 1-15) applies only to copy-back, extract and backup.
 --memory-limit=#(300) by default, caps the number of 16MB buffers to 18
 --number-of-buffers=#((Rt+Wt+Pt)+max(Rt, Wt, Pt)) calculated , max calc 60 buffers need
memory-limit=960
 Set Rt and Wt to the number of spindles
 Pt are a lower impact, but I would tend to 50% of Rt+Wt or less
 Cause no swapping or CPU spike in tuning
 Buffers can be automatically set, but will be blocked if memory-limit is too
loaded

Helpful Parameters
 Potentially:
 --on-disk-full={abort|abort_and_remove|warn} a handy way of avoiding knock-on
effects.
 --skip-unused-pages not as useful as you might think. The empty pages are
returned during the next apply-log.
 --exec-when-locked="utility arg1 arg2 ..." run a script during the lock phase, say to
backup a memory table.
 --only-innodb to esure exclusive innodb data being backed up.
 --show-progress in order to enable progress reporting of backup execution.
 --innodb_purge_batch_size (mysqld / my.cnf) Reduce to 1, run backup and then
return to 20. Run command before & after backup execution.

References
 MySQL Enterprise Backup: Product Information
 https://www.mysql.com/products/enterprise/backup.html
 MySQL Enterprise Backup Team Blog
 https://blogs.oracle.com/mysqlenterprisebackup/
 MySQL Enterprise Backup: Documentation
 https://dev.mysql.com/doc/mysql-enterprise-backup/8.0/en/
 How Do I get it
 https://edelivery.oracle.com
 Some Best Pratices:
 https://mysql.wisborg.dk/2019/03/31/mysql-backup-best-practices/

Get Started Today!
MySQL Enterprise Edition Trial Contact a MySQL Sales Rep
http://www.mysql.com/trials/ http://www.mysql.com/about/contact/

Questions?
keith.hollman@oracle.com

Thank you
Keith Hollman
Principal Solution Architect
MySQL

MySQL Enterprise Backup - BnR Scenarios

More Related Content

MySQL Enterprise Backup - BnR Scenarios