MySQL Enterprise Backup: Better Very Large Database Backup & Recovery and More!!

<Insert Picture Here>
MySQL Enterprise Backup
Better Very Large Database Backup & Recovery and More!
Gagan Goel
MEB Software development manager

Copyright © 2017, Oracle and/or its affiliates. All rights reserved.
‹#›
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, and timing of any features or functionality
described for Oracle’s products remains at the sole discretion of
Oracle.

‹#›
Why backups?
• Data is your most valuable IP. You have to protect it from loss.
• Disaster Recovery
– Hardware, Software, Developer or DBA (Pilot) error
• Migration and Upgrades - Change Hardware – serve or storage
• Create replica’s for HA setup
• Archival – requirements to keep data for X number of years
• Move chunks of data
• Setup Test environments

‹#›
Types of Backup and Tools for these types
• Logical
– Mysqldump
– Mysqlpump
• Next Generation for logical backup
• Physical
– MySQL Enterprise Backup (MEB)
• Other
– Snapshots
– Replicas

‹#›
Logical Backup
• Advantages
– Easy of use - simple commands allow you to easily backup and restore
– Good for small database or tables – minimum impact on backup and restore
performance
– Flexibility – logical backup allows you to choose what you want to backup and not
backup. Change the scripts to restore partially etc.
– Readability - good assurance that database files are not corrupt - all the data is
read and it is read using standard SQL queries.
– Portable – use across various OS and MySQL versions
• Collection of SQL Queries to recreate the database

‹#›
Logical Backup
• Disadvantages
– Not an online solution - write operations are locked while performing the backup,
thereby blocking use of the database.
– Poor performance for larger databases – backup and especially restore times are
very slow for larger databases.
– No incremental backup – all backups are full backups, can be time consuming and
require more storage.
• Collection of SQL Queries to recreate the database

‹#›
Physical Backup (MEB)
• Advantages
– “HOT” NON-Blocking for Innodb
– Performance – orders of magnitude faster
for backup and restore
– Scalable – performance is near linear for
larger databases.
– Efficient – processes mostly run outside
server
– More compact backup files – up to 90%
compression in some cases.
– Secure – supports AES 256 compression
• Copy of the internal files that constitute the MySQL database
• Restore Copy back Internal Files and Replay data changes to make data
consistent.
– Flexible – support for incremental backups, partial
backups, backup compression, point in time recovery
and more.
– Many targets supported directly
– Media Managers – Oracle Secure Backup,
– Cloud Storage - AWS S3, OpenStack Swift
– General Streaming (pipe to SSH etc)
– Archival Backups – suitable archival format for
historical purposes
– Consistent – delivers consistent point in time recovery

‹#›
Backup Options Comparison/Summary
MySQL Enterprise Backup mysqlpump mysqldump LVM Snapshot MySQL HA GR/Replication
Full Backup Y Y Y Y Y
Incremental Backup Y N N Y N
Partial Backup Y Y Y N N
Compression Support Y N N N N
Encryption Support Y N N N N
Allows Updates Y N N N Y
Point in time consistent Y N N Y Y
Backup Speed Very Fast Slow Very Slow Fast Very Fast
Recovery Speed Very Fast Very Poor Very Poor Fast Very Fast
Partial Restore Y Y Y N N
Corruption Detection Y Y Y N N
Meet Regulatory Archive
Requirements
Y Y Y N N
Supports DDL Y Y Y N N
Streaming Support Y Y Y N N
Direct Media Manager/Tape
Support
Y N N N N

‹#›
Backup and Recovery can be trickier than it appears
Requires some fore thought 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 space is critical

Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Example Backup Strategy
A comprehensive plan for backup and recovery

Example Recovery Strategy
A comprehensive plan for backup and recovery
Recover log to
Full Backup
• For past 3 days
Recover
Incremental Backup
• 3 days to 1 week
Archive Backup
• Archive full backups
more than 1 week old to
tape.
• Delete backups more
than 6 months old

Validate
No backup strategy is complete without validating backup
Validate by
MEB command
• Every week
Validate by
reinstall
• Every month
Reinstall and run
regression
• Every 2 months

‹#›
To consider performance think of structure of a running backup –
one way is like this.

‹#›
To consider performance think of structure of a running backup – or
like this.

‹#›
What determines backup speed? The longest time

‹#›
What determines backup speed? The longest Time

‹#›
Too much Sharing – slows things down –
Mostly IO Contention, At times CPU

‹#›
Improving backup speed

‹#›
Does Highest Compression=Higher Speed
Not typically
High
Compression
Impacts on CPU

‹#›
MySQL Enterprise Backup is Truly Parallel
Read, Write, Processing
Parallel Processing
Is Faster
https://blogs.oracle.com/mysqlenterprisebackup/entry/truly_parallel_backup_mysql_enterprise
http://dev.mysql.com/doc/mysql-enterprise-backup/4.10/en/backup-capacity-options.html

‹#›
MySQL Enterprise Backup is Buffered
http://dev.mysql.com/doc/mysql-enterprise-backup/4.10/en/backup-capacity-options.html
http://dev.mysql.com/doc/mysql-enterprise-backup/4.10/en/backup-performance.html

‹#›
Understanding your system
• CPU load
– Patterns – look at times of day
– Load level – is it low or high – often DBs are low = 30%
• IO load
– Patterns – look at times of day
– Architecture
• IO rate
– How fast can you read database files?
– How fast can you write?
– Run DD or other tools – whats you MB/sec?

‹#›
Compression options
• LZ4
– Fastest and Most Efficient
– Slightly Lower compression rate
• ZLIB
– Medium Compression
– Medium Cost
• LZMA
– High Compression rate
• Huge Dictionary
– High cost

‹#›
LZ4 –default compression (older versions were zlib)
• IF
– To save on write IO on backup
– For backup to run faster/in less time
• Most cases faster than uncompressed
• If write bound – less data to write is faster
– And makes CPU overhead even lower
– On a busy database
• LZ4 is low overhead – database CPUs not saturated.
– Lz4 compression doesn’t side affect DB performance
• If zlib compression was to much CPU overhead
– Try LZ4 - better than LZO/QuickLZ and many others
• NOT IF
– Database is already compressed or blob data is compressed
• Can’t compress what is already compressed

‹#›
LZMA – new option for compression at all costs
• IF
– Really want to save on space
– Running off hours or cold backup
– Have strong CPUs
– Have horribly Slow IO
• NOT IF
– You want the backup to run faster
• Typically time is slower
– You have a busy database
• LZMA is high overhead and will saturate CPUs
• If zlib was to much overhead previously, LZMA is more
– Instead try LZ4

‹#›
Test these new Options
Recommendation
• Use previous guidance BUT
• Trying various options out
– Your results may vary
• Its why we have options
– Pick what works best for you
• Let us know what worked best

‹#›
New Encryption option
Secure your sensitive backup data with encryption
• Note – only supported for image backup
– --backup-image
• Works very well with compression
– Compress then encrypt – you can’t compress encrypted files.
• Uses symmetric Encryption
– AES – Advanced Encryption Standard
• 256 bit
– Using very latest OpenSSL Library
– Data is encrypted prior to hitting disk or other storage

‹#›
WHAT’S NEW,
WHEN TO USE,
HOW TO USE

‹#›
Optimistic Backup Overview
• Takes advantage of Database table usage patterns
– Tables that are infrequently updated
– Tables that are typically only update during certain periods of time
• Uses that information to optimize the backup pattern
• Results in
– Faster, Less Time
– Smaller
– Less overhead backups
– Quicker recovery, Less Time

‹#›
Optimistic Backup Overview – How it work
• You provide information about tables
– Which are active or inactive
– Based on names or timing etc.
• Use this info to perform a 2 phase backup

‹#›
Why is optimistic better faster in some cases
• Normally we assume every table could change
– Start collecting the REDO log at start of the backup
• All of it
– Thus if the backup takes 1 hour – we backup 1 hour of REDO changes for all tables
• If we know many tables don’t change then
– We don’t start copying the REDO till we get to active tables
– Its may be that 80% of data isn’t changing
– We copy that 80%
– Then start active 20%. REDO may be ~80% smaller
• On restore REDO brings to a consistent state
– Now has 80% fewer pages to go through and apply

‹#›
Phase 1 – copy “inactive” files
Phase 2 – copy “active” files

‹#›
Optimistic Parameters
• optimistic-time
– This option specifies the cut-off date-time to identify tables to be skipped in first
phase. Several options - easiest is {Number}{Unit} – for example --optimistic-
time=23hours
– https://dev.mysql.com/doc/mysql-enterprise-backup/4.0/en/backup-capacity-options.html#option_meb_optimistic-time
• optimistic-busy-tables
– This option specifies the InnoDB tables (i.e. busy tables) to be skipped in the first
phase.
– Defined using a regular expression
• Note: optimistic-busy-tables gets higher precedence than the optimistic-
time option

‹#›
Optimistic Differential Backup
• We already have FULL optimistic
– now Incremental completes the feature - even greater value
• Without incremental optimistic
– Current algorithm checks all tables to find changed pages
• With optimistic (more efficient)
– Scans only those tables that have been modified since the previous backup
– In case of optimistic incremental backup, no additional parameters are necessary
• No need for --optimistic-time or --optimistic-busy-tables options
– Busy tables are already clearly defined and identified

‹#›
How’s it optimistic incremental works
• Optimistic incremental backup starts
• Compares the modified time of each table against the consistency time.
• If the modification time of a table is greater than the consistency time
– Table has been modified after consistency time was recorded
• Optimistic incremental backup copies changed pages

‹#›
Example of Optimistic Backups – FULL and Incremental
FULL – this uses a datetime format – could also use hours, days, weeks, etc. since change format
# A full optimistic backup performed on 2017/02/04, Sat, at 1130 PM.
mysqlbackup --defaults-file=/home/admin/my.cnf
--optimistic-time=110516200000
--backup-dir=/home/admin/temp_dir
--backup-image=/home/admin/bkups/mydb_full_201702042330.bi
--with-timestamp
backup-to-image
# A sequence of optimistic incremental backups are then performed on each the following six days at 1130 PM # On Sunday, 2017/02/05
mysqlbackup --defaults-file=/home/admin/my.cnf
--incremental=optimistic --incremental-base=history:last_backup
--backup-dir=/home/admin/temp_dir
--backup-image=/home/admin/bkups/mydb_incremental__201702052330.bi
--with-timestamp
backup-to-image

‹#›
Example of Optimistic Restore – FULL and Incremental
# Restore the database to its state at Tuesday, 2017/02/07, at 11:30 PM
# First, restore the full optimistic backup taken on the Saturday before, which was 2017/02/04:
mysqlbackup --defaults-file=/etc/my.cnf
--backup-image=/home/admin/backups/mydb_full_201702042330.bi
--backup-dir=/home/admin/temp_dir --datadir=/var/lib/mysql
--with-timestamp
copy-back-and-apply-log
# Next, restore the optimistic incremental taken on the Sunday, Monday, and Tuesday that follow:
mysqlbackup --defaults-file=/etc/my.cnf --backup-image=/home/admin/backups/mydb_incremental__201702052330.bi
--incremental-backup-dir=/home/admin/temp_dir --datadir=/var/lib/mysql --incremental
--with-timestamp
--backup-image=/home/admin/backups/mydb_incremental__201702062330.bi
--with-timestamp
--backup-image=/home/admin/backups/mydb_incremental__201702072330.bi
--with-timestamp

‹#›
Improved Redo Log Copying
• Fixes issue with Redo Log overwrites
• If redo log records were written faster than they can be processed by
MEB, the backup operation fails
– Log scan was only able to reach <LSN1>, but a checkpoint was at <LSN2>.
– Means that the database server has overwritten a part of the circular REDO log files
before the backup was able to read it.
– To solve this problem either:
• Re-run the backup when the database has less load, or
• Re-configure the database with bigger InnoDB log files.
• Improved – now this problem is highly unlikely

‹#›
• Prior to 4.1
The redo log thread does a lot of work for a single thread

‹#›
• New in 4.1
Now REDO processing split into multiple threads
Could replicate the redo log overwrite issues easily with the older version, but we are yet to see the
problem in the 4.1 release.

‹#›
References
• MySQL Enterprise Backup: Product Information
– www.mysql.com/products/enterprise/backup.html
• MySQL Enterprise Backup Team Blog
– https://blogs.oracle.com/mysqlenterprisebackup/
• MySQL Enterprise Backup: Documentation
– dev.mysql.com/doc/mysql-enterprise-backup/4.1/en/index.html
• How Do I get it
– https://edelivery.oracle.com
• Support and patches (My Oracle Support = MOS)
– https://support.oracle.com

‹#›
Thanks for Attending
• You’ll get the slides
• Please don’t hesitate to send us ideas, feedback, doc requests, blog
requests, etc.
– http://bugs.mysql.com/report.php
– Directly through support
– Blog Comments
– Email
• gagan.goel@oracle.com

MySQL Enterprise Backup: Better Very Large Database Backup & Recovery and More!!

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to MySQL Enterprise Backup: Better Very Large Database Backup & Recovery and More!!

Similar to MySQL Enterprise Backup: Better Very Large Database Backup & Recovery and More!! (20)

Recently uploaded

Recently uploaded (20)

MySQL Enterprise Backup: Better Very Large Database Backup & Recovery and More!!