MySQL enterprise backup overview


Published on

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

MySQL enterprise backup overview

  1. 1. MySQL Enterprise Backup Fast, Consistent, Online Backups <Insert Picture Here> MySQL Enterprise Backup
  2. 2. The preceding 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.
  3. 3. Agenda • • • • Database Backup Overview MySQL Enterprise Backup: Features & Benefits Database Backup Types: Comparison MySQL Enterprise Backup: How it Works
  4. 4. Database Backup Overview
  5. 5. DBA Challenge • Core responsibility for backup and recovery • But, its not easy – Databases are growing exponentially – Backup times are increasing even faster • Your Backups impact other activities – End Users – DBA Maintenance • And your storage costs are out of control • And when bad things happen • Needs to work • Taking forever to recover
  6. 6. Database Backup: Terms • Online Backup (aka “Hot” or “Online”) – Backup while database is running – Zero business interruption during backups • Incremental Backup – Backup of data that has changed since the last full backup. • Partial Backup – Backup of select tables • Consistent Point in Time Recovery – Restoring a database with data in a consistent state at a date and time • Roll Forward Recovery – Recovery that restores a database to a specific date and time.
  7. 7. Most Critical Questions to Ask First • What are my recovery requirements? – Assess tolerance for data loss: Recovery Point Objective (RPO) • How frequently should backups be taken? • Is point-in-time recovery required? – Assess tolerance for downtime: Recovery Time Objective (RTO) • Downtime: Problem identification + recovery planning + systems recovery • Tiered RTO per level of granularity, e.g. database, tablespace, table, row – Determine backup retention policy • Onsite, offsite, long-term • How Does MySQL Enterprise Backup strategy fulfill those requirements?
  8. 8. Backup Method 1: Full • Well Suited for: – Databases that can tolerate hours/days RTO – Medium-High change between backups (e.g. over 30%) – Environments where disk can be allocated for 1x size of database • Backup Strategy – Full backups with optional backup compression – Full backup archived to tape, as needed
  9. 9. Backup Method 2: Full + Incremental • Well suited for – Databases that can tolerate no more than a few hours RTO – Environments where disk can be allocated for 1x size of database • Backup strategy – – – – Occasional Full backup, followed by more frequent incremental To recover - apply Full and then applying 1 or more Incremental Full backups archived to tape, as needed Incremental Backups retained on-disk, as needed
  10. 10. Backup Method 3: Full + Incremental + Log • Well suited for – Databases that can tolerate no more than a few minutes RTO – Environments where disk can be allocated for more than1x size of database • Backup strategy – – – – – – Initial full backup, followed by incremental backups Backup Transaction Logs To recover - apply Full and then applying 1 or more Incremental Finally Roll Forward with Transaction Log to “minute” desired. Full backups and incrementals archived to tape, as needed Logs are backup up and retained on-disk, as needed
  11. 11. Backup Method 4: Offload Backups to Slave (Replication) • Well Suited for: – Databases that require no more than several minutes of recovery time, in event of failure – Environments that can preferably allocate symmetric hardware and storage for physical standby database – Environments whose backup storage infrastructure can be shared between master and slave database sites • Backup Strategy – – – – – Setup Master / Slave replication Slave acts as physical standby database Run full and incremental backup on slave Backup can be restored to master or slave database Backups can be taken at each database for optimal protection
  12. 12. Determining Backup Strategy Low Value Data High Value Data F: Daily A: Replication, Backup on Slave F: Weekly I: Daily F: Daily F: Daily I: Hourly I: Hourly Low Change Change Frequency I: Hourly A: Binlog Backups: 5 min F: Monthly F: Full I: Incremental A: Additional I: Weekly F: Weekly I: Daily F: Monthly Value of Data High Change
  13. 13. Backup Strategies Comparison Method Backup Factors Recovery Factors Method 1: Full Backups • Longest Backup Times • Largest Storage Space • Save space with compression • Easy to Recover • Fastest Restore Times Method 2: Full + Incremental Backup • Shortest Backup Time • Reduced Storage Requirements • Requires 1X production storage for copy • Finer-grained Recovery • Slower Restore Times • First Restore Full Backup • Then Restore Incrementals Method 3: Full + Incremental + Log Backup • Added Storage Requirements • Requires more than 1X production storage for copy • Finest-grained Recovery • Slowest Restore Times • First Restore Full Backup • Then Restore Incrementals • Then Apply Logs Method 4: • Used with 1 of the above Offload Backups Slave • Frees Master for more workload Replication • Requires 1X production hardware and storage for standby database • Fast failover to standby • Backups are last resort, in event of double site failure or need to perform PITR
  14. 14. MySQL Enterprise Backup Features & Benefits
  15. 15. MySQL Server Features - Online Backup is the #1 most requested feature for MySQL Enterprise Customers
  16. 16. MySQL Backup Concerns - Backup & Recovery Performance is the #1 Concern
  17. 17. MySQL Enterprise Backup • • • • • • • • • • Online Backup for InnoDB Support for MyISAM (Read-only) High Performance Backup & Restore Compressed Backup Full Backup Incremental Backup Partial Backups Point in Time Recovery Unlimited Database Size Cross-Platform – Windows, Linux, Unix
  18. 18. Benefits • Online “Hot” Backup (Non-blocking) – Reads and Writes to InnoDB – Reads for MyISAM tables • High Performance – Backup: >3x faster than mysqldump (export) – Restore: >10x than mysqldump recovery • Consistent Backups – Point in Time Recovery • Compression – Multi-level compression – Save 70% or more of the storage required
  19. 19. Benefits • Reliable – Proven for 7+ Years • Scalable for Large Databases – No Database Size Limitations • Easy to automate – Easily integrate within various scheduling systems – Examples: cron, OSB scheduler, others
  20. 20. MySQL Enterprise Backup 3.5: New Features • Incremental backup • Support of InnoDB Barracuda file format • Backup of compressed tables • Backup of partition files • Backup of in-memory database • with --exec-when-locked option • Adds mysql system tables to keep backup status, progress, and history
  21. 21. High Performance Backups Backups are up to 3.5x Faster than MySQL Dump
  22. 22. High Performance Restore Restore is up to 16x Faster than MySQL Dump - mysqldump performance is non-linear (more table/indexes impacts performance) - MySQL Enterprise performance is near linear
  23. 23. Backup Compression Storage Savings Backup size reduced from 65% up to 93%
  24. 24. Database Backup Types Advantages & Disadvantages
  25. 25. MySQL Backup Tools • Hot Backup (online) – MySQL Enterprise Backup • Export/Import (portable copies – a logical backup) – mysqldump • Standby Copy (hot swap) • • MySQL Replication Cold Backup (offline) – Simple File Copies when server is shutdown • File System Volume Managers (snapshots) – LVM for example - create snapshot copy
  26. 26. mysqldump • Advantages – Good for small databases or tables – Good assurance that database files are not corrupt – Logical Backup – thus flexible and portable • Disadvantages – Very slow restore times – Uses database processing cycles and resources – Not Online (requires Transaction or Locks on Tables in the database) – Not Incremental (requires a Full Backup every time) – Not Consistent (unless transaction is used)
  27. 27. MySQL Replication • Advantages – – – – Rolling “snapshot” Quick Recovery - via failover Non-Blocking Works well in conjunction with other backup options • Disadvantages – – – – Only latest “Point in Time” (point it time keeps moving forward) Not historical Not for archival purposes Doesn’t protect from “oops”
  28. 28. LVM Snapshots • Advantages – Quick – Feature of Linux – Good to use in conjunction with backups • Disadvantages – It’s a snapshot – Still need to make a backup copy – which is “full” in size – Performance degrades with each concurrent snapshot – Snapshots need to be released – Cross File System Limitations
  29. 29. MySQL Enterprise Backup • Advantages – – – – – – Physical Backup so Fast – esp. restores Flexible - many options Archival Scalable Consistent Supported • Disadvantages • Requires some planning
  30. 30. MySQL Backup Types: Comparison mysqldump LVM Snapshots MySQL Replication MySQL Enterprise Backup Full Backup ✔ ✔ ✔ ✔ Incremental Backups ✖ ✔ ✖ ✔ Partial Backups ✔ ✖ ✖ ✔ Compression Support ✖ ✖ ✖ ✔ Allows updates ✖ ✖ ✔ ✔ Point in Time Consistent ✖ ✔ ✔ ✔ Backup Speed Poor Good Very Good Very Good Very Poor Good Very Good Very Good Partial Restore ✔ ✖ ✖ ✔ Corruption Detection ✔ ✖ ✖ ✔ Meets Regulatory Archive Req. ✔ ✖ ✖ ✔ Supports DDL ✔ ✖ ✖ ✔ Recovery Speed
  31. 31. MySQL Enterprise Backup How it Works
  32. 32. MySQL Enterprise Backup • MySQL Enterprise Backup CLI • MySQL Enterprise Monitor • Oracle Secure Backup Intrinsic knowledge of database file formats • Block Validation Media Manager (like Oracle Secure Backup) • Tablespace/Data file recovery • Unused Block Compression • Consistent Recovery • File Compression Database Quickly Accessible Disk Storage Tape Archive
  33. 33. MySQL Enterprise Backup: Terms • mysqlbackup : backup executable which includes InnoDB, MyISAM and other MySQL Data. mysqlbackup is a compatible replacement for the innobackup post 3.5.1 and includes additional features and capabilites • ibbackup: finer grained raw innodb backup executable for innodb files alone • binlog: contains database changes – eg DDL and DML • LSN: Log Sequence Number – the unique monotonically increasing id for each change in the binlog • Ibdata: system tablespace files • .ibd: single table space file
  34. 34. How it Works: Backup for InnoDB • Step 1: Backing Up InnoDB Data Files – Copies and compresses InnoDB data files • System Database (ibdata) & Single-table Tablespaces (.ibd) – Produces “Fuzzy Backup • Backup of data files doesn’t correspond to any specific log sequence number (LSN) • Different database pages are copied at varying times ibbackup 1. InnoDB Tables & Indexes MEB Backup Files MySQL Database Files
  35. 35. How it Works: Backing Up InnoDB Data Files Newest LSN InnoDB data file compressed data file L S N data L S N L S N data data L S N L S N data Oldest LSN data L S N data L S N L S N data data L S N L S N data data L S N data L S N data L S N L S N data data • Backup files size is reduced by 70% – Omits unused storage in each block, empty pages • Produces “Fuzzy Backup” • Notes earliest and latest Log Sequence Number (LSN)
  36. 36. How it Works: Backup for InnoDB • Step 2: Backing up InnoDB Log Files – Copies Log Records accumulated during data file copy – All redo records with LSNs during data file copy ibbackup 1. InnoDB Tables & Indexes MEB Backup Files 2. Log Files MySQL Database Files
  37. 37. How it Works: Backing up InnoDB Log Files Log File Earliest needed redo info L S N redo info L S N redo info L S N redo info Last needed redo info L S N redo info L S N redo info L S N redo info ibbackup_logfile L S N Oldest LSN Log file w/relevant redo L S N Newest LSN • Copies portion of the log file that contains all required redo information • Covers the time from beginning to end of data backup • Recovers all data blocks modified after copied to compressed data file
  38. 38. Full & Partial Backups • Backup contains all tables in system tablespace – Plus those separate tables that match the pattern • When using “file per table”, you can backup a subset of InnoDB tables – Tables included in the backup are specified with regular expressions – Use the -- include option Full Backup Table A Multiple tables & indexes in the system tablespace (ibdata files) Table B Table C Partial Backup One table & indexes per file (.ibd files) Table D Table E Table F
  39. 39. mysqlbackup – Usage Syntax mysqlbackup [--sleep=MS] [--compress[=LEVEL]] [--include=REGEXP] [--user=WORD][--password=WORD] [--port=PORT] [--socket=SOCKET] [--no-timestamp] [--ibbackup=IBBACKUP-BINARY] [--slave-info] [--backup-and-apply-log] [--databases=LIST] [--exec-when-locked="utility arg1 arg2 ..."] [--incremental --lsn=LSN] [--only-known-file-types] MY.CNF BACKUP-ROOT-DIR mysqlbackup --apply-log [--use-memory=MB] [--uncompress] [--ibbackup=IBBACKUP-BINARY] MY.CNF BACKUP-DIR mysqlbackup --apply-log --incremental [--use-memory=MB] [--uncompress] [--ibbackup=IBBACKUP-BINARY] INCREMENTAL-BACKUP-MY.CNF FULL-BACKUP-MY.CNF mysqlbackup --copy-back MY.CNF BACKUP-DIR
  40. 40. mysqlbackup (innobackup) Examples • Full Backup mysqlbackup --user=dba --password=xyz --compress /etc/my.cnf /backups • Incremental Backup – The backup only contains changed data mysqlbackup --incremental --lsn 2261747124 /etc/my.cnf /incr-backup • Partial – The backup contains tables in test database that match the .ib.* regular expression. mysqlbackup --include 'test.ib.*' /etc/my.cnf /backups
  41. 41. How mysqlbackup Works SQL: “FLUSH TABLES WITH READ LOCK” mysqlbackup Exec’s MySQL Command-line Client ibbackup InnoDB Tables & Indexes Hot Backup Files MyISAM Tables & Indexes, .frm, & .mrg files MySQL Database Files Flush, Lock SQL MySQL Server
  42. 42. Tips: InnoDB and MyISAM Backup • InnoDB tables are fully accessible during backup – Insert, Update & Delete • MyISAM tables cannot be updated during backup – Uses FLUSH TABLES WITH READ LOCK near the end of the backup • Works best if … – Wait for insert/update/delete transactions during MyISAM backup – Do not run long SELECT queries during the backup – MyISAM tables are small, thus copied quickly
  43. 43. ibbackup – Usage Syntax – strictly innodb Usage: ibbackup [--incremental lsn] [--sleep ms] [--suspend-at-end] [--compress [level]] [--include regexp] my.cnf backup-my.cnf or ibbackup --apply-log [--use-memory mb] [--uncompress] backup-my.cnf or ibbackup --apply-log --incremental [--use-memory mb] [--uncompress] incremental-backup-my.cnf full-backup-my.cnf
  44. 44. Typical ibbackup Backup/Restore Steps •Take Backup' – ibbackup my.cnf backup.cnf •Prepare backup for restore – ibbackup –apply-log backup.cnf •Copy innodb backup files to mysqld datadir •Start mysqld •Performs recovery during startup
  45. 45. Examples : Take Backup details • ibbackup my.cnf backup.cnf Example my.cnf [mysqld] datadir = /production/var innodb_data_home_dir = /production/var innodb_log_group_home_dir = /production/var innodb_data_file_path =ibdata1:32M;ibdata2:32M:autoextend innodb_log_files_in_group = 3 innodb_log_file_size = 32M Example backup.cnf datadir = /backup innodb_log_group_home_dir = /backup innodb_data_home_dir = /backup innodb_data_file_path = ibdata1:32M;ibdata2:32M:autoextend innodb_log_files_in_group = 3 innodb_log_file_size = 32M
  46. 46. Tips: “Raw Backup” Files • The “raw backup” files from backup phase cannot be directly consumed by MySQL • These files can be copied to media • The database must be “restored” first • Use mysqlbackup to restore database before use Compressed copy of InnoDB data file(s) ibbackup_logfile Copy of MyISAM, frm, .mrg files Raw Backup Files
  47. 47. How it Works: Restoring a Database MySQL data dir Compressed copy of InnoDB data file(s) 1. Uncompresses InnoDB files to data dir InnoDB data files 2. Recreates InnoDB Log files log files MyISAM, .frm, .mrg files ibbackup_logfile 3. Applies log, so InnoDB files are consistent 4. Restores MyISAM and other files Copy of MyISAM, frm, .mrg files
  48. 48. Restoring a Database Con’t… • MEB restore rolls forward data files to a common point in time (the time at the end of backup) • After restore, MEB Backup prints the location in the binlog for the next SQL operation that executed after the backup completed • Note: the restore phase need not run on database server host – You can perform recovery on any machine, and copy recovered files to your database server host
  49. 49. Backup and Roll forward “Log” Recovery • Also known as log archiving or log backups • Add executing mysqlbinlog to copy logs to your full and incremental backup schedules • Restore Full and Incremental as previously described • Roll forward using binlog from the final lsn to the lsn for the desired recovery point in time
  50. 50. Roll Forward Backup and Recovery • Log Backup – Use mysqlbinlog to make a continuous backup of the binary log – mysqlbinlog --read-from-remote-server --host=host_name --raw --stop-never binlog.000999 • Restore – If data loss occurs (for example, if the server crashes), restore the most recent MEB backup – Edit output file to truncate at desired point – Note end lsn and use for roll forward start position • mysqlbinlog --start-position=27284 binlog.001002 binlog.001003 binlog.001004 | mysql --host=host_name -u root -p
  51. 51. Additional Resources • Product Information • Documentation • Backup Forum • Download (30 Day Trial)