虽然不能恢复百分百，至少能将损失降到最低。

有个问题测试：

  主从同步时，主库网络断开，binlog dump线程kill掉，然后从库一直是同步状态。

  从库默认有个连接重试的时间，有时重试的时间很长，所以短时间内是不连主库的，此时从库就会显示是正常的状态。

  Seconds_Behind_Master:0 从库落后于主库的秒数。是可以参考的 。

  Slave_IO_Running:YES

  Slave_SQL_Running:YES

  如果报错：Last_Errno：会有一个number值，显示的是MySQL的错误号，从而判断是什么错误

冷备份：需要离线备份，需要关闭服务才能进行备份。生产环境中不适用。

热备份：需要在线备份

逻辑备份：如mysqldump：备份的是SQL语句

物理备份：对磁盘上的数据目录进行打包，拷贝等

主从配置只是备份的一种解决方案。

调优：

   1、底层系统优化，尽可能节省资源。更多的资源交给MySQL处理，

   2、优化数据库运行方式，优化变量，能够运行更高效。

   3、优化数据库线程，如：线程重用技术，从而提高数据库访问效率，线程利用效率。

   4、搭建NoSQL缓存，

衡量数据备份是否合格，2个重要的指标：

  1、RPO 恢复点目标(关注的是恢复数据的程度)

  2、RTO 恢时间目标(恢复数据需要多长的时间)

 生产环境中，不同的备份方式包含的备份指标是不太一样的。

生产环境中常见的备份方式：

  最基本的：

 1、冷备份。

  最简单，也最容易实现。数据目录：/var/lib/mysql(yum安装后的默认位置)，存放了所有数据库文件，以及索引文件等信息。只需要将这个目录下的所有文件，进行拷贝保存，当数据出现问题、需要恢复的时候，只需要：将这个目录拷贝到需要恢复的主机即可。

  然而在生产环境中，这种方式没什么用、因为在生产环境的机器中，都是需要7*24小时在线提供服务的，这种冷备份需要先停机，然后再备份。这样影响了在线的业务，所以这样虽然简单，但只适合特殊的环境，对不间断提供业务的环境这种方式不适合。

 2、快照备份。

  Raid，LVM(逻辑卷，属于热备份支持在线备份。)

  LVM中：LVM快照的功能，如果MySQL安装在的是一个LVM的分区，可以通过快照的功能，将数据文件，数据库、数据表、以及日志文件都通过快照进行备份。

  有个很大的缺点：必须保证要备份的数据文件都存在一个逻辑卷中，然后对这个卷进行快照备份。

  还有一个问题是：只能存放在本地。

 2-1、备份的数据，全部存放在一个逻辑卷中。

 2-2、只支持本地备份。

3、逻辑备份。

  官方的工具，mysqldump,支持默认的数据库存储引擎。相对简单，是通过sql语句备份的。

  问题：备份速度稍慢。(这是一种单线程的备份工具，处理一个升级版：mydumper)

普通文件的数据同步

  1、NFS网络文件共享可以同步存储数据(明文传输的)

  2、samba共享数据

  3、定时任务或守护进程结合rsync,scp。

  4、inotify(sersync) + rsync触发式实时数据同步

  5、ftp数据同步

  6、ssh key + scp/rsync

  7、svn版本管理

  8、rsync,sersync,inotify,union(双向同步)，csync2(多向同步)

MySQL的主从同步不是磁盘上文件直接同步。replication

在主从复制的基础上如何保证数据的完整性：

  1、在主库宕机的时，将主库的bin-log日志拉取，让从库将数据恢复。(百度的支付，游戏支付可能是这么做的)

  2、双向写入数据(占用资源较多)

  3、用程序记录宕机时的所有数据(写一分钟的log，记录到内存中)

  4、将异步同步，该为实时同步。在MySQL上有个谷歌开发的半同步插件。某个半同步从库成功，再向前面报告成功，将这2个主、从绑定到一起，要成功一起成功。先写的主。

MySQL主从复制原理过程：

 1、slave服务器上执行start slave，开启主从复制开关。

2、此时，slave服务器的IO线程会通过在master上授权的复制用户权限请求连接master服务器，并请求从指定Binlog日志文件的指定位置(日志文件名和位置就是在配置主从复制服务时执行change master命令时指定的)，之后发送Binlog日志内容。

 3、master服务器接收到来自slave服务器的IO线程的请求后，master服务器上负责复制的IO线程根据slave服务器的IO线程请求的信息读取指定的Binlog日志 指定位置之后的 Binlog日志信息，然后返回给slave端的IO线程，返回的信息中除了Binlog日志内容外，还有本次返回日志内容后在master服务器端的新的Binlog文件名称以及在Binlog中的下一个指定需要更新位置。

 4、当slave服务器的IO线程获取到来自master服务器上的IO线程发送的日志内容以、日志文件、位置点后，将Binlog日志内容依次写入到slave端自身的RelayLog(即中继日志)文件(MySQL-relay-bin.xxxxxx)的最末端，并将新的Binlog文件名和位置记录到：master-info文件中，以便下一次读取master端新的Binlog日志时能告诉master服务器需要从Binlog日志的哪个文件哪个位置开始请求新的Binlog日志内容。

 5、slave服务器端的SQL线程实时的检测本地RelayLog中新增的日志内容，然后及时的把Log文件中的内容解析成在master端曾经执行的SQL语句的内容，并slave自身按语句的顺序执行应用这些SQL语句，应用完毕后清理应用过的日志。

6、经过了上面的过程，就可以确保在master端和slave端执行了同样的SQL语句。当复制状态正常的情况下，master端和slave端的数据是完全一样的，MySQL的同步机制是由一些特殊情况的。

若从库再作为主时，开启Binlog日志：默认情况下复制过来后直接写入数据库文件，并不写入log-bin，需要修改：log_slave_update后则可以写入。

 1、主库打开log-bin 二进制日志文件

 2、主库授权用户：grant replication slave on *.* to 'rep'@'192.168.88.%' identified by '123123';

   flush privileges; #刷新权限

 3、flush table with read lock;

#设置主库只读模式，暂时不可以写入数据

 3-1、unlock tables; 

#解锁数据表。

 4、备份主库之前的数据：mysqldump -uroot -p123123 -S /data/3306/mysql.sock  -B -events --master-data=2 | gzip > rep.sql

#--master-data=2 #注释create master to 命令。

###mysqldump备份数据之后，再确认主库Binlog日志及位置是否发生变化，如果发生变化则备份是有错误的

  mysqldump -uroot -p123123 -S /data/3306/mysql.sock -A -B --master-data=1 --single-transaction | gzip > all_data.sql.gz

# --single-transaction 数据同步，InnoDB引擎，如果是MyISAM引擎会出现问题，如果是update语句可能会在dump的时候重复执行2次。

master.info文件用于从库的IO线程获取主库的Binlog日志

relay-log.info用于从库SQL线程记录Binlog日志文件及Binlog文件的位置

MySQL主从同步配置步骤：

  1、准备俩台数据库环境，或单台多实例环境，能够正常启动和登录。

  2、配置my.cnf文件，主库配置log-bin和server-id参数，从库配置server-id，不能和主库及其他库一样，一般不开启从库log-bin功能，注意：配置参数后要重启后生效。如果级联主从：则做为从库又是主库的配置文件需要开启：log-bin 和 log-slave-update 后才会正常写入。

  3、登录主库增加用于从库连接主库同步的帐号：

    grant replication slave on *.* to 'rep'@'192.168.88.%' identified by '123123';

  4、登录主库，整库锁表：flush table with read lock(窗口关闭即失效，超时参数到了也失效)，然后：show master status; 查看Binlog日志文件及位置状态。

补充：

5.1版本：flush tableswith read lock

   5.5版本：flush table with read lock

提示：锁表命令的事件，在不同的引擎的情况，会受下面参数的控制，锁表时，如果超过设置时间不操作会自动解锁。

   interactive_timeout=60

   wait_timeout=60

  show variables like '%timeout%';

设置超时时间：

set global wait_timeout=10;

set global interactive_timeout=10;

退出再登录即可查看到修改后的参数。重启服务后会失效。永久设置，在设置后，修改配置文件。

  5、新开窗口，Linux命令行备份或导出原有的数据库数据，并拷贝到从库所在的服务器目录。

    mysqldump -uroot -p123123 -S /data/3306/mysql.sock -A -B --events --master-data=2 | gzip > rep.sql

  6、解锁主库，unlock tables;

  7、把主库导出的原有数据恢复到从库

  8、根据主库的show master status查看binlog的位置状态，在从库执行 change master to...语句。

  9、从库开启同步开关，start slave;

  10、从库 show slave status\G; 查看同步状态，并在主库进行更新测试。

MySQL主从复制原理要点：

  1、异步方式同步

  2、逻辑同步模式，多种模式，默认是通过SQL语句执行。

  3、主库通过记录binlog实现对从库的同步，binlo记录数据库的更新

  4、主库1个IO线程，从库由1个IO线程一个SQL线程来完成的，刚开时候的时候是由主库的主进程负责的，处理完后才交给主库的IO线程的，之后主库的IO，和从库的IO才会进行传输。

5、从库关键文件master.info, relay-log , relay-info 功能。

  6、如果从库需要级联从库，需要打开 log-bin 和 log-slave-updates 参数。

生产场景快速配置MySQL主从复制方案：

  1、安装好配置从库的数据库，配置好log-bin和server-id参数。

  2、无序配置主库my.cnf文件，主库的bin-log和server-id参数默认配置好的。

  3、登录主库增加用于从库连接主库同步的帐号：

    grant replication slave on *.* to 'rep'@‘192.168.88.%’ identified by '123123';

4、使用半夜mysqldump带--master-data=1备份的全备数据恢复到从库。

  5、在从库执行change master to...语句，无需binlog文件及对应位置点。

  6、从库开启同步开关，start slave;

  7、从库show slave status\G;检查同步状态，并在主库进行更新测试。

复制主线程状态：

  下面列出了主服务器的Binlog Dump线程的State列的最常见的状态。如果没有在主服务器上看见任何Binlog Dump线程，说明复制没有在运行，即目前没有连接任何从服务器

  1、Sending binlog event to slave

   二进制日志由各种事件组成，一个事件通常为一个更新加一些其他信息。线程已经从二进制日志读取了一个事件并且正将它发送到从服务器

  2、Finished reading one binlog;switching to next binlog

   线程已经读完二进制日志文件并且正打开下一个要发送到从服务器的日志文件。

  3、Has sent all binlog to slave;waiting for binlog to be updated

   线程已经从二进制日志读取所有主要的更新并且已经发送到了从服务器。线程现在正空闲，等待由主服务器上新的更新导致的出现在二进制日志中的新事件。

  4、waiting finalize termination

   线程停止时发生的一个很简单的状态。

从IO线程状态：

  下面列出了从服务器的I/O线程的State列的最常见的状态。该状态也出现在Slave_IO_State列，由show slave status显示。可以通过该语句仔细浏览所有发生的事情。

  1、Connecting to msater

   线程正视图连接主服务器

  2、Checking master version

   建立同主服务器之间的连接后立即临时出现的状态

  3、Registering slave on master 

   建立同主服务器之间的连接后立即临时出现的状态

  4、Requesting binlog dump

   建立同主服务器之间的连接后立即临时出现的状态。线程向主服务器发送一条请求，索取从请求的二进制日志文件名和位置开始的二进制日志的内容。

  5、Waiting to reconnect after a failed binlog dump request

   如果二进制日志装储请求失败(由于没有连接)，线程进入睡眠状态，然后定期尝试重新连接。可以使用 --master-connect-retry 选项指定重试之间的间隔。

  6、Reconnecting after a failed binlog dump request

   线程正尝试重新连接主服务器

  7、Waiting for master to send event

   线程已经李娜街上主服务器，正等待二进制日志事件到达。如果主服务器正空闲，会持续较长的时间，如果等待持续slave_read_timeout秒，则发生超时。此时，线程认为连接被中断并企图重新连接。

  8、Queueing master event to the relay log

   线程已经读取一个事件，正将它复制到中继日志供SQL线程来处理。

   队列master事件，已经拿到binlog日志，往relay-log文件中塞的过程。

  9、Waiting to reconnect after a failed master event read

   读取时(由于没有连接)出现错误。线程企图重新连接前将睡眠master-connect-retry秒。

  10、Reconnecting after a failed master event read

   线程正尝试重新连接主服务器，当连接重新建立后，状态变为Waiting for master to send event。

  11、Waiting for the slave SQL thread to free enough relay log space

   正使用一个非零relay_log_space_limit值，中继日志已经增长到其他组合大小超过该值。I/O线程正等待，直到SQL线程处理中继日志内容并删除部分中继日志文件来释放足够的空间。

  12、Waiting for slave mutex on exit

   线程停止时发生的一个很简单的状态。

通过查看这些状态，从而指导MySQL工作到什么程度了，主的I/O、从的I/O、从的SQL都处于什么状态，所以当数据不同步的时候可以通过查看这些状态来定位问题。

 通过MySQL线程同步状态查看数据同步是否完成，用于主库宕机或人工数据库主从切换迁移等。

 主库宕机选择最快的从库提升为主，就需要查看，当然也可以利用MySQL的半同步功能，选择固定的库提升为主。

 1、先锁表，停止用户写入数据。flush table with read lock;

 2、查看状态是否已经将二进制文件发送完毕，show processlist;

 3、切换主库。

 4、查看从库是否将主库的binlog日志，全部拉取过来。是否都写入到了从库

复制从SQL线程状态：

  下面列出了从服务器的SQL线程的State列的最常见的状态。

  1、Reading event from the relay log

   线程已经从中继日志读取一个事件，可以对事件进行处理了。

  2、Has read all relay log; waiting for the slave I/O thread to update it 

   线程已经处理了中继日志文件中的所有事件，现在正等待I/O线程将新事件写入中继日志。

  3、Waiting for slave mutex on exit

   线程停止时发生的一个很简单的状态

   I/O线程的State列也可以显示语句的文本。这说明线程已经从中继日志读取了一个事件，从中提取了语句，并且正在执行语句。 

读写分离配置方案：

  中大型公司：通过程序(php,java)实现读写分离

  测试环境：代理软件(mysql-proxy,amoeba)

  门户网站，分布式dbproxy(读写分离，hash负载均衡，健康检查)，一主多从，主从同步

如何实现MySQL主从读写分离：

  1、通过程序实现读写分离(性能，效率最佳，推荐使用)

   php和Java程序都可以通过设置多个连接文件轻松的实现对数据库的读写分离，即当select时，就去连接读库的连接文件，当update,insert,delete时就连接写库的连接文件。

  2、通过软件实现读写分离

   MySQL-proxy，Amoeba等代理软件也可以实现读写分离功能，但最好的还是程序实现读写分离。

  3、开发dbproxy，不对外，大户都是内部使用的。 

MySQL自带的备份命令，mysqldump

语法：mysqldump -u 用户名 -p 数据库名 > 备份的文件名.sql

 mysqldump testdata > bak.sql

#对数据库testdata进行备份。 

 mysql data1 < bak.sql

#恢复的时候需要指定数据库，恢复备份数据库中的数据表。

##如果还原的是数据库，则不需要指定 数据库名称。

 mysqldump data1 t1 > backt.sql

#只备份了data1数据库中的 t1 数据表。恢复同上。

 mysqldump --database data1 data2 > databak.sql

#同时备份数据库data1,data2，需要用--database指定备份的是数据库。

 mysqldump --all-database > alldata.sql

#备份数据库管理系统中的所有数据库。恢复删除掉的。

区别：

 mysqlhostcopy: 可以实现MySQL在某些情况下，能够实现MySQLdump不方便做的一些功能，如：备份所有以A开头的数据库，可以很好的和正则表达式集合起来用。

  是快速文件意义上的备份，相当于cp命令，但比cp效率高很多。

  只能在本地操作。

  copy备份文件到数据目录覆盖即可。

  只支持MyISAM存储引擎

 mysqldupm:

  是一个数据库端的sql语句的集合，里面全都是sql语句。

  可以远程操作(最终的备份文件，还是存放在原服务器上的)

  还原时，导入SQL文件。

  支持MyISAM和InnoDB存储引擎

俩者支持的存储引擎不同，安装时候的条件不一样，操作的方法不一样，

共同点：

  在做操作的时候，都要执行锁表的操作(行级锁，表级锁，页级锁)

 mysqlhostcopy --flushlog --regexp=^a /backup

#如果数据库中没有备份的内容则会报错

# --flushlog必须加的，用来刷新日志系统。--regexp=指定备份什么样的数据库

场景：

   mysqldump + 计划任务 在凌晨1点备份，然而3点的时候，需要恢复数据，也就是1点到3点之间的数据没有了。这时候就需要 ： 二进制文件备份。(利用的是MySQL中提供的日志功能来进行备份的)

MySQL中的日志：

   网站一般有2个日志文件：一个访问日志，一个错误日志

   FTP：一个日志文件。

   数据库：有多个日志文件。错误日志，一般查询日志，慢查询日志，二进制日志，事务日志等。

show global variables like '%log%';

# 在MySQL中所启动的日志相关的一些变量。

binlog开头的二进制日志信息。

innodb开头的事务日志。

general_log：查询日志。也叫一般查询日志的日志信息。

relay_log： 中继日志

log_slow_gueries: 有slow的属于慢查询日志。

错误日志的信息：

 show global varibales like 'log_error';

#查看错误日志信息位置。

  1、服务器在启动和关闭过程中一些信息，运行过程中产生的一些错误信息也会记录

  2、主从联机的时候，从服务器上产生的一些信息，也会存放到主服务器的错误日志中，

修改日志文件位置：修改主配置文件： my.cnf 在[mysqld_safe]模块下

一般查询日志：

  记录对数据库的查询操作，如：select、show。

  general_log：设置一般查询日志是否需要开启，默认是OFF关闭状态。

为什么默认是关闭的：比如：电商网站，在高并发查询商品的时候都会记录下来，从而日志增加非常快，并且记录用户查询商品的记录没有多大意义。

  这也可以得到用户的一些操作习惯，分析用户的购物需求，这些不是通过数据库的查询日志实现的，是通过会话实现的

  general_log_file：设置一般查询日志的默认存放位置

开启查询日志文件： 在主配置文件：my.cnf中[mysqld]模块下：log=ON.即可。修改配置文件需要重启服务才会生效。

一般查询日志保存的类型：

  show global variables like 'log_output';

#value对应的值是：FILE。这个值可以改成table，这样会一般日志在保存信息的时候不是存在文件里，而存到数据库中。以数据表的形式记录日志的信息。

  一般查询日志在生产环境中不打开，是为了节省服务器的资源。

慢查询日志：

   为什么会查询慢？ 服务器性能达到瓶颈，网络出现延迟，数据库表结构应该优化，数据量过大等原因。

从而导致查询某条信息时，时间过长，这样的信息都应该保存起来，

log_slow_queries OFF: 默认是没有开启的。

打开，主配置文件中添加：[mysqld]模块下：

log-slow-queries=/var/slow/mysql-slow.log

重启服务，使配置文件生效。

查询慢的条规定设定的时间：

show global variables like '%long%';

#long_query_time：mysql默认的一个时间，如果达到设置的事件还没有响应的话，就人为这是一个慢查询

  修改主配置文件：

打开主配置文件：my.cnf [mysqld]模块下添加：

 long_query_time=2 #设置超过2秒记录到慢查询日志，单位秒。

二进制日志：

   如果只是用逻辑备份：mysqldupm + 计划任务,是没办法满足生产环境中数据重要性备份的需求的。

所以需要通过二进制日志文件，对其进行一个补充，

特点：

  会记录所有更改数据库状态的SQL操作。如：create 、drop、update

查询二进制日志文件是否开启：

  show global variables like '%log%';

#log_bin 表示二进制日志的一个状态，默认是OFF，

打开二进制文件：

修改主配置文件，

 在[mysqld]模块中：log-bin=mysql-bin。指定一下二进制文件即可开启二进制日志。

  查看正在使用的二进制日志：

show binary logs;

#可以看到正在使用的二进制日志的文件名叫什么。后面的序号：00001表示使用的是第一个二进制文件

#file size：表示文件的大小。

查看这个二进制文件的内容：

 show binlog events in 'mysql-bin.00001';

#查看正在使用的二进制文件里面的内容。在数据目录下

#log_name: 文件名

#Pos: 起始大小(记录某个信息之前的大小，KB)

#Event_type: 日志文件的格式

#Server_id: 服务器默认分配的一个ID号。

#End_log_pos：结束的大小。(记录完以后的大小，KB)

#Info: 记录的信息。记录的是更改数据时的命令SQL语句

  用二进制管理工具，查看二进制日志文件：

 mysqlbinlog mysql-bin.000001

二进制日志文件恢复时候，指定恢复的范围：

 1、通过事件指定还原范围

   mysqlobinlog --start-datetime '2013-11-22 2:52:52' --stop-datetime '2013-11-22 2:55:44' mysql-bin.000001 | mysql -uroot -p

#这个命令实在数据目录下执行的。

 2、通过大小指定还原范围

   mysqlbinlog --start-position 264 --sopt-positon 341 mysql-bin.000001 | mysql -uroot -p 

二进制文件：

  ‘/*!*/’ 作为分割，at 106:记录的是文件的大小，第三行是：记录的时间。

通过大小，或时间都可以将数据恢复。

二进制日志指定数据库导出SQL语句：

  mysqlbinlog -d dbname mysql-bin.000002 > dbname.sql

# -d 截取指定库的binlog文件SQL文件。

#从而可以指定需要恢复数据的数据库，进行数据恢复。

二进制日志文件，指定位置点恢复：

  mysqlbinlog mysql-bin.000002 --start-position=365 --stop-position=465 -r pos.sql

# -r : 相当与是重定向

#导出的SQL语句是 365到465之间的SQL语句

二进制日志文件，指定时间点恢复：

  mysqlbinlog mysql-bin.000002 --start-datetime='2017-10-16 17:14:16' --stop-datetime='2017-10-16 17:15:20' -r time.sql

# -r : 相当于是重定向

#导出的SQL语句，都是在指定时间段内的

# 这个时间不一定对应上当时需要恢复数据的时间，可以是早些的时间：2017-10-16 17:14:10 

--master-data

  这个值 =1 时：下面的语句是没有注释掉的

  这个值 =2 时：下面的语句是由注释掉的 --:表示注释

change master to master_log_file='mysql-bin.000002',master_log_pos=1191;

mysqldump + 计划任务 + 二进制日志文件

 二进制文件虽然能帮助备份数据库中的一些操作，然而还原的时候还是比较麻烦的，

更倾向于实时的备份方式。

完美备份方案： 主从数据备份是单向的。只可以主同步到从，反之是不可以的。

 多机配置之主从设置。

主服务器提供给用户访问及操作。

从服务器：用户无法访问，仅用来备份主服务器产生的数据。

从服务器作用：备份用户访问主服务器时操作所产生的所有的数据。

设置后：主服务器会打开一个线程(I/O)，在从服务器上打开2个线程(I/O SQL).

如果一个用户访问了主服务器，提交了一个SQL请求，创建一个数据(create database aa;),这个请求会交给主服务器上的I/O线程，这时查询管理其和存储管理器就开始工作，会分析用户的这次请求，解析语法，解析完这个语法后将这个语法执行出来，执行完以后就会产生一个结果，这个结果分俩部分保存：

  第一部分：用户提交的这个操作是个SQL语句，(所有更改数据的操作都会存到二进制日志文件中，时间越长二进制日志文件就会越多，所以需要有一个索引文件来管理这二进制日志文件，索引文件：mysql-bin.index)。用户提交的请求会记录到本机的二进制文件中，执行后会在数据目录中产生对应的数据库目录(这个操作也是由线程提交过来的 )

  在主从环境下，会实时的将数据备份给从服务器，(怎么传给从服务器数据，是以什么样的方式保存的)

主服务器对从服务器做授权操作 grant replication slave 表示：授权某一个主机，可以来这里同步数据(授权一个用户，密码，权限 来访问)。管理员在从服务器上生成一个文件，Master.info:这个文件由管理员输入的(记录了：登录主服务器所需要的信息，这些信息由管理员通过：change master to挨个写入，包括：(下有案例)

      Master_host：服务器IP地址多少。

      Master_user: 服务器授权的用户名。

      Master_passwd: 服务器授权的密码多少。

      Master_log_file: 服务器正在使用的二进制文件)

      Master_log_pos: 二进制文件是从哪里开始使用的

##可以生成master.info的登录信息。

这些信息都是由管理员给从服务器输入的。输入完以后会在从服务器的数据目录下生成一个Master.info的文件。将信息记录在里面。

  从而，从服务器就可以通过里面记录的授权信息，用这些授权信息，尝试连接主服务器，通过从服务器的I/O线程，向主服务器的I/O线程发起连接。

在主从环境中，为了让同步更加高效，是将主服务器上的二进制日志文件，传给从服务器，所以给从服务器的是二进制文件。

当从服务器拿到这个二进制文件后，会在从服务器上也生成一个文件，Relay-bin.000001这样的文件(中继日志文件，也就是完整拷贝了主的二进制日志文件中的信息)。从而记录下主服务器上的一些用户的操作，记录在从服务器中的中继文件中，这时候的从服务器的I/O线程就会通知另外一个线程工作，通知SQL线程，SQL线程会读取中继文件中的所有内容，并且将其中的内容完整的执行一遍，从而从服务器也会在本地的数据库中做出对应的操作，

需要主从都开启二进制文件记录：

  主配置文件： [mysqld]

 模块下添加：

log-bin=mysql-bin  #开启二进制日志文件记录

server-id=251   #区分主从服务器的身份，一般是IP地址的最后一位

show global variables like '%log_bin%';

#主从都需要，查看二进制文件：log_bin 是否ON。

登录到主服务器的数据库系统中：

  grant replication slave on *.* to slave_user@'从服务器IP地址' identified by '123123';

#授权从服务器可以通过用户：slave_user，用密码：123123等录，对任何数据

  show master status;

#查看当前数据库服务正在使用的二进制日志文件的，文件名以及大小

在从服务器上指定主服务器授权的权限：登录到数据库操作

  change master to master_host='主服务器IP地址',

     master_user='slave_user',

     master_password='123123',

     master_log_file='mysql-bin.000001', #这个参数需要查看主服务器

     master_log_pos=262; #这个参数需要查看主服务器

执行后就会在从服务器的数据目录文件下产生一个：master.info的配置文件。

  start slave;

#打开从服务器功能 登录到数据库操作 

  show slave status\G;

#查看从服务器状态 

2-1、mysqldump -B

  提示：-B参数表示接多个库，并且增加use db,和create database db的信息。

  生产环境：

     -B   --database

  -B参数的作用：后指定多个数据

    mysqldump -uroot -p123123 -B dbname > /backup/dbnam_B.sql

  a)导出的语句会有一个创建数据库的语句，使用数据库的语句。

     mysql -uroot -p123123 < /backup/dbname_B.sql #可以直接导入，不用指定数据库名

  b)-B后指定多个数据库备份。

2-2、mysqldump的--compact参数：可以减少输出，输出让容量更少，只适合调试用。

   options:

     --skip-add-drop-table

     --no-set-name

     --skip-disable-keys

     --skip-add-locks

因为有了这些参数，所以--compact参数不安全

2-3、mysqldump压缩备份

   mysqldump -uroot -p123123 -B dbname | gizp > /backup/dbname.sql.gz

备份数据时 mysqldump 工具时：

 1、导出数据用 -B 参数

 2、管道符 gzip 进行压缩

 3、-d : 备份表结构

   mysqldump -uroot -p123123 -d dbname tblname;

 4、-t : 只备份数据

   mysqldump -uroot -p123123 -t dbname tblname;

 5、备份所有数据库和表：-A

   mysqldump -uroot -p123123 -A -B --events | gzip > /backup/db_all.sql.gz

 6、切割bin-log日志：-F

 7、备份bin-log日志的位置：--master-data=1

    --master-data=2 时：会在前面加注释。

 8、--compact 去掉注释，适合调试输出，生产不用。

一般的MyISAM引擎就是锁表，锁表后是不能操作，也不能访问的

 9、-x,--lock-all-talbes 在备份数据的时候一般都是要锁表的，从而保证数据的一致性。

 10、-l,--locak-tables 只读锁表

 11、--single-transaction 适合innoDB事务数据库备份

   InnoDB表在备份时，通常启用选项 --single-transaction 来保证备份的一致性，实际工作原理是设定本次会话的隔离级别为：REPEATABLE READ，保证本次会话(dump)时，不会看到其他会话已经提交了的数据。 

生产环境MyISAM引擎备份数据：

 备份命令：

  mysqldump -uroot -p123123 -A -B --master-data=2 -x --events | gzip > /backup/all_db.sql.gz

生产环境InnoDB引擎备份数据：工作中推荐使用InnoDB引擎。

 备份命令：

  mysqldump -uroot -p123123 -A -B --master-data=2 --single-transaction --events | gzip > /backup/all_db.sql.gz

如果2种引擎都有，以MyISAM引擎为主

--triggers : 触发器

--routines : 存储过程

分库备份：主要是为恢复数据时方便，恢复小数据库时候很快

  mysql -uroot -p123123 -e "show databases;" | grep -Evi "database|info|perfo" sed -r "s#^([a-z].*$)#mysqldump -uroot -p123123 --events -B \1  | gzip > /backup/\1.sql.gz#g" | bash

#要注意，命令的每个参数之间必须要有空格分割

##命令行备份多个数据库

mysqldump备份的是SQL语句，属于逻辑备份

命令行for循环：

gz文件解压的文件是需要先解压再批量导入的。

  for dbname in `ls *.sql | sed "s#_back.sql##g"` ; do mysql -uroot -p123123 < ${dbname}_back.sql ;done