Mysql主从安装配置(二)

master_log_pos=324;

slave start;

show slave status\G;

2、现象：从数据库无法同步，show slave status显示Slave_IO_Running为No,Seconds_Behind_Master
为null

解决：重启主数据库

service mysql restart

mysql> show master status;

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

| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |

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

| mysql-bin.000001 | 98 | | |

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

slave stop;

change master to Master_Log_File='mysql-bin.000001',Master_Log_Pos=98

slave start;

或是这样：

stop slave;

set global sql_slave_skip_counter =1;

start slave;

这个现象主要是master数据库存在问题，我在实际的操作中先重启master后重启slave即可解决这问题，
出现此问题，必须要要重启master数据库。

1.主辅库同步主要是通过二进制日志来实现同步的。

2.在启动辅库的时候必须先把数据同步，并删除日志目录下的：master.info文件。因为master.info记录
了上次要连接主库的信息，如果不删除，即使my.cnf里进行了修改，也不起作用。因为读取的还是
master.info文件里的信息。

在mysql复制环境中,有8个参数可以让我们控制,需要复制或需要忽略不进行复制的DB或table分别为:

下面二项需要在Master上设置：

Binlog_Do_DB:设定哪些数据库需要记录Binlog

Binlog_Ignore_DB:设定哪里数据库不需要记录Binlog

优点是Master端的Binlog记录所带来的Io量减少，网络IO减少，还会让slave端的IO线程,SQL线程减少，
从而大幅提高复制性能,

缺点是mysql判断是否需要复制某个事件不是根据产生该事件的查询所在的DB,而是根据执行查询时刻所在
的默认数据库（也就是登录时指定的库名或运行"use database"中指定的DB）,只有当前默认DB和配置中
所设定的DB完全吻合时IO线程才会将该事件读取给slave的IO线程.所以,如果在默认 DB和设定须要复制的
DB不一样的情况下改变了须要复制的DB中某个Table中的数据,该事件是不会被复制到Slave中去的,这样就
会造成Slave端的数据和Master的数据不一致.同样,在默认的数据库下更改了不须要复制的数据库中的数据,
则会被复制到slave端,当slave端并没有该数据库时,则会造成复制出错而停止.

下面六项需要在slave上设置：

Replicate_Do_DB:设定需要复制的数据库,多个DB用逗号分隔

Replicate_Ignore_DB:设定可以忽略的数据库.

Replicate_Do_Table:设定需要复制的Table

Replicate_Ignore_Table:设定可以忽略的Table

Replicate_Wild_Do_Table:功能同Replicate_Do_Table,但可以带通配符来进行设置。

Replicate_Wild_Ignore_Table:功能同Replicate_Do_Table,功能同Replicate_Ignore_Table,可以带通配符。

优点是在slave端设置复制过滤机制,可以保证不会出现因为默认的数据库问题而造成Slave和Master数据
不一致或复制出错的问题.

缺点是性能方面比在Master端差一些.原因在于:不管是否须要复制,事件都会被IO线程读取到Slave端,
这样不仅增加了网络IO量,也给Slave端的IO线程增加了Relay Log的写入量.

同步原理说明

MySQL的Replication基于主服务器在二进制日志中跟踪所有对数据库的更改(更新、删除等)。

MySQL使用3个线程来完成Replication工作，具体分布是主上1个相关线程、从上2个相关线程；

主的相关线程可以理解为主服务器上SHOW PROCESSLIST的输出中的Binlog Dump线程、从服务器分别为IO和
SQL线程;

主服务器创建将binlog中的内容发送到从服务器。从服务器I/O线程读取主服务器Binlog Dump线程发送的
内容并将该数据拷贝到从服务器数据目录中的中继日志文件（relay-log）里，SQL线程用于读取中继日志
并执行日志中包含的更新。

MySQL的Replication是单向，异步同步

MySQL同步机制基于master把所有对数据库的更新、删除等)都记录在二进制日志里。因此，想要启用同步
机制，在master就必须启用二进制日志。每个slave接受来自master上在二进制日志中记录的更新操作，
因此在slave上执行了这个操作的一个拷贝。应该非常重要地意识到，二进制日志只是从启用二进制日志开
始的时刻才记录更新操作的。所有的 slave必须在启用二进制日志时把master上已经存在的数据拷贝过来。
如果运行同步时slave上的数据和master上启用二进制日志时的数据不一致的话，那么slave同步就会失败。
把master上的数据拷贝过来的方法之一实在slave上执行 LOAD DATA FROM MASTER 语句。不过要注意，LOAD DATA FROM MASTER是从MySQL 4.0.0之后才开始可以用的，而且只支持master上的 MyISAM 类型表。同样地，
这个操作需要一个全局的读锁，这样的话传送日志到slave的时候在master上就不会有更新操作了。当实现了
自由锁表热备份时(在 MySQL 5.0中)，全局读锁就没必要了。由于有这些限制，因此我们建议只在master上
相关数据比较小的时候才执行 LOAD DATA FROM MASTER 语句，或者在master上允许一个长时间的读锁。
由于每个 系统之间 LOAD DATA FROM MASTER 的速度各不一样，一个比较好的衡量规则是每秒能拷贝1MB数据。
这只是的粗略的估计，不过master和slave都是奔腾700MHz的机器且用 100MBit/s网络连接时就能