一、数据备份
数据备份的主要作用是当误操作发生时，可以将数据回退到某个时间点。
数据备份根据备份数据的范围可以分为：
1、完全备份：备份整个数据库；
2、部分备份：备份部分数据，比如备份数据库中的某一张表。部分备份又细分为：
1）增量备份：从上一次 备份（完全备份或增量备份）时间开始以来变化的数据；
2）差异备份：从上一次完全备份以来变化的数据；
数据备份根据备份时是否影响数据库读写可以分为：
1、热备份：当对数据库进行备份时，该数据库的读写操作不受影响；
2、温备份：当对数据库进行备份时，该数据库的读操作可以执行，但不能进行写操作；
3、冷备份：当对数据库进行备份时，该数据库不能进行读写操作，即需要停数据库；
mysql支持哪种备份方式，还跟存储引擎有关：
| 引擎类型 | 热备份 | 温备份 | 冷备份 |
|---|---|---|---|
| MyISAM | × | √ | √ |
| InnoDB | √ | √ | √ |
数据备份根据备份方式可以分为：
1、物理备份：通过操作文件达到备份目的，比如使用tar，cp等命令打包备份数据库中的数据文件，比如拷贝mysql的data目录下的数据文件，在拷贝之前执行FLUSH TABLES WITH READ LOCK阻塞往数据库中写入数据再拷贝，拷贝完成后使用UNLOCK TABLES解除锁定；
2、逻辑备份：一般是使用特定工具从数据库中导出某种格式的数据文件。常用的有：
1>mysqldump工具，比如：
mysqldump -h11.33.156.333 -P3306 -uroot -proot123 --skip-lock-tables --quick dbname tablename > filename.sql2>mysql工具，优点是可以使用DQL语句指定导出符合条件的记录以及指定导出指定的列，但注意需要在my.cnf的mysqld中开启secure_file_priv属性，该属性指定了要导出的文件所在目录，否则会报错没有权限。比如：
mysql -h11.33.156.333 -P3306 -uroot -proot123 dbname -e "select col1,col2 from tablename into outfile '/home/work/doc/filename.sql'"二、恢复数据
这里主要介绍使用二进制日志恢复数据。
1、binlog二进制日志常用命令：
1）show master logs;显示所有binlog二进制日志列表；
2）show master status;显示master状态，即最新binlog日志的名称，及最后一个操作事件pos结束点(Position)值；
3）flush logs;产生一个新编号的binlog日志文件作为最新的二进制日志，每当mysqld服务重启时，会自动执行此命令，刷新binlog日志。在mysqldump备份数据时加-F 选项也会刷新binlog日志；
4）reset master;删除所有index file中记录的所有binlog 文件，将日志索引文件清空，创建一个从000001开始的新日志文件。
2、binlog二进制日志不能用普通的文本查看工具查看，需要使用mysqlbinlog查看，指定参数--base64-output=DECODE-ROWS会显示出row模式带来的SQL变更，指定参数-v会显示出statement模式带来的SQL变更，如果指定-vv则在SQL语句中显示字段类型。
也可以在mysql命令行执行：show binlog events [IN 'log_name'] [FROM pos] [LIMIT [offset,] row_count]进行查看。
3、使用mysqlbinlog [IN 'log_name'] | mysql -uusername -ppasswd恢复指定二进制文件中的变化，实际上就是使用mysqlbinlog将二进制日志的内容读取出来交给mysql进行执行。
三、主从复制
主从复制的主要作用是实现读写分离，当主数据库服务器挂掉后，可以使用从服务器，从而使业务不受影响。
1、主从复制原理：
1）主库的数据发生变化时，将变化记录在二进制日志bin-log中，同时发送event事件给从库；
2）从库的IO线程读取主库中的bin-log日志，放在自己的中继日志relay-log中；
3）从库启动SQL线程执行中继日志relay-log中的操作，更新数据与主库数据保持一致。
注意：
1）一个从库只能有一个主库；
2）每个服务器都有一个唯一的server-id和uuid，server-id在my.cnf中配置，uuid存放在data目录下的auto.cnf文件中；
3）变化的数据记录是记录在二进制bin-log中的，所以需要开启记录二进制日志；
4）如果主从复制过程中发生错误，比如主库删除一条记录，在从库删除时未找到这条记录报错了，那么整个主从复制停止。所以也不会轻易只修改从库数据，因为如果从库数据与主库数据不一致很可能导致主从复制中断；
5）如果网络中断后又恢复，主从复制会继续；
6）如果设置log_slave_updates=1，当从库是其它从库的主库，从而扩散自己从主库得到的更新到其他从库。
2、主从复制方式：
1）基于语句的复制：在主服务器上执行的SQL语句，同样地在从服务器上执行一次。主从复制默认采用这种方式，效率比较高，占用空间比较小；
2）基于行的复制：把改变的数据一行一行复制过去，从mysql5.0开始支持，用于弥补基于语句的复制中部分数据变动无法更新的缺点，占用空间比较大；
3）混合模式的复制：默认采用基于语句的复制，当基于语句的方式无法复制时就采用基于行的复制。
3、主从配置常见的拓扑结构：
MySQL不支持多主服务器复制(Multimaster Replication)——即一个slave可以有多个master。但是，通过一些简单的组合，我们却可以建立灵活而强大的复制体系结构。
由一个master和一个slave组成复制系统是最简单的情况。Slave之间并不相互通信，只能与master进行通信。如下：
如果写操作较少，而读操作很时，可以采取这种结构。你可以将读操作分布到其它的slave，从而减小master的压力。但是，当slave增加到一定数量时，slave对master的负载以及网络带宽都会成为一个严重的问题。
这种结构虽然简单，但是，它却非常灵活，足够满足大多数应用需求。一些建议：
(1) 不同的slave扮演不同的作用(例如使用不同的索引，或者不同的存储引擎)；
(2) 用一个slave作为备用master，只进行复制；
(3) 用一个远程的slave，用于灾难恢复；
2）主动模式的Master-Master(Master-Master in Active-Active Mode)
Master-Master复制的两台服务器，既是master，又是另一台服务器的slave。如图：
主动的Master-Master复制有一些特殊的用处。例如，地理上分布的两个部分都需要自己的可写的数据副本。这种结构最大的问题就是更新冲突。假设一个表只有一行(一列)的数据，其值为1，如果两个服务器分别同时执行如下语句：
在第一个服务器上执行：
mysql> UPDATE tbl SET col=col + 1;
在第二个服务器上执行：
mysql> UPDATE tbl SET col=col * 2;
那么结果是多少呢？一台服务器是4，另一个服务器是3，但是，这并不会产生错误。
实际上，MySQL并不支持其它一些DBMS支持的多主服务器复制(Multimaster Replication)，这是MySQL的复制功能很大的一个限制(多主服务器的难点在于解决更新冲突)，但是如果你实在有这种需求，你可以采用MySQL Cluster，以及将Cluster和Replication结合起来，可以建立强大的高性能的数据库平台。但是，可以通过其它一些方式来模拟这种多主服务器的复制。
3）主动-被动模式的Master-Master(Master-Master in Active-Passive Mode)
这是master-master结构变化而来的，它避免了M-M的缺点，实际上，这是一种具有容错和高可用性的系统。它的不同点在于其中一个服务只能进行只读操作。如图：
4）带从服务器的Master-Master结构(Master-Master with Slaves)
这种结构的优点就是提供了冗余。在地理上分布的复制结构，它不存在单一节点故障问题，而且还可以将读密集型的请求放到slave上。
4、主从复制配置步骤：
1）在主服务器的my.cnf的mysqld中增加配置：
server-id = 1
log-bin = /home/work/yun1/mysql/log/master-bin-log
binlog-format = MIXED
expire_logs_days = 1其中：server-id标识服务器的唯一性，确保主从服务器的server-id不能重复；
log-bin指定开启二进制日志，并指定二进制日志放置的目录；
binlog-format指定主从复制的方式，这里指定混合模式；
expire_logs_days指定二进制文件保存的天数，这里设置为1，表示1天之后生成的二进制日志自动清理，否则二进制日志会越积越多；
可以执行reset master命令删除所有index file中记录的所有binlog 文件，将日志索引文件清空，创建一个新的日志文件，这个命令通常仅仅用于第一次用于搭建主从关系的时的主库。将master的binlog重置为从000001开始记录，slave不能是运行状态才能执行。
2）在从服务器的my.cnf的mysqld中增加配置：
server-id = 2
relay-log = /home/work/yun1/mysql_slave/log/relay-bin-log
relay_log_purge = 1
read_only = 1其中：server-id标识服务器的唯一性，确保主从服务器的server-id不能重复；
relay-log指定开启中继日志，并指定中继日志放置的目录；
relay_log_purge指定中继日志被从服务器的SQL线程使用之后就自动清理掉，否则中继日志会越积越多；
read_only设置从库除了从服务器的SQL线程修改数据、以及有超级管理权限的用户修改数据外，其他情况都只允许只读，避免从库和主库数据不一致导致主从复制失败。
可以执行reset slave命令删除master.info文件和relay-log.info文件以及所有的relay log文件并重新启用一个新的relaylog文件。使用reset slave之前必须使用stop slave 命令将复制进程停止。
3）主从服务器修改配置文件后重启，在主服务器中查看主库信息；
4）在从服务器中指定要从这个主库复制，这些信息最终默认会保存在data目录中的master.info中。执行show slave status\G，可以看到Slave_ID_Running和Slave_SQL_Running状态都是No；
其中：MASTER_HOST为主库的ip；
MASTER_PORT为主库的端口；
MASTER_USER为主库中为从库复制使用创建的账号；
MASTER_PASSWORD为主库中为从库复制使用创建的账号的密码；
MASTER_LOG_FILE为从库IO线程要读取的二进制文件名，注意不需要完整的路径，只需要写文件名即可，否则IO线程是会启动失败；
MASTER_LOG_POS为从库IO线程要读取的二进制文件的起点位置。
5）执行start slave，然后执行show slave status\G，可以看到Slave_ID_Running和Slave_SQL_Running状态已变为Yes，说明主从复制已启动，只要主库有任何变更，都会将变化同步到从库，这个过程或多或少都会存在一定的延时。
6）在主库中对数据进行变动后，执行show processlist\G，可以看到状态是：已将二进制日志发给了从库。
7）在从库执行show processlist\G，可以看到从库进行了更新操作；
8）更新操作完成后在从库再次执行show processlist\G，可以看到从库此时等待主库的下一个更新；
如果主从复制失败，还可以使用set GLOBAL SQL_SLAVE_SKIP_COUNTER=N，跳过N个中继日志中的语句。执行之前要先使用stop slave停止复制，执行后再使用start slave启动复制。