(图是由本人自制，不够美观，请勿介意)
slave服务器上执行start slave，开启主从复制开关
此时，slave的io线程会通过在master上的授权的复制用户权限请求连接master，并请求从指定位置（日志文件和未知就是在配置主从复制服务时执行change master命令时指定的）之后发送binlog日志 内容master接收来自slave的io线程的请求后，master负责复制io线程根据slave的io线程请求的信息读取指定binlog日志文件指定位置之后的binlog日志信息，然后返回给slave端的io线程。返回的信息中出了binlog日志内容外，还有本次返回日志内容后在master端的新的binlog文件名称以及在binlog中的下一个指定更新位置 当slave的io线程获取到来自master上io线程发送日志内容及日志文件及位置点后，将binlog日 志内容依次写入到slave端自身的relay log文件的最末端，并将新的binlog文件名和位置纪录到master- info文件中，以便下一次读取master端新binlog日志时能够告诉master服务器需要从新binlog日志的哪 个文件哪个位置开始请求新的binlog日志内容
slave端的sql线程会实时的检测本地relay log中新增加的日志内容，然后及时的把log文件中的内容解析成master端曾经执行的sql语句的内容，并在自身slave上按语句的顺序执行应用这些sql语句， 应用完毕后清理应用过的日志
经过上面的过程，就可以确保在master端和slave端执行了同样的sql语句。当复制状态正常的情况下，master端和slave端的数据完全一样的，mysql的同步机制是有一些特殊情况的，具体参考官方说明，大多数情况下，不用担心。
这只是mysql主从复制的最基础部分，还有relay.info文件和索引文件没有涉及到
