17.1 Replication Configuration

17.1 Replication Configuration
 
17.1.1 How to Set Up Replication
17.1.2 Replication Formats
17.1.3 Replication with Global Transaction Identifiers
17.1.4 Replication and Binary Logging Options and Variables
17.1.5 Common Replication Administration Tasks
 
复制在MySQL server之间是基于binary logging 机制。
 
MySQL 实例操作作为master(数据库改变的源头) 写更新和改变作为"events" 到binary log.
 
信息在binary logs 是存在不同的日志格式根据数据所记录的数据库的变化。
 
Slaves 是被配置从master 读取binary log 执行binary log上的evnets 在slave的本地数据库。
 
注意:
 
你不能配置master 只记录某些evnets.
 
在这种情况下 master 是哑巴,一旦 binary logging 启用,所有的语句是记录在Binary log里。
 
每个slave 接收到binary log的整个内存的拷贝。
 
这是slave的责任来决定 哪个语句在binary log 应该被执行,
 
你可以配置master 来只记录某些events. 如果你没有指定其他, 所有的evnets 在master binary log 是在slave端执行的。
 
如果需要,你可以配置slave来只处理events 应用于特定的数据库或者表。
 
每个slave 保持一个binary log 坐标的记录,文件名和位置 在文件里记录了已经读取和从master处理的位置。
 
这意味着 多个slaves 可以连接到master中相同binary log的不同的部分。
 
因为slaves 控制这个过程,单独的slaves 可以连接和断开不会影响master的操作。
 
因为每个slave记录当前位置在binary log,  对于slave 被断开是可以的,重新连接和继续处理
 
master 和每个slave必须配置一个唯一的ID(使用server-id 选项).此外, 每个slave 必须配置信息关于master hostname,
 
log file name,和文件的位置。
 
那些细节可以在一个MySQL Session 使用CHANGE MASTER TO statement on the slave.
 
信息是存储在slave的master info 信息库,它可以是一个文件或者一个表格
 
本章节藐视了复制的设置和配置环境,包含一步一步阐述创建一个新的复制环境。主要的组成部分是:
 
1. 设置2个或者更多的server用于复制, Section 17.1.1, “How to Set Up Replication”,  处理系统配置和
 
提供方法用于复制数据在Master和slave之间
 
2.Events 在binary log 是被记录使用一些列的格式, 那些被称为基于语句的(SBR)或者基于行的(RBR)
 
第3种类型, 混合模式(MIXED),使用SBR和RBR, 复制自动的利用SBR和RBR的好处 当在合适的情况下.
 
3.在不同的配置选项和变量详细信息 ,应用于复制是提供在 Section 17.1.4, “Replication and Binary Logging Options and 
 
Variables”.
 
4.一旦启动,复制过程应该需要很少的管理或者监控,然而,对于常见的任务你需要执行 see Section 17.1.5, “Common Replication 
 
Administration Tasks”.