更正

docs/7/7.1/backup and recovery type.md

@@ -0,0 +1,100 @@
+# 7.1 备份和恢复的数据类型
+This section describes the characteristics of different types of backups.
+
+Physical (Raw) Versus Logical Backups
+Physical backups consist of raw copies of the directories and files that store database contents. This type of backup is suitable for large, important databases that need to be recovered quickly when problems occur.
+
+Logical backups save information represented as logical database structure (CREATE DATABASE, CREATE TABLE statements) and content (INSERT statements or delimited-text files). This type of backup is suitable for smaller amounts of data where you might edit the data values or table structure, or recreate the data on a different machine architecture.
+
+Physical backup methods have these characteristics:
+
+The backup consists of exact copies of database directories and files. Typically this is a copy of all or part of the MySQL data directory.
+
+Physical backup methods are faster than logical because they involve only file copying without conversion.
+
+Output is more compact than for logical backup.
+
+Because backup speed and compactness are important for busy, important databases, the MySQL Enterprise Backup product performs physical backups. For an overview of the MySQL Enterprise Backup product, see Section 30.2, “MySQL Enterprise Backup Overview”.
+
+Backup and restore granularity ranges from the level of the entire data directory down to the level of individual files. This may or may not provide for table-level granularity, depending on storage engine. For example, InnoDB tables can each be in a separate file, or share file storage with other InnoDB tables; each MyISAM table corresponds uniquely to a set of files.
+
+In addition to databases, the backup can include any related files such as log or configuration files.
+
+Data from MEMORY tables is tricky to back up this way because their contents are not stored on disk. (The MySQL Enterprise Backup product has a feature where you can retrieve data from MEMORY tables during a backup.)
+
+Backups are portable only to other machines that have identical or similar hardware characteristics.
+
+Backups can be performed while the MySQL server is not running. If the server is running, it is necessary to perform appropriate locking so that the server does not change database contents during the backup. MySQL Enterprise Backup does this locking automatically for tables that require it.
+
+Physical backup tools include the mysqlbackup of MySQL Enterprise Backup for InnoDB or any other tables, or file system-level commands (such as cp, scp, tar, rsync) for MyISAM tables.
+
+For restore:
+
+MySQL Enterprise Backup restores InnoDB and other tables that it backed up.
+
+ndb_restore restores NDB tables.
+
+Files copied at the file system level can be copied back to their original locations with file system commands.
+
+Logical backup methods have these characteristics:
+
+The backup is done by querying the MySQL server to obtain database structure and content information.
+
+Backup is slower than physical methods because the server must access database information and convert it to logical format. If the output is written on the client side, the server must also send it to the backup program.
+
+Output is larger than for physical backup, particularly when saved in text format.
+
+Backup and restore granularity is available at the server level (all databases), database level (all tables in a particular database), or table level. This is true regardless of storage engine.
+
+The backup does not include log or configuration files, or other database-related files that are not part of databases.
+
+Backups stored in logical format are machine independent and highly portable.
+
+Logical backups are performed with the MySQL server running. The server is not taken offline.
+
+Logical backup tools include the mysqldump program and the SELECT ... INTO OUTFILE statement. These work for any storage engine, even MEMORY.
+
+To restore logical backups, SQL-format dump files can be processed using the mysql client. To load delimited-text files, use the LOAD DATA statement or the mysqlimport client.
+
+Online Versus Offline Backups
+Online backups take place while the MySQL server is running so that the database information can be obtained from the server. Offline backups take place while the server is stopped. This distinction can also be described as “hot” versus “cold” backups; a “warm” backup is one where the server remains running but locked against modifying data while you access database files externally.
+
+Online backup methods have these characteristics:
+
+The backup is less intrusive to other clients, which can connect to the MySQL server during the backup and may be able to access data depending on what operations they need to perform.
+
+Care must be taken to impose appropriate locking so that data modifications do not take place that would compromise backup integrity. The MySQL Enterprise Backup product does such locking automatically.
+
+Offline backup methods have these characteristics:
+
+Clients can be affected adversely because the server is unavailable during backup. For that reason, such backups are often taken from a replica that can be taken offline without harming availability.
+
+The backup procedure is simpler because there is no possibility of interference from client activity.
+
+A similar distinction between online and offline applies for recovery operations, and similar characteristics apply. However, it is more likely for clients to be affected by online recovery than by online backup because recovery requires stronger locking. During backup, clients might be able to read data while it is being backed up. Recovery modifies data and does not just read it, so clients must be prevented from accessing data while it is being restored.
+
+Local Versus Remote Backups
+A local backup is performed on the same host where the MySQL server runs, whereas a remote backup is done from a different host. For some types of backups, the backup can be initiated from a remote host even if the output is written locally on the server. host.
+
+mysqldump can connect to local or remote servers. For SQL output (CREATE and INSERT statements), local or remote dumps can be done and generate output on the client. For delimited-text output (with the --tab option), data files are created on the server host.
+
+SELECT ... INTO OUTFILE can be initiated from a local or remote client host, but the output file is created on the server host.
+
+Physical backup methods typically are initiated locally on the MySQL server host so that the server can be taken offline, although the destination for copied files might be remote.
+
+Snapshot Backups
+Some file system implementations enable “snapshots” to be taken. These provide logical copies of the file system at a given point in time, without requiring a physical copy of the entire file system. (For example, the implementation may use copy-on-write techniques so that only parts of the file system modified after the snapshot time need be copied.) MySQL itself does not provide the capability for taking file system snapshots. It is available through third-party solutions such as Veritas, LVM, or ZFS.
+
+Full Versus Incremental Backups
+A full backup includes all data managed by a MySQL server at a given point in time. An incremental backup consists of the changes made to the data during a given time span (from one point in time to another). MySQL has different ways to perform full backups, such as those described earlier in this section. Incremental backups are made possible by enabling the server's binary log, which the server uses to record data changes.
+
+Full Versus Point-in-Time (Incremental) Recovery
+A full recovery restores all data from a full backup. This restores the server instance to the state that it had when the backup was made. If that state is not sufficiently current, a full recovery can be followed by recovery of incremental backups made since the full backup, to bring the server to a more up-to-date state.
+
+Incremental recovery is recovery of changes made during a given time span. This is also called point-in-time recovery because it makes a server's state current up to a given time. Point-in-time recovery is based on the binary log and typically follows a full recovery from the backup files that restores the server to its state when the backup was made. Then the data changes written in the binary log files are applied as incremental recovery to redo data modifications and bring the server up to the desired point in time.
+
+Table Maintenance
+Data integrity can be compromised if tables become corrupt. For InnoDB tables, this is not a typical issue. For programs to check MyISAM tables and repair them if problems are found, see Section 7.6, “MyISAM Table Maintenance and Crash Recovery”.
+
+Backup Scheduling, Compression, and Encryption
+Backup scheduling is valuable for automating backup procedures. Compression of backup output reduces space requirements, and encryption of the output provides better security against unauthorized access of backed-up data. MySQL itself does not provide these capabilities. The MySQL Enterprise Backup product can compress InnoDB backups, and compression or encryption of backup output can be achieved using file system utilities. Other third-party solutions may be available.

docs/7/7.2/database backup methods.md

@@ -0,0 +1,55 @@
+# 7.2 多种数据库备份方法
+This section summarizes some general methods for making backups.
+
+Making a Hot Backup with MySQL Enterprise Backup
+Customers of MySQL Enterprise Edition can use the MySQL Enterprise Backup product to do physical backups of entire instances or selected databases, tables, or both. This product includes features for incremental and compressed backups. Backing up the physical database files makes restore much faster than logical techniques such as the mysqldump command. InnoDB tables are copied using a hot backup mechanism. (Ideally, the InnoDB tables should represent a substantial majority of the data.) Tables from other storage engines are copied using a warm backup mechanism. For an overview of the MySQL Enterprise Backup product, see Section 30.2, “MySQL Enterprise Backup Overview”.
+
+Making Backups with mysqldump
+The mysqldump program can make backups. It can back up all kinds of tables. (See Section 7.4, “Using mysqldump for Backups”.)
+
+For InnoDB tables, it is possible to perform an online backup that takes no locks on tables using the --single-transaction option to mysqldump. See Section 7.3.1, “Establishing a Backup Policy”.
+
+Making Backups by Copying Table Files
+MyISAM tables can be backed up by copying table files (*.MYD, *.MYI files, and associated *.sdi files). To get a consistent backup, stop the server or lock and flush the relevant tables:
+
+FLUSH TABLES tbl_list WITH READ LOCK;
+You need only a read lock; this enables other clients to continue to query the tables while you are making a copy of the files in the database directory. The flush is needed to ensure that the all active index pages are written to disk before you start the backup. See Section 13.3.6, “LOCK TABLES and UNLOCK TABLES Statements”, and Section 13.7.8.3, “FLUSH Statement”.
+
+You can also create a binary backup simply by copying the table files, as long as the server isn't updating anything. (But note that table file copying methods do not work if your database contains InnoDB tables. Also, even if the server is not actively updating data, InnoDB may still have modified data cached in memory and not flushed to disk.)
+
+For an example of this backup method, refer to the export and import example in Section 13.2.6, “IMPORT TABLE Statement”.
+
+Making Delimited-Text File Backups
+To create a text file containing a table's data, you can use SELECT * INTO OUTFILE 'file_name' FROM tbl_name. The file is created on the MySQL server host, not the client host. For this statement, the output file cannot already exist because permitting files to be overwritten constitutes a security risk. See Section 13.2.13, “SELECT Statement”. This method works for any kind of data file, but saves only table data, not the table structure.
+
+Another way to create text data files (along with files containing CREATE TABLE statements for the backed up tables) is to use mysqldump with the --tab option. See Section 7.4.3, “Dumping Data in Delimited-Text Format with mysqldump”.
+
+To reload a delimited-text data file, use LOAD DATA or mysqlimport.
+
+Making Incremental Backups by Enabling the Binary Log
+MySQL supports incremental backups using the binary log. The binary log files provide you with the information you need to replicate changes to the database that are made subsequent to the point at which you performed a backup. Therefore, to allow a server to be restored to a point-in-time, binary logging must be enabled on it, which is the default setting for MySQL 8.0 ; see Section 5.4.4, “The Binary Log”.
+
+At the moment you want to make an incremental backup (containing all changes that happened since the last full or incremental backup), you should rotate the binary log by using FLUSH LOGS. This done, you need to copy to the backup location all binary logs which range from the one of the moment of the last full or incremental backup to the last but one. These binary logs are the incremental backup; at restore time, you apply them as explained in Section 7.5, “Point-in-Time (Incremental) Recovery”. The next time you do a full backup, you should also rotate the binary log using FLUSH LOGS or mysqldump --flush-logs. See Section 4.5.4, “mysqldump — A Database Backup Program”.
+
+Making Backups Using Replicas
+If you have performance problems with a server while making backups, one strategy that can help is to set up replication and perform backups on the replica rather than on the source. See Section 17.4.1, “Using Replication for Backups”.
+
+If you are backing up a replica, you should back up its connection metadata repository and applier metadata repository (see Section 17.2.4, “Relay Log and Replication Metadata Repositories”) when you back up the replica's databases, regardless of the backup method you choose. This information is always needed to resume replication after you restore the replica's data. If your replica is replicating LOAD DATA statements, you should also back up any SQL_LOAD-* files that exist in the directory that the replica uses for this purpose. The replica needs these files to resume replication of any interrupted LOAD DATA operations. The location of this directory is the value of the system variable replica_load_tmpdir (from MySQL 8.0.26) or slave_load_tmpdir (before MySQL 8.0.26). If the server was not started with that variable set, the directory location is the value of the tmpdir system variable.
+
+Recovering Corrupt Tables
+If you have to restore MyISAM tables that have become corrupt, try to recover them using REPAIR TABLE or myisamchk -r first. That should work in 99.9% of all cases. If myisamchk fails, see Section 7.6, “MyISAM Table Maintenance and Crash Recovery”.
+
+Making Backups Using a File System Snapshot
+If you are using a Veritas file system, you can make a backup like this:
+
+From a client program, execute FLUSH TABLES WITH READ LOCK.
+
+From another shell, execute mount vxfs snapshot.
+
+From the first client, execute UNLOCK TABLES.
+
+Copy files from the snapshot.
+
+Unmount the snapshot.
+
+Similar snapshot capabilities may be available in other file systems, such as LVM or ZFS.

docs/7/tutorial.md

@@ -0,0 +1,45 @@
+# 章节 7 备份和恢复
+
+**目录**
+
+- 【7.1备份和恢复的数据类型】
+
+- 【7.2 多种数据库备份方法】
+
+- 【7.3 备份示例以及恢复策略】
+
+- 【7.4 用 `mysqldump` 命令备份】
+
+- 【7.5 按时间点 (增量) 备份】
+
+- 【7.6 使用 `MyISAM` 引擎的表格维护和崩溃后恢复】
+
+备份数据库很重要，通过备份可以恢复数据，再次（正确）启动和运行（程序），以防止出现错误，比如系统崩溃，硬件故障，用户错误的删除数据；备份（操作）也是必须的，特别是作为一种保护措施，在升级MySQL安装程序之前，迁移到MySQL数据库的配置到另外一个系统，或者是为复制的`MySQL` 服务器准备数据。
+
+`MySQL` 提供了多种备份策略，可以选择最适合自己的，满足配置要求的策略。本章讨论了几个关于备份和恢复的主题，这些讨论包含一些或许已经熟悉的内容：
+
+- 备份类型： 逻辑卷备份VS物理卷备份，完全备份VS增量备份，等等。
+- 创建备份的多种方式。
+- 恢复方式，包括按照时间点恢复。
+- 备份计划，压缩，和加密。
+- 数据表维护，以便恢复损坏的数据表。
+
+## 其他资源
+
+下列内容包含了备份和维护数据可用性的资源:
+
+- `MySQL` 企业版客户可以使用MySQL企业备份产品备份。以下为企业备份概览，参见：【章节 30.2, “MySQL企业备份概览”】。
+
+- 一个专用于备份问题的论坛 https://forums.mysql.com/list.php?28.
+
+- `mysqldump` 命令的细节,在这里可以找到 【第4章节 *MySQL程序*】。
+
+- 这里提供了 `MySQL` 语法说明 【第13章节】。
+
+- 关于 `MySQL` 默认表格引擎 `InnoDB` 备份功能的额外信息，参见【章节15.18.1 InnoDB 备份】。
+
+- 复制数据库可以维护多台服务器的可识别数据。它有以下几个优点，比如分散客户端的查询加载到多台服务器，维护特定服务器的可用性即使其下线或者故障， 备份数据而不对数据源产生影响，参见【章节17，*复制服务器*】。
+
+- `MySQL InnoDB` 集群是一组产品集合，提供了一种高可用解决方案。使用 `MySQL Shell` 可以创建集群，配置一组 `MySQL` 服务器。这组集群服务器拥有单点数据源，称为主服务器，它能读写数据。多台从属服务器备份数据。高可用集群至少需要创建三台服务器，一台客户端，用以通过 `MySQL` 路由连接主服务器。如果主服务器故障，从属服务器将自动升级为主服务器，`MySQL` 路由将自动路由请求到新的主服务器。
+
+- `NDB Cluster` 集群提供了在分布式计算环境下的高可用，高冗余 `MySQL` 方案，参见【章节 23, *MySQL NDB 集群 8.0*】。