MySQL-5.7.7复制功能的默认设置改进

      Binlog_gtid_simple_recovery=TURE(默认值)      这个参数控制了当mysql启动或重启时，mysql在搜寻GTIDs时是如何迭代使用binlog文件的。      这个选项设置为真，会提升mysql执行恢复的性能。因为这样mysql-server启动和binlog日志清理更快。该参数为真时，mysql-server只需打开最老的和最新的这2个binlog文件，gtid_purged参数的值和gtid_executed参数的值可以根据这些文件中的Previous_gtids_log_event 或者 Gtid_log_event计算得出。这确保了当mysql-server重启或清理binlog时，只需打开2个binlog文件。       在MySQL-5.6中，调整这个选项设置也同样会提升性能，但是在一些特殊场景下，计算gtids值可能会出错。而保持这个选项值为false，能确保计算总是正确。       在MySQL-5.7.7中，几乎不需要在速度和安全性之间做权限。设置该选项为TRUE总能得到正确的结果，除了以下2个极端场景：       a． 最新的binlog是MySQL-5.7.5(或更老版本)产生的，并且gtid_mode对一些binlog设置为ON，但是对最新的binlog设置为OFF.       b． GTID_PURGED的状态是MySQL-5.7.7之前的版本发布的，并且在当时激活清理的binlog在当前仍然没有清理完成。       因此，开启这个选项几乎总是更好一些，所以这个选项默认开启。       如果这个参数设置为off，在mysql恢复期间为了初始化gtid_executed，所有以最新文件开始的binlog都要被检查。并且为了初始化gtid_purged，所有的binlog都要被检查。这可能需要非常长的时间。

       Binlog-format=ROW(默认值)       当开启binlog并且binlog格式设置为ROW模式时，每张表的行变动被写到binlog文件中，然后这些变动在从库端应用。这和使用statement格式binlog是不同的。在STATEMENT格式下，binlog会在从库端重新执行。       所有的数据库变动都能被复制并且这是最安全的复制方式。同基于statement的复制相比，基于row的复制需要的行级锁定更少。在先前的默认statement格式下，不确定的状态可能会造成主从不一致的问题。

      Binlog_error_action=ABORT_SERVER      Binlog_error_action参数控制当不能写binlog时，mysql-server将会采取什么行动。      设置binlog_error_action=ABORT_SERVER会使mysql-server在写binlog遇到严重错误时退出，比如磁盘满了，文件系统不可写入了等。在ABORT_SERVER选项下，binlog和从库都是安全的，这是官方修改此默认值的原因。      在先前的选项下（binlog_error_action=IGNORE_ERROR），如果一个错误发生，导致无法写入binlog，mysql-server会在错误日志中记录错误并强制关闭binlog功能。这会使mysql-server在不记录binlog的模式下继续运行，导致从库无法继续获取到主库的binlog。

       MySQL崩溃时的binlog安全是sync_binlog参数控制的，这个参数的值代表了在把binlog刷新到磁盘前，提交的组的数量。       当sync_binlog=1时，所有的事务都在提交前写入binlog。因此即使binlog事件遇到意外重启，一些在prepared状态的binlog会丢失。这导致服务器在恢复数据时自动回滚这些事务。这确保了从binlog不丢失事务，因此是最安全的选项。事实上，这增加了同步到磁盘的总次数。但是从MySQL5.6开始，已经支持组提交和合并同步了，这使得出现性能问题的可能性最小化了。       当sync_binlog=0时，mysql-server并不把binlog同步到磁盘，而是依赖操作系统把binlog的内容同步到磁盘。因此，当出现掉电或操作系统崩溃时，很可能出现已经提交的事务没有被同步到磁盘的情况。因此mysql在自动恢复时无法恢复这些事务，他们从binlog中丢失了。

      Slave_net_timeout定义了从库从主库获取数据等待的秒数，超过这个时间从库会主动退出读取，中断连接，并尝试重连。这个参数还影响了主从库之间心跳测试的频率，这个频率的默认值是slave_net_timeout除以2.      Slave_net_timeout新的默认值是60，此前的默认值是3600秒。在老值下，长时间的复制延迟很可能是网络瞬断造成的。

    ‘@@global.gtid_executed’ 变量包括了所有记录在binlog中的事务的集合。       当使用这个变量的会话级值时，他代表了写入事务缓存中的值。Session.gtid_executed只有在gtid_next是UUID：NUMBER并且至少一个DML语句已经被执行却没有提交时才同UUID:NUMBER的值相等。当GTID_NEXT 被设置为其他值是，session . GTID_EXECUTED包含一个空字符串。在MySQL5.7.7中如果使用这个会话级的变量会触发一个警告。对这个变量的全局级（@@global.gtid_executed）没有任何变化,因为这个参数使用频率更高并且当用户忘记提及global关键词时，他们会得到这个变量的会话级值，这个值很可能是不正确的。为了避免这个问题，我们取消了这个变量的会话级设置，同时也因为这个参数在应用中没有任何已知的价值。因此我们把他取消掉了。

MySQL-5.7.7复制功能的默认设置改进

标签：exe   sim   参数设置   版本发布   使用   false   mysql5.6   打开   读取   

小编还为您整理了以下内容，可能对您也有帮助：

mysql5.7数据库默认值开关在哪

MySQL 5.7数据库默认值选项的开关为“sql_mode”，它可以通过MySQL配置文件my.cnf中的“sql-mode”参数来设置。在MySQL 5.7中，默认情况下，sql_mode参数被设置为“NO_ENGINE_SUBSTITUTION, STRICT_TRANS_TABLES”，这意味着默认值不会被忽略，并且如果有任何数据违反列的定义，则会抛出错误。如果您想更改这个默认行为，您可以在my.cnf文件中将sql_mode参数设置为其他值。在MySQL 5.7之前的版本中，默认启用了MySQL非标准的“严格模式”，以严格遵守SQL标准和数据完整性。在5.7版本及更高版本中，“严格模式”将不再是默认行为，但仍然可以启用。

mysql5.7数据库默认值开关在哪

MySQL 5.7数据库默认值选项的开关为“sql_mode”，它可以通过MySQL配置文件my.cnf中的“sql-mode”参数来设置。在MySQL 5.7中，默认情况下，sql_mode参数被设置为“NO_ENGINE_SUBSTITUTION, STRICT_TRANS_TABLES”，这意味着默认值不会被忽略，并且如果有任何数据违反列的定义，则会抛出错误。如果您想更改这个默认行为，您可以在my.cnf文件中将sql_mode参数设置为其他值。在MySQL 5.7之前的版本中，默认启用了MySQL非标准的“严格模式”，以严格遵守SQL标准和数据完整性。在5.7版本及更高版本中，“严格模式”将不再是默认行为，但仍然可以启用。

MySql怎么给列设置默认值 mysql修改默认值

Mysql数据库的好处我就不多说了，本咗嚛针对平时常见的一个问题。Mysql新建的表怎么给列设置默认值，简单提供几个常见的情况希望能帮到小伙伴。

命令语法如下 createtable表名(列名称数据类型default默认值);

如果图形化界面操作，如phpmyadmin的话，一般直接默认值就可以设置选择呢

命令行界面 若本身存在默认值，则先删除 altertable表名altercolumn字段名dropdefault;

然后设置默认值（若本身不存在则可以直接设定） altertable表名altercolumn字段名setdefault默认值;

再次返回表的结构视图，你会发现如下图。刚刚设置的默认值已经更新了

图形界面操作修改 图形界面操作设置就非常简单了，直接编辑表的结构点击需要修改的列即可。

如下图打开找到默认值一般都有无，和自定义等选项

mysql5.6和5.7的区别是什么?

mysql5.7是5.6的新版本，在没有减少功能的情况下新增了功能与进行了优化，例如新增了新的优化器、原生JSON支持、多源复制，还优化了整体的性能、GIS空间扩展、InnoDB。

1、原生json支持

MySQL 5.7可以定义原生json类型数据，对json数据进行有效性检查，查询不需要遍历所有字符串才能找到数据，通过虚拟列的功能可以对JSON中的部分数据进行索引。

2、多源复制

MySQL 5.7开始支持多源复制，也就是多主一从的复制架构。各个库汇总在一起，就算是其他库都挂了（整个机房都无法连接了），还有最后一个救命稻草。不需要每个库都做一个实例，也减少了DBA的维护成本。

3、InnoDB优化

MySQL 5.7针对innodb_buffer_pool_size、innodb_log_file_size、innodb_flush_method提供了更加合适的默认值。

参考资料来源：MYSQL-MySQL 5.7的新增功能

mysql5.6和5.7的区别是什么?

mysql5.7是5.6的新版本，在没有减少功能的情况下新增了功能与进行了优化，例如新增了新的优化器、原生JSON支持、多源复制，还优化了整体的性能、GIS空间扩展、InnoDB。

1、原生json支持

MySQL 5.7可以定义原生json类型数据，对json数据进行有效性检查，查询不需要遍历所有字符串才能找到数据，通过虚拟列的功能可以对JSON中的部分数据进行索引。

2、多源复制

MySQL 5.7开始支持多源复制，也就是多主一从的复制架构。各个库汇总在一起，就算是其他库都挂了（整个机房都无法连接了），还有最后一个救命稻草。不需要每个库都做一个实例，也减少了DBA的维护成本。

3、InnoDB优化

MySQL 5.7针对innodb_buffer_pool_size、innodb_log_file_size、innodb_flush_method提供了更加合适的默认值。

参考资料来源：MYSQL-MySQL 5.7的新增功能

MySql怎么给列设置默认值 mysql修改默认值

1、首先新建一张表结构。

2、select * from t_temp_test 查看下这张表已经建好在数据库里面了。

3、查看该t_temp_test表结构  sp_help t_temp_test,可以看到字段column_b 的默认值定义为空，默认属性是DF__t_temp_te__colum__19DA45DB。

4、修改表的默认值先要把表的默认属性删除了才能修改,删除表的默认属性。

5、删除之后再执行sp_help t_temp_test，这个时候默认值属性已经被删除了的。

6、然后再重新给字段新加上默认属性alter table t_temp_test add constraint DF__t_temp_te__colum__19DA45DB DEFAULT (('123')) for column_b。

7、执行完毕再查询表结构sp_help t_temp_test可以看到表的默认值已经被更改为字符串‘123’。

mysql ab复制有哪些模式

        mysql复制在业界里有叫：mysql同步，ab复制等。专业名称就是叫：复制。复制是单向的异步复制，从一个Mysql（Master）复制到另一个Mysql(Slave)。实现整个主从复制，需要由Master服务器上的IO进程，和Salve服务器上的Sql进程和IO进程共同完成。

        要实现主从复制，首先必须打开Master端的二进制日志（bin-log）功能，因为整个Mysql复制过程实际上就是Slave从Master端获取相应的二进制日志文件，然后在根据相应的Position号在自己Slave端完全的执行日志中所记录的各种操作，（二进制日志文件是用sql语句写成的所以可以直接在Slave机上直接执行）。

        主从复制的基本过程如下：

        1、Mysql Slave端的IO进程链接上Master，向Master请求指定日志文件的指定位置（或者从最开始的日志）之后的日志内容；

        2、Master接受来自Slave的IO进程的请求后，负责复制的IO进程根据Slave的请求信息，读取相应日志内容，返回给Slave 的IO进程。并将本次请求读取的bin-log文件名及位置一起返回给Slave端。

        3、Slave的IO进程接受到信息后，将接受到的日志内容写入relay-log文件中，并将读取到的Master端的二进制日志文件名后Position号记录在Master-info文件中，下次根据记录的日志文件名和Position号从Master上继续复制。以确保数据的一致性。

        4、Slave的Sql进程检测到relay-log中新增加的内容后，会马上解析relay-log的内容，并在自身执行。

        这种传统的复制方法由于在Master端是多线程写入的，而在Slave端是单线程的复制，往往会造成很高的延迟，同时在配置的时候需要找到binlog和pos点，然后change master to指向，不是很有经验的运维，往往会找错，造成主从同步复制报错。而从Mysql5.6开始支持的gtid模式的主从复制从而很大程度上解决了这些问题。

        TID：Transaction ID,事务的ID号：也就是说在mysql复制中每一个事务都有自己的ID号（随机数）

        GTID：Global Transaction ID,全局事务ID，在整个事务架构中每一个事务ID号是全局唯一的，不止是在一个节点上而是整个主从复制架构中每任何两个事务的ID号都不会相同。是mysql对写入二进制日志的每个事务所作的标记。由server_uuid和事务id组成。

        简单来讲GTID能够保证让一个从服务器到其他的从服务器那里实现数据复制而且能够实现数据整合的。一个事务对应一个唯一ID，一个GTID在一个服务器上只会执行一次，相对于行复制来讲数据安全性更高，故障切换更简单。

        GTID也有它的限制，不支持非事务引擎；不支持create table … select 语句复制；不允许在一个SQL同时更新一个事务引擎和非事务引擎的表； 在一个复制组中，必须要求统一开启CTID或是关闭GTID，开启DTID后，就不在使用原来的传统的复制方式，对于createtemporary table 和drop temporary table语句不支持，不支持sqlslaveskip_counter。

        Mysql是默认是异步复制、Master在将事件写入binlon时不知道Slave是否已经接受，此时Master宕机的，Slave可能会丢失事务。在这中情况下我们可以采用半同步复制，即一个线程在Master上提交事务将受到阻塞，直到得知一个已开启半同步复制功能的Slave已收到此事务的所有事件，或等待超时。

        以下是mysql主从复制的一些简单配置

        传统ab复制（mysql版本为rhel6.5自带的mysql）：

在master主机上：

vim /etc/my.cnf  server-id=1  log-bin=mysql-bin #启动二进制日志系统/etc/init.d/mysqld restartcd /var/lib/mysql

可以通过mysqlbinlog指令来插看二进制日志文件

创建同步帐户,并给予权限

mysql -pmysql> GRANT REPLICATION SLAVE ON *.* TO example@‘172.25.254.3‘ IDENTIFIED BY ‘Westos+123‘ ;

查看master状态

show master status;

记录File和Position的值,在slave配置时会用到。

在slave主机上 

查看能否远程登陆master主机的mysql

mysql -h 172.25.254.2 -uexample -pWestos+123

vim /etc/my.cnf  server-id=2 #从服务器ID号,不要和主ID相同也不要与其他从服务器相同/etc/init.d/mysqld restartmysql -pmysql> change master to    -> master_host=‘172.25.254.2‘, #指定主服务器ip地址    -> master_user=‘example‘,      #指定在主服务器上可以进行同步的用户名    -> master_password=‘Westos+123‘, #同步用户的密码    -> master_log_file=‘mysql-bin.000003‘, #上面看到的master的日志文件    -> master_log_pos=1007;          #master机的position值mysql> start slave;   #开启同步mysql> show slave statusG #查看slave状态

看到以下两个yes就表示同步开启成功

 Slave_IO_Running: Yes Slave_SQL_Running: Yes

我们可以通过slave状态中的延迟时间是否为0和pos号是否与master主机一致来查看同步是否完成。

。。。Seconds_Behind_Master: 0Exec_Master_Log_Pos: 1007。。。

Mysql的GTID复制：（mysql为5.7社区版）

在Master主机上：

vim /etc/my.cnf  server-id=1   log-bin=mysql-bin   gtid-mode=on   #开启gtid  enforce-gtid-consistency=on #强制GTID的一致性/etc/init.d/mysqld restartmysql -pmysql> GRANT REPLICATION SLAVE ON *.* TO example@‘172.25.254.3‘ IDENTIFIED BY ‘Westos+123‘ ;

在slave主机上

vim /etc/my.cnf  server-id=2  log-slave-updates #更新是否记入日志，当slave主机作为master主机是必须要有  gtid-mode=on  enforce-gtid-consistency=on  slave-parallel-type=LOGICAL_CLOCK #MySQL 5.6的多线程同步仅在有多个数据库时才有明显的性能提升,MySQL 5.7.2之后，可以通过配置slave-parallel-type为LOGICAL_CLOCK来避开这个限制.  slave-parallel-workers=16 #从服务器的SQL线程数，一个数据库同一时间只能有一个worker线程来进行工作。master_info_repository=TABLE #主服信息记录库=表/文件relay_log_info_repository=TABLE #中继日志信息记录库relay_log_recovery=ON   #在CRASH后自动放弃所有未执行的relay-log,并且重新从MASTER获取日志；保证relay-log的完整/etc/init.d/mysqld restartmysql -pmysql> change master to     -> master_host=‘172.25.254.2‘,    -> master_user=‘example‘,    -> master_password=‘Westos+123‘,    -> master_auto_position=1;mysql> start slave;mysql> show processlist; #可以看到开启了多个线程

这样简单的配置就完成了，检测的方法就是在Master主机上创建一个数据库看Slave机上是否会同步。

Mysql的ab复制

标签：mysql

mysql ab复制有哪些模式

        mysql复制在业界里有叫：mysql同步，ab复制等。专业名称就是叫：复制。复制是单向的异步复制，从一个Mysql（Master）复制到另一个Mysql(Slave)。实现整个主从复制，需要由Master服务器上的IO进程，和Salve服务器上的Sql进程和IO进程共同完成。

        要实现主从复制，首先必须打开Master端的二进制日志（bin-log）功能，因为整个Mysql复制过程实际上就是Slave从Master端获取相应的二进制日志文件，然后在根据相应的Position号在自己Slave端完全的执行日志中所记录的各种操作，（二进制日志文件是用sql语句写成的所以可以直接在Slave机上直接执行）。

        主从复制的基本过程如下：

        1、Mysql Slave端的IO进程链接上Master，向Master请求指定日志文件的指定位置（或者从最开始的日志）之后的日志内容；

        2、Master接受来自Slave的IO进程的请求后，负责复制的IO进程根据Slave的请求信息，读取相应日志内容，返回给Slave 的IO进程。并将本次请求读取的bin-log文件名及位置一起返回给Slave端。

        3、Slave的IO进程接受到信息后，将接受到的日志内容写入relay-log文件中，并将读取到的Master端的二进制日志文件名后Position号记录在Master-info文件中，下次根据记录的日志文件名和Position号从Master上继续复制。以确保数据的一致性。

        4、Slave的Sql进程检测到relay-log中新增加的内容后，会马上解析relay-log的内容，并在自身执行。

        这种传统的复制方法由于在Master端是多线程写入的，而在Slave端是单线程的复制，往往会造成很高的延迟，同时在配置的时候需要找到binlog和pos点，然后change master to指向，不是很有经验的运维，往往会找错，造成主从同步复制报错。而从Mysql5.6开始支持的gtid模式的主从复制从而很大程度上解决了这些问题。

        TID：Transaction ID,事务的ID号：也就是说在mysql复制中每一个事务都有自己的ID号（随机数）

        GTID：Global Transaction ID,全局事务ID，在整个事务架构中每一个事务ID号是全局唯一的，不止是在一个节点上而是整个主从复制架构中每任何两个事务的ID号都不会相同。是mysql对写入二进制日志的每个事务所作的标记。由server_uuid和事务id组成。

        简单来讲GTID能够保证让一个从服务器到其他的从服务器那里实现数据复制而且能够实现数据整合的。一个事务对应一个唯一ID，一个GTID在一个服务器上只会执行一次，相对于行复制来讲数据安全性更高，故障切换更简单。

        GTID也有它的限制，不支持非事务引擎；不支持create table … select 语句复制；不允许在一个SQL同时更新一个事务引擎和非事务引擎的表； 在一个复制组中，必须要求统一开启CTID或是关闭GTID，开启DTID后，就不在使用原来的传统的复制方式，对于createtemporary table 和drop temporary table语句不支持，不支持sqlslaveskip_counter。

        Mysql是默认是异步复制、Master在将事件写入binlon时不知道Slave是否已经接受，此时Master宕机的，Slave可能会丢失事务。在这中情况下我们可以采用半同步复制，即一个线程在Master上提交事务将受到阻塞，直到得知一个已开启半同步复制功能的Slave已收到此事务的所有事件，或等待超时。

        以下是mysql主从复制的一些简单配置

        传统ab复制（mysql版本为rhel6.5自带的mysql）：

在master主机上：

vim /etc/my.cnf  server-id=1  log-bin=mysql-bin #启动二进制日志系统/etc/init.d/mysqld restartcd /var/lib/mysql

可以通过mysqlbinlog指令来插看二进制日志文件

创建同步帐户,并给予权限

mysql -pmysql> GRANT REPLICATION SLAVE ON *.* TO example@‘172.25.254.3‘ IDENTIFIED BY ‘Westos+123‘ ;

查看master状态

show master status;

记录File和Position的值,在slave配置时会用到。

在slave主机上 

查看能否远程登陆master主机的mysql

mysql -h 172.25.254.2 -uexample -pWestos+123

vim /etc/my.cnf  server-id=2 #从服务器ID号,不要和主ID相同也不要与其他从服务器相同/etc/init.d/mysqld restartmysql -pmysql> change master to    -> master_host=‘172.25.254.2‘, #指定主服务器ip地址    -> master_user=‘example‘,      #指定在主服务器上可以进行同步的用户名    -> master_password=‘Westos+123‘, #同步用户的密码    -> master_log_file=‘mysql-bin.000003‘, #上面看到的master的日志文件    -> master_log_pos=1007;          #master机的position值mysql> start slave;   #开启同步mysql> show slave statusG #查看slave状态

看到以下两个yes就表示同步开启成功

 Slave_IO_Running: Yes Slave_SQL_Running: Yes

我们可以通过slave状态中的延迟时间是否为0和pos号是否与master主机一致来查看同步是否完成。

。。。Seconds_Behind_Master: 0Exec_Master_Log_Pos: 1007。。。

Mysql的GTID复制：（mysql为5.7社区版）

在Master主机上：

vim /etc/my.cnf  server-id=1   log-bin=mysql-bin   gtid-mode=on   #开启gtid  enforce-gtid-consistency=on #强制GTID的一致性/etc/init.d/mysqld restartmysql -pmysql> GRANT REPLICATION SLAVE ON *.* TO example@‘172.25.254.3‘ IDENTIFIED BY ‘Westos+123‘ ;

在slave主机上

vim /etc/my.cnf  server-id=2  log-slave-updates #更新是否记入日志，当slave主机作为master主机是必须要有  gtid-mode=on  enforce-gtid-consistency=on  slave-parallel-type=LOGICAL_CLOCK #MySQL 5.6的多线程同步仅在有多个数据库时才有明显的性能提升,MySQL 5.7.2之后，可以通过配置slave-parallel-type为LOGICAL_CLOCK来避开这个限制.  slave-parallel-workers=16 #从服务器的SQL线程数，一个数据库同一时间只能有一个worker线程来进行工作。master_info_repository=TABLE #主服信息记录库=表/文件relay_log_info_repository=TABLE #中继日志信息记录库relay_log_recovery=ON   #在CRASH后自动放弃所有未执行的relay-log,并且重新从MASTER获取日志；保证relay-log的完整/etc/init.d/mysqld restartmysql -pmysql> change master to     -> master_host=‘172.25.254.2‘,    -> master_user=‘example‘,    -> master_password=‘Westos+123‘,    -> master_auto_position=1;mysql> start slave;mysql> show processlist; #可以看到开启了多个线程

这样简单的配置就完成了，检测的方法就是在Master主机上创建一个数据库看Slave机上是否会同步。

Mysql的ab复制

标签：mysql

如何配置MySQL主从复制

MySQL支持单向、异步复制，复制过程中一个服务器充当主服务器，而一个或多个其它服务器充当从服务器。主服务器将更新写入二进制日志文件，并维护日志文件的一个索引以跟踪日志循环。当一个从服务器连接到主服务器时，它通知主服务器从服务器在日志中读取的最

MySQL支持单向、异步复制，复制过程中一个服务器充当主服务器，而一个或多个其它服务器充当从服务器。主服务器将更新写入二进制日志文件，并维护日志文件的一个索引以跟踪日志循环。当一个从服务器连接到主服务器时，它通知主服务器从服务器在日志中读取的最后一次成功更新的位置。从服务器接收从那时起发生的任何更新，然后封锁并等待主服务器通知下一次更新。

为什么使用主从复制?

1、主服务器/从服务器设置增加了健壮性。主服务器出现问题时，你可以切换到从服务器作为备份。

2、通过在主服务器和从服务器之间切分处理客户查询的负荷，可以得到更好的客户响应时间。但是不要同时在主从服务器上进行更新，这样可能引起冲突。

3、使用复制的另一个好处是可以使用一个从服务器执行备份，而不会干扰主服务器。在备份过程中主服务器可以继续处理更新。

MySQL使用3个线程来执行复制功能(其中1个在主服务器上，另两个在从服务器上。当发出START SLAVE时，从服务器创建一个I/O线程，以连接主服务器并让主服务器发送二进制日志。主服务器创建一个线程将二进制日志中的内容发送到从服务器。从服务器I/O线程读取主服务器Binlog Dump线程发送的内容并将该数据拷贝到从服务器数据目录中的本地文件中，即中继日志。第3个线程是SQL线程，从服务器使用此线程读取中继日志并执行日志中包含的更新。SHOW PROCESSLIST语句可以查询在主服务器上和从服务器上发生的关于复制的信息。

默认中继日志使用host_name-relay-bin.nnnnnn形式的文件名，其中host_name是从服务器主机名，nnnnnn是序列号。用连续序列号来创建连续中继日志文件，从000001开始。从服务器跟踪中继日志索引文件来识别目前正使用的中继日志。默认中继日志索引文件名为host_name-relay-bin.index。在默认情况，这些文件在从服务器的数据目录中被创建。中继日志与二进制日志的格式相同，并且可以用mysqlbinlog读取。当SQL线程执行完中继日志中的所有事件后，中继日志将会被自动删除。

从服务器在数据目录中另外创建两个状态文件--master.info和relay-log.info。状态文件保存在硬盘上，从服务器关闭时不会丢失。下次从服务器启动时，读取这些文件以确定它已经从主服务器读取了多少二进制日志，以及处理自己的中继日志的程度。

设置主从复制：

1、确保在主服务器和从服务器上安装的MySQL版本相同，并且最好是MySQL的最新稳定版本。

2、在主服务器上为复制设置一个连接账户。该账户必须授予REPLICATION SLAVE权限。如果账户仅用于复制(推荐这样做)，则不需要再授予任何其它权限。

mysql> GRANT REPLICATION SLAVE ON *.*

TO 'replication'@'%.yourdomain.com' IDENTIFIED BY 'slavepass';

3、执行FLUSH TABLES WITH READ LOCK语句清空所有表和块写入语句：

mysql> FLUSH TABLES WITH READ LOCK;

保持mysql客户端程序不要退出。开启另一个终端对主服务器数据目录做快照。

shell> cd /usr/local/mysql/

shell> tar -cvf /tmp/mysql-snapshot.tar ./data

如果从服务器的用户账户与主服务器的不同，你可能不想复制mysql数据库。在这种情况下，应从归档中排除该数据库。你也不需要在归档中包括任何日志文件或者master.info或relay-log.info文件。

当FLUSH TABLES WITH READ LOCK所置读锁定有效时(即mysql客户端程序不退出)，读取主服务器上当前的二进制日志名和偏移量值：

mysql > SHOW MASTER STATUS;

+---------------+----------+--------------+------------------+

| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |

+---------------+----------+--------------+------------------+

| mysql-bin.003 | 73 | test | manual,mysql |

+---------------+----------+--------------+------------------+

File列显示日志名，而Position显示偏移量。在该例子中，二进制日志值为mysql-bin.003，偏移量为73。记录该值。以后设置从服务器时需要使用这些值。它们表示复制坐标，，从服务器应从该点开始从主服务器上进行新的更新。

如果主服务器运行时没有启用--logs-bin，SHOW MASTER STATUS显示的日志名和位置值为空。在这种情况下，当以后指定从服务器的日志文件和位置时需要使用的值为空字符串('')和4.

取得快照并记录日志名和偏移量后，回到前一中端重新启用写活动：

mysql> UNLOCK TABLES;

4、确保主服务器主机上my.cnf文件的[mysqld]部分包括一个log-bin选项。该部分还应有一个server-id=Master_id选项，其中master_id必须为1到232–1之间的一个正整数值。例如：

[mysqld]

log-bin

server-id=1

如果没有提供那些选项，应添加它们并重启服务器。

5、停止从服务器上的mysqld服务并在其my.cnf文件中添加下面的行：

[mysqld]

server-id=2

slave_id值同Master_id值一样，必须为1到232–1之间的一个正整数值。并且，从服务器的ID必须与主服务器的ID不相同。

6、将数据备据目录中。确保对这些文件和目录的权限正确。服务器 MySQL运行的用户必须能够读写文件，如同在主服务器上一样。

Shell> chown -R mysql:mysql /usr/local/mysql/data

7、启动从服务器。在从服务器上执行下面的语句，用你的系统的实际值替换选项值：

mysql> CHANGE MASTER TO

MASTER_HOST='master_host_name',

MASTER_USER='replication_user_name',

MASTER_PASSWORD='replication_password',

MASTER_LOG_FILE='recorded_log_file_name',

MASTER_LOG_POS=recorded_log_position;

8、启动从服务器线程：

mysql> START SLAVE;

执行这些程序后，从服务器应连接主服务器，并补充自从快照以来发生的任何更新。

9、如果出现复制错误，从服务器的错误日志(HOSTNAME.err)中也会出现错误消息。

10、从服务器复制时，会在其数据目录中发现文件master.info和HOSTNAME-relay-log.info。从服务器使用这两个文件跟踪已经处理了多少主服务器的二进制日志。不要移除或编辑这些文件，除非你确切知你正在做什么并完全理解其意义。即使这样，最好是使用CHANGE MASTER TO语句。

mysql 5.5相对于以前的版本有什么不一样（5.0以后，5.5以前）

MySQL 4.1/5.0/5.1/5.5/5.6各版本的主要区别

1、4.1 增加了子查询的支持，字符集增加UTF-8，GROUP BY语句增加了ROLLUP，mysql.user表采用了更好的加密算法。

2、5.0 增加了Stored proceres、Views、Cursors、Triggers、XA transactions的支持，增加了INFORATION_SCHEMA系统数据库。

3、5.1 增加了Event scheler，Partitioning，Pluggable storage engine API ，Row-based replication、Global级别动态修改general query log和slow query log的支持。

4、5.5的新特征

1)默认存储引擎更改为InnoDB

2)提高性能和可扩展性

a. 提高了默认线程并发数(innodb_thread_concurrency)

b. 后台输入/输出线程控制（innodb_read_io_threads、innodb_write_io_threads）

c. 主线程输入/输出速率控制（innodb_io_capacity）

d. 操作系统内存分配程序使用控制(innodb_use_sys_malloc)

e. 适应性散列索引(Hash Index)控制，用户可以关闭适应性散列功能。

f. 插入缓冲（Insert Buffering）控制，用户可以关闭innodb的插入缓冲功能。

g. 通过快速加锁算法提高可扩展性，innodb不在使用代理(posix)线程,而是使用原生的操作来完成互斥和读写锁定。

h. 恢复组提交（Restored Group Commit）

i. 提高恢复性能

j. 多缓冲池实例

k. 多个回滚段（Multiple Rollback Segments）,之前的innodb版本最大能处理1023个并发处理操作，现在mysql5.5可以处理高达128K的并发事物，

l. Linux系统固有的异步输入/输出，mysql5.5数据库系统也提高了linux系统的输入输出请求的并发数。

m. 扩展变化缓冲：添加了删除缓冲和清除缓冲

n. 改善了日志系统互斥和单独刷新（Flush）列表互斥

o. 改善清除程序进度，在mysql5.5中清楚操作线程是的线程，并支持并发，可以使用innodb_purge_treads配置。

p. 改善事务处理中的元数据锁定。例如，事物中一个语句需要锁一个表，会在事物结束时释放这个表，而不是像以前在语句结束时释放表。

3)提高实用性

a. 半同步复制（Semi-synchronous Replication）

b. 复制Heartbeat

c. 中继日志自动恢复（Automatic Relay Log Recovery）

d. 根据服务器过滤项复制（Replication Per Server Filtering）

e. 从服务器复制支持的数据类型转换（Replication Slave Side Data Type Conversions）

4)提高易管理性和效率

a. 建立快速索引（Faster Index Creation）

b. 高效的数据压缩（Efficient Data Compression）

c. 为大物件和可变长度列提供高效存储

d. 增加了INFORMATION_SCHEMA表，新的表提供了与InnoDB压缩和事务处理锁定有关的具体信息。

5)提高可用性

a. 针对SIGNAL/RESIGNAL的新SQL语法

b. 新的表/索引分区选项。MySQL5.5将表和索引RANG和LIST分区范围扩展到了非整数列和日期，并增加了在多个列上分区的能力。

6)改善检测和诊断

Mysql5.5引入了一种新的性能架构(performancn_shema,P_S),用于监控mysql监控服务器运行时的性能。

5、5.6的新特征 1)InnoDB现在可以大量表打开的时候内存占用过多的问题（比如这里提到的）(第三方已有补丁)

2)InnoDB性能加强。如分拆kernel mutex;flush操作从主线程分离;多个perge线程;大内存优化等

3)InnoDB死锁信息可以记录到 error 日志，方便分析

4)MySQL5.6支持延时复制，可以让slave跟master之间控制一个时间间隔，方便特殊情况下的数据恢复。

5)表分区功能增强

6)MySQL行级复制功能加强，可以降低磁盘、内存、网络等资源开销（只记录能确定行记录的字段即可）

7)Binlog实现 crash-safe

8)复制事件采用crc32校验，增强master/slave 复制数据一致性

9)新增 log_bin_basename （以前variables里面没有binlog位置信息，对数据库的监管很不方便）