主库:
DUMP THREAD
从库:
IO  THREAD
SQL THREAD

主库:
mysql-bin.000001　　　　=====》主库的二进制文件

从库: 
db01-relay.000001           ===》中继日志
master.info                 ===》主库信息记录日志
relay-log.info              ===> 记录中继应用情况信息

1.change master to 时，ip pot user password binlog position写入到master.info进行记录
2. start slave 时，从库会启动IO线程和SQL线程
3.IO_T，读取master.info信息，获取主库信息连接主库
4. 主库会生成一个准备binlog DUMP线程，来响应从库
5. IO_T根据master.info记录的binlog文件名和position号，请求主库DUMP最新日志
6. DUMP线程检查主库的binlog日志，如果有新的，TP(传送)给从从库的IO_T
7. IO_T将收到的日志存储到了TCP/IP 缓存，立即返回ACK给主库 ，主库工作完成
8.IO_T将缓存中的数据，存储到relay-log日志文件,更新master.info文件binlog 文件名和postion，IO_T工作完成
9.SQL_T读取relay-log.info文件，获取到上次执行到的relay-log的位置，作为起点，回放relay-log
10.SQL_T回放完成之后，会更新relay-log.info文件。
11. relay-log会有自动清理的功能。
细节：
1.主库一旦有新的日志生成，会发送“信号”给binlog dump ，IO线程再请求

mysql> show slave status \G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
# 主库的相关信息(master.info中的信息)
Master_Host: 192.168.0.104
Master_User: repl
Master_Port: 3306
Connect_Retry: 10
Master_Log_File: mysql-bin.000011    # 获取到的最新的主库日志文件
Read_Master_Log_Pos: 779            # 当前主库最新的position位置

# 从库relay应用信息有关的(relay.info中的信息)
Relay_Log_File: 192-relay-bin.000005
Relay_Log_Pos: 992                        # 上下两个表示relay_log的文件名和position
Relay_Master_Log_File: mysql-bin.000011    # 对应主库的文件名

# 从库线程运行状态
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Last_IO_Errno: 0
Last_IO_Error: 
Last_SQL_Errno: 0
Last_SQL_Error: 

# 过滤复制有关的信息(有选择性的复制主库)
Replicate_Do_DB: 
Replicate_Ignore_DB: 
Replicate_Do_Table: 
Replicate_Ignore_Table: 
Replicate_Wild_Do_Table: 
Replicate_Wild_Ignore_Table: 
   
# 从库延时主库的时间(秒)
Seconds_Behind_Master: 0

# 延时从库配置
SQL_Delay: 0
SQL_Remaining_Delay: NULL

# gtid复制有关的状态信息
Retrieved_Gtid_Set: 
Executed_Gtid_Set: 
Auto_Position: 0

主从复制的核心就是从库的两个线程（io和sql）加上主库的dump线程，而dump线程又是主库自动开启的，出问题的概率不大。

从库线程之io线程解析：
io线程的工作职责：
　　1. 连接主库
　　2. 请求主库的binlog
　　3. 存储请求到的binlog

手动使用复制账户连接主库，核对账户，密码，ip，端口等配置信息是否正确，如果是这些信息异常导致的，则按照以下步骤到从库重新设置。
核对防火墙的影响。

stop  slave  
reset slave all 
change master to xxxxxx
start slave

如果是因为数据库最大链接数满了引起的连接异常，可手动增大最大连接数限制

[root@db01 ~]# mysql -urepl -p123 -h 10.0.0.51 -P 3307 
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 1040 (HY000): Too many connections
处理方法:
db01 [(none)]>set global max_connections=300;

1. 确认主从binlog是否开启
2. 确认从库配置的二进制日志文件是否存在
3. 针对主库做过重置二进制文件序号的命令(即主库执行了：reset master)解决办法？
　　分析，之所以同步失败，是因为主库重置了二进制序号，而该操作不会被从库同步到，所以导致从库中储存的二进制文件和position号无效。
　　主库执行：show binlog events in ‘xxxxx.000001‘;找到最开始的position号，从新配置从库的同步信息即可。
　　(reset master后刷出来的新二进制文件，开始的position号一定是154吗？)