1.1. Physical backup method
1.1.1. InnoDB physical cold backup
The backup process:
a) stop the server during the copy operation.
b) verify that the server normally closed, there is no error.
c) a copy of each component:
- Every InnoDB table a .frm file
- Table space in the file: system table space, each table space based on the table
- InnoDB log files
- my.cnf file
d) Restart the server.
InnoDB complete backup (all InnoDB tables) of a physical full backup copy of all documents generated InnoDB for space-based management table. All InnoDB tables in all databases must be backed up together, because InnoDB will focus on maintaining certain information in the system table space.
To use the physical backup and recovery InnoDB tables, stop the server, replace all components of copies generated during the backup process, and then restart the server.
Note: The table space must file as a group copy. In other words, we need to replace all existing table space for files on the server. You can not be used to add a physical backup space table to another table space.
1.1.2. MyISAM and ARCHIVE physical backup
The backup process:
a) During the server is running, lock the table to copy:
mysql> USE mysql
mysql> FLUSH TABLES users WITH READ LOCK;
To generate MyISAM or ARCHIVE table, the need to copy the file to represent the MySQL table. For MyISAM, these files are .frm, .MYD and .MYI file. For ARCHIVE tables, these files are .frm and .ARZ file. During this copying operation, the other programs (including the server) can not use the table. In order to avoid server interaction problems, to stop the server during the copy operation.
Note: locking down the server without a valid approach on a Linux system. On Windows, file locking behavior causes may not be able to copy a locked file server list table. In this case, we need to stop the server and then copy the table files.
b) perform file system replication.
c) start a new binary log file: FLUSH LOGS;
To start a new binary log file, you can use FLUSH LOGS (before UNLOCK TABLES). Or, SHOW MASTER STATUS returns the name and location of the current binary log file. The new binary log file contains changes to the data after the backup of all statements (and all subsequent binary log files).
d) After copying the file system is unlocked: UNLOCK TABLES;
To recover from the physical backup MyISAM or ARCHIVE tables, should stop the server, copy the backup files to the appropriate database table directory, and then restart the server.
1.1.3. Using LVM snapshot backups
In the following cases, perform a physical backup with LVM snapshots:
l host supports LVM; For example, Linux support LVM2;
l MySQL data directory contains a file system on the logical volume;
The backup process:
a) generating a MySQL data directory contains a snapshot of the logical volume. When backing up non-InnoDB table, use FLUSH TABLES WITH READ LOCK.
b) perform a physical copy from a snapshot.
c) delete the snapshot.
LVM support systems (such as Linux), you can create a logical volume to include MySQL data directory. You can create a snapshot of the volume, the behavior is like a snapshot of real-time copies of logical volumes. LVM use a mechanism called "copy on write" (copy-on-write) to create a snapshot of the original without the data. When reading the file from the newly created snapshot, LVM will read these files from the original volume. When the original volume before the change, LVM data on the original volume will change immediately copied to the snapshot, therefore, any data that has changed since the snapshot is generated both in its original form is stored in the snapshot. The result of this is that when a file is read from the snapshot, the data obtained version existed when the snapshot. Because snapshots are almost instantaneous, it can be assumed without any change in the underlying data generation snapshots. This makes it very useful snapshot of InnoDB database backup without shutting down the server. To create a snapshot, use the following syntax:
lvcreate -s -n <snapshot-name> -L <size> <original-volume>
-S option indicates the lvcreate to create a snapshot, the other option specifies the name of the location and size of the new snapshot and the original volume.
For example, assume there is a volume group and a logical volume VG_MYSQL lv_datadir:
lvcreate -s -n lv_datadirbackup -L 2G /dev/VG_MYSQL/lv_datadir
Previous statement creates a snapshot lv_datadirbackup, its reserve size is 2 GB. If the snapshot need only a short time, the retention size can be much smaller than the size of the original volume, the snapshot storage as a data block contains only changed in the original volume. For example, if you want to use snapshot backup is subject to change in the time to perform backups and delete snapshots only did the size of the store.
You can mount the same volume as the standard mount snapshot. After loading the snapshot, just like any other physical as backup, perform a physical backup (e.g., through the use of tar or cp) from the roll. From the time the snapshot backup, the database can not have a change during the backup process. You will certainly get the same consistent data when the backup file versions, without stopping the server. Over time, the snapshot space requirements usually grow to the size of the original volume. Further, initial data for each data block of the original volume change will result in two write data to the volume group: copy and writes the requested changes to the snapshot. This may affect performance during snapshot retention. For these reasons, should be removed as soon as possible after the execution of a snapshot backup. To delete a snapshot created by the previous statement, you can use the following statement:
lvremove VG_MYSQL / lv_datadirbackup
1.1.4. Portability of physical backup
l can replicate databases between MySQL server binary. When the computer generated binary backup get on another computer having different architectures, binary portability useful. For example, a method using binary backup database is replicated between the databases MySQL server.
All table spaces and log files l InnoDB database can be copied directly. And the name of the source system database directory on the target system must be identical. For InnoDB, you can use binary portability between different computers on different MySQL servers directly copy table space, other MySQL server can access the table space.
l MyISAM, ARCHIVE, all the files can be copied directly to a single table. For MyISAM or ARCHIVE copy files directly between MyISAM and ARCHIVE tables, binary portability means that MySQL server on a different computer, and other MySQL server can access the table.
l Windows compatibility on Windows systems, MySQL server databases and internal storage lowercase table names. For case-sensitive file system, you can use an option file statement:
lower_case_table_names=1
1.2. Backup log file and status
Ø updates made after the completion of the binary log file storage and backup;
Ø Options file server uses (my.cnf and my.ini file) contains configuration information must be restored after a system crash.
Ø copy the file: Copy the slave master to create a connection to the desired file containing information master.info, as well as an indication of the current relay log the progress of relay-log.info file.
Ø copy slave data files: copy the data files created for handling slave LOAD DATA INFILE statement. These files are located slave_load_tmpdir system variables specified directory using --slave-load-tmpdir option to set the variable at server startup. If you do not set slave_load_tmpdir, value tmpdir system variable is applied. To protect data replication slave, you need to back up files to SQL_LOAD- beginning.
Ø MySQL binaries and libraries
Ø strategies:
- Static file: Use conventional system backup tool in case the server is running
- Dynamic file: Use conventional system backup tool in case of a server is stopped
1.3. Will serve as a backup copy of aid
Ø master can continue to run.
If used as a master in a replication MySQL server arrangement may be used to generate a backup slave without backup master. By using slave backup, master will not be interrupted, the backup process without increasing the processing load on the master, no request for additional hard disk space or additional processing.
Ø can stop the slave to generate backup
Close mysqld process or issue STOP SLAVE SQL_THREAD statement to stop the server process that receives updates from the master. In the latter case, you must refresh the table to force the pending changes to disk.
Ø backup slave database
Generate a backup slave database. Methods available depends on the server is stopped or is still running. For example, if the server is stopped, the tool can not be used mysqldump mysqlhotcopy or the like connected to the server. Stop the server can use the system tools; slave thread to stop, but the server is still running MySQL can use any tool.
Ø Start the server: start and stop the server, START SLAVE SQL_THREAD
Restart the server stopped. If the server is still running, you can restart the SQL thread by issuing a START SLAVE SQL_THREAD statement.
Zhengzhou infertility hospital ×××: http://wapyyk.39.net/zz3/zonghe/1d427.html
1.4 Comparison of backup methods
快照 ：并非所有引擎都以相同方式处理快照。例如， InnoDB 表不需要 FLUSH TABLES WITH READ LOCK 就能启动快照，但 MyISAM 表却需要。1.5. Backup Strategy
Flowchart showing the decision-making process can be used to determine a backup strategy. May issue raised in this process include:
n Our system can withstand prolonged downtime (downtime)?
n How much data to be backed up?
n which storage engine to store data (InnoDB, MyISAM, or both) to use?
1.6. mysqlbinlog
a) determining which generated after the backup log write
After the backup file restored binary or text backup file reloaded, by re-processing the binary data recorded in the change log on the server, the recovery operation is completed. Therefore, it must determine which logs are written after generating the backups. Then, use the mysqlbinlog program to convert the contents of these binary logs into text SQL statements in order to use mysql process results statement.
b) Using a command handler for all mysqlbinlog binlog
mysqlbinlog bin.000050 bin.000051 bin.000052 | mysql
c) recovery portion Binlog
--start-datetime / --stop-datetime
--start-position / --stop-position
mysqlbinlog --start-position=23456 binlog.000004 | mysql
If the specified binary log files are being written during the backup process, it must be extracted from only points written after the backup, all log files are written after plus. In addition, if you accidentally delete a table or database (or data corruption occurred in his case), you can use the incremental activities recorded in the binary log recovery backup. In order to avoid duplication of the implementation of the statement, you can get to all the previous statements before that point binary log file, run the problem statement. In order to process part of the file extraction, mysqlbinlog supports a number of options allows you to specify the time or allow the option to specify the location of the log began to extract the contents of the log:
--start-datetime option: specify the date and time of the beginning of the extraction, where the options parameter takes DATETIME format. But --start-datetime size of only one second, and therefore may not be accurate, you can not specify the exact starting position.
--start-position options: extract can be used to specify the start of the log at a given location.
There are also corresponding --stop-datetime --stop-position and the option to specify a stop position of the extracted log contents.
If you are unsure log file location corresponding to the time stamp or the beginning point of the process, you can use mysqlbinlog (without mysql) to display the contents of the log to check:
shell> mysqlbinlog file_name | more