-- MySQL复制;
复制是MySQL的一项功能,允许服务器将更改从一个实例复制到另一个实例:
1.MySQL中的复制功能用于将更改从一个服务器(主服务器)复制到一个或多个从属服务器;
2.主服务器将所有数据和结构更改记录到二进制日志中;
3.从属服务器从主服务器请求该二进制日志并在本地应用其内容;
4.日志文件的格式影响从属服务器应用更改的方式,MySQL支持基于语句的,基于行的以及混合格式的日志记录;
5.从属服务器数量:
1.一个主服务器可以具有的从属服务器数量没有限制,但是,每个额外从属服务器使用主服务器上的较少资源,所以您应该仔细考虑生产设置中每个从属服务器的好处;
2.给定环境中主服务器的最佳从属服务器数量取决于许多因素:模式大小,写入次数,主服务器和从属服务器的相对性能以及CPU和内存可用性等因素;
3.一般准则是将每个主服务器的从属服务器数量限制为不超过30;
6.网络故障:
1.MySQL中的复制功能在网络故障时继续工作;
2.每个从属服务器跟踪其已经处理了多少日志并在网络连接恢复时自动继续处理,此行为是自动的,不需要特殊配置;
-- 复制主服务器和从属服务器;
主/从属服务器关系是一对多关系:
1.每个从属服务器从一个主服务器读取日志;
2.一个主服务器可以将日志传送给许多从属服务器;
3.中继从属服务器:
1.最顶层主服务器的直接从属服务器请求并应用该主服务器处发生的更改,而该从属服务器将更改向下中继到其从属服务器,以此类推,直到复制到达该链的末尾;
2.这样可以通过多个级别的复制来传播更新,允许更复杂的拓扑,每个额外级别会向系统添加更多传播延迟,从而较浅设置遇到的复制滞后要比较深设置少;
3.每个从属服务器仅能具有一个主服务器,一个从属服务器不能从多个主服务器进行复制;
4.如果一个从属服务器用作其他服务器的主服务器,该从属服务器常常称为中继从属服务器;
4.使用BLACKHOLE存储引擎进行复制:
1.BLACKHOLE存储引擎无提示地放弃所有数据更改,而不发出警告,二进制日志继续成功记录这些更改;
2.当中继从属服务器将所有更改复制到深一层的从属服务器,但是自身不需要将数据存储在特定表中时,将BLACKHOLE用于这些表;
3.例如,如果您具有的中继从属服务器单独用来对少量表执行经常长时间运行的业务智能报表,您可以将其他所有复制的表配置为使用 BLACKHOLE,从而服务器不会存储其不需要的数据,同时将所有更改复制到其从属服务器;
-- 复杂拓扑;
可以使用更复杂的拓扑:
1.双向拓扑具有两个主服务器,每个主服务器是另一个主服务器的从属服务器;
2.循环拓扑具有任意数量的服务器:
1.每个服务器是一个主服务器并且是另一个主服务器的从属服务器;
2.对任何主服务器的更改将复制到所有主服务器;
3.并非每个从属服务器都必须是主服务器;
4.MySQL复制不执行冲突解析;
1.在典型配置中,客户机仅将更改写入主服务器,但是从属服务器读取更改,在服务器允许数据进行并发更新的环境中,数据在多个服务器上的最终状态可能变得不一致;
2.应用程序负责防止或管理冲突操作,MySQL复制不执行冲突解决解析;包括多个主服务器的所有拓扑中都可能发生冲突,这包括诸如前面幻灯片中显示的简单分层结构(如果中继从属服务器接受客户机的更改);冲突在循环拓扑中特别常见
3.eg:程序的两个进程想要把一个价值600块的商品上涨20%和下降50块,就会因为执行的顺序不同产生670块和660块;
-- 复制用例;
复制的常见用法:
1.水平向外扩展:在多个从属服务器中分布查询工作负荷;实现复制的最常见原因是在一个或多个从属服务器中分布查询工作负荷,从而提高整个应用程序中读取操作的性能,并通过减少主服务器的读取工作负荷来提高其上的写入操作性能;
2.业务智能和分析:业务智能报表和分析处理会使用大量资源,需要大量时间来执行;在复制的环境中,可以在从属服务器上运行此类查询,从而主服务器可以继续处理生产工作负荷,而不受长时间运行的I/O密集型报表的影响;
3.地理数据分布:具有分布式地理位置的公司可以受益于复制,在每个区域具有服务器,用于处理本地数据并在组织中复制该数据;这样可以向客户和员工提供地理相邻性的性能和管理优势,同时还使公司了解整个公司的数据;
-- 高可用性复制;
1.受控切换:在硬件或系统升级期间使用副本来代替生产服务器;
2.服务器冗余:在系统故障时执行故障转移到副本服务器;
3.联机模式更改:在具有多个服务器的环境中执行滚动升级来避免整个系统故障;
4.软件升级:在环境升级过程中在不同版本的MySQL之间进行复制;
1.从属服务器运行的版本必须比主服务器新;
2.在升级过程中发出的查询必须受升级过程中使用的所有版本的支持;
-- 配置复制;
1.为每个服务器配置唯一server-id;
1.复制拓扑中的每个服务器必须具有唯一的server-id,一个无符号的32位整数,值从0(默认)到4,294,967,295;
2.server-id为0的服务器(无论是从属服务器还是主服务器)拒绝使用其他服务器进行复制;
2.配置每个主服务器:
1.启用二进制日志并启用TCP/IP网络;
1.每个主服务器必须启用二进制日志记录,因为在复制过程中,每个主服务器将其日志内容发送到每个从属服务器;
2.每个主服务器必须分配有IP地址和TCP端口,因为复制无法使用UNIX套接字文件;
2.每个从属服务器必须登录到主服务器中才能从中进行复制,所以创建具有REPLICATION SLAVE特权的新用户;
1.GRANT REPLICATION SLAVE ON *.* TO @;
3.备份主数据库,并且如果需要则记录日志坐标;
1.如果您正使用已经包含已填充数据库的主服务器创建复制拓扑,必须首先为从属服务器创建该数据库的副本;
2.如果您使用全局事务标识符,则不需要记录日志坐标;
3.配置每个从属服务器:
1.从主服务器恢复备份;
2.在每个从属服务器上发出CHANGEMASTER TO语句,包含:
1.主服务器的网络位置;
2.复制帐户用户名和口令;
3.开始复制操作的日志坐标(如果需要);
3.使用START SLAVE开始复制;
-- CHANGE MASTER TO;
1.在从属服务器上发出CHANGE MASTER TO...语句来配置复制主服务器连接详细信息:
mysql> CHANGE MASTER TO
-> MASTER_HOST = 'host_name',
-> MASTER_PORT = port_num,
-> MASTER_USER = 'user_name',
-> MASTER_PASSWORD = 'password',
-> MASTER_LOG_FILE = 'master_log_name',
-> MASTER_LOG_POS = master_log_pos;
2.CHANGE MASTER TO的后续调用保留每个未指定选项的值:
1.更改主服务器的主机或端口还会重置日志;
2.更改口令,但是保留所有其他设置: mysql> CHANGE MASTER TO MASTER_PASSWORD='newpass';
3.注意事项:
1.要提高安全性,还可以在启用SSL的服务器上使用MASTER_SSL和相关选项加密复制期间从属服务器和主服务器之间的网络通信;
2.可以通过执行SHOW MASTER STATUS语句从主服务器获取文件和位置:mysql> SHOW MASTER STATUS;
3.如果使用mysqldump执行主服务器的数据库备份作为从属服务器的起点,可以使用--master-data选项在备份中包括日志坐标:
mysqldump -uroot -p --master-data -B world_innodb > backup.sql;
4.如果您使用GTID,则指定MASTER_AUTO_POSITION=1,而不是日志坐标;
-- 使用日志坐标进行故障转移;
1.当主服务器变为不可用后进行故障转移,从而选择某个从属服务器作为主服务器;需要查找每个从属服务器的新主服务器和正确的日志坐标,严密检查二进制日志:
1.查找应用于每个从属服务器的最近事件;
2.选择最新从属服务器作为新的主服务器;
1.如果新主服务器位于特定从属服务器后面(即,如果该从属服务器已经应用了该新主服务器的日志末尾的事件),则该从属服务器会重复那些事件;
2.如果新主服务器在特定从属服务器的前面(即,如果该新主服务器的二进制日志包含该从属服务器尚未应用的事件),该从属服务器将跳过那些事件;
3.确定新主服务器上的日志坐标来匹配每个其他从属服务器上最新应用的事件;
4.在每个从属服务器上发出正确的CHANGE MASTER TO...;
2.在循环拓扑中,查找每个二进制日志中的事件源变得非常困难:
1.因为每个从属服务器使用与其他从属服务器不同的顺序应用操作;
2.要避免此困难,请使用全局事务标识符(Global Transaction Identifier, GTID);MySQL实用程序还包括有助于使用GTID进行故障转移的工具;
-- 全局事务标识符(Global Transaction Identifier, GTID);
1.全局事务标识符(Global Transaction Identifier, GTID)唯一地标识复制的网络中的每个事务;
1.UUID(universally unique identifier,通用唯一标识符)是每个事务的源服务器的UUID;
2.每个服务器的UUID存储在数据目录中的auto.cnf文件中,每次重启时会读取这个文件;如果该文件不存在,MySQL会创建该文件并生成新的UUID,将其放在该新文件中;
3.使用server_uuid变量查询服务器的UUID:mysql> SELECT @@server_uuid\G
4.客户机在主服务器上执行事务时,MySQL将创建新GTID并记录事务及其唯一GTID,从属服务器从主服务器读取并应用该事务时,该事务保持其原始GTID;即,复制到从属服务器的事务的服务器UUID是主服务器的UUID,而不是从属服务器的;复制链中的每个后续从属服务器都将记录该事务及其原始GTID,因此,复制拓扑中的每个从属服务器 可以确定第一个执行事务的主服务器;
2.每个GTID的形式为::0ed18583-47fd-11e2-92f3-0019b944b7f7:338;
3.GTID集包含一系列GTID:0ed18583-47fd-11e2-92f3-0019b944b7f7:1-338;
4.使用以下选项启用GTID模式:
1.gtid-mode=ON:与每个事务一起记录唯一的GTID;
2.enforce-gtid-consistency:禁止无法以事务安全方式记录的事件;
3.log-slave-updates:将复制的事件记录到从属服务器的二进制日志;
4.gtid_executed:记录事务的GTID;在全局上下文中,此变量包含记录到服务器的二进制日志的所有GTID集(表示此服务器和其他上游主服务器的所有事务);mysql> SELECT @@global.gtid_executed\G
5.gtid_purged:变量包含已经从二进制日志中清除的GTID集;在服务器上执行RESET MASTER时,gtid_purged和全局gtid_executed都将重置为空字符串;
-- 使用GTID进行复制;
使用CHANGE MASTER TO...启用GTID复制:
1.告知从属服务器通过GTID标识事务:CHANGE MASTER TO MASTER_AUTO_POSITION=1;
2.您不需要提供日志坐标(eg:MASTER_LOG_FILE,MASTER_LOG_POS);
1.启用基于GTID的复制时,不需要指定主服务器的日志坐标,因为从属服务器将@@global.gtid_executed的值发送给主服务器;
2.因此,主服务器知道从属服务器已经执行了哪些事务,从而仅发送从属服务器尚未执行的那些事务;
3.不能在同一CHANGE MASTER TO...语句中提供MASTER_AUTO_POSITION和日志坐标;
-- 使用GTID进行故障转移;
1.使用GTID时,循环拓扑中的故障转移很简单:
1.在发生故障的主服务器的从属服务器上,通过发出单个CHANGE MASTER TO语句绕过该主服务器;
2.每个服务器忽略或应用从拓扑中的其他服务器复制的事务,具体取决于是否看到了该事务的GTID;
2.非循环拓扑中的故障转移同样简单:
1.临时将新主服务器配置为最新从属服务器的从属服务器,直到该新主服务器变为最新;
3.虽然GTID可以防止源自单个服务器上的事件重复,但是它们不会防止源自不同服务器上的冲突操作,如标题为“复杂拓扑”的幻灯片中所述;
-- 复制过滤规则;
1.过滤器是应用于主服务器或从属服务器的服务器选项:
1.主服务器写入二进制日志时应用binlog-*过滤器;
2.从属服务器读取中继日志时应用replicate-*过滤器;
3.当环境中的不同服务器用于不同目的时,使用过滤规则;例如,专用于显示Web内容的服务器不需要从主服务器复制重新进货信息或工资记录,而专用于生成关于销售量的管理 报表的服务器不需要存储Web内容或市场营销副本;
2.基于以下各项选择要复制的事件:
1.数据库:
1.replicate-do-db, binlog-do-db
2.replicate-ignore-db, binlog-ignore-db
2.表:
1.replicate-do-table, replicate-wild-do-table
2.replicate-ignore-table, replicate-wild-ignore-table
3.过滤规则具有按顺序应用的复杂优先级规则:
1.数据库过滤器先于表过滤器应用;
2.表通配符过滤器*-wild-*在不使用通配符的那些过滤器之后应用;
3.*-do-*过滤器先于各个*-ignore-*过滤器应用;
4.使用多个过滤器时要谨慎,由于应用过滤器的顺序复杂,非常容易出错;因为过滤器控制要复制的数据,所以很难从此类错误中恢复,因此,不要混用不同类型的过滤器;
-- MySQL实用程序;
MySQL实用程序是提供许多有用功能的命令行工具:
1.随MySQL Workbench提供;
2.用于维护和管理MySQL服务器;
3.以Python编写,Python编程人员很容易使用提供的库对其进行扩展;
4.对于配置复制拓扑和执行故障转移非常有用;
-- 用于复制的MySQL实用程序;
1.mysqldbcopy:将数据库以及复制配置从源服务器复制到目标服务器;
1.mysqldbcopy实用程序接受选项--rpl,其在目标服务器上运行CHANGE MASTER TO语句;它接受以下值:
1.master:目标服务器变为源的从属服务器;
2.slave:源已经是其他主服务器的从属服务器,目标服务器从源复制该主服务器信息并变为同一主服务器的从属服务器;
2.mysqldbcompare:比较两个数据库来查找区别并创建脚本来同步这两个数据库;
3.mysqlrpladmin:管理复制拓扑:
1.在主服务器故障后故障转移到最佳从属服务器;
2.切换以升级指定的从属服务器;
3.启动,重置或停止所有从属服务器;
4.mysqlfailover:持续监视主服务器,并执行故障转移到最佳可用从属服务器:
1.mysqlfailover实用程序通过ping操作定期检查主服务器状态,期间间隔和ping操作都是可配置的;
2.它使用GTID确保新的主服务器在变为主服务器时是最新的,通过以下操作实现此项:
1.从候选列表中选择新主服务器(如果列表中没有可行的候选项,则从所有从属服务器中选择),将其配置为所有其他从属服务器的从属服务器来收集所有未完成事务,最后使其成为新主服务器;
2.mysqlrpladmin的failover命令在选择新主服务器时执行相似的临时重新配置;
3.如果主服务器失败,您还可以执行运行状况监视而不执行自动重新配置;
5.mysqlrplcheck:检查主服务器和从属服务器之间进行复制的先决条件,包括:
1.二进制日志记录;
2.具有适当特权的复制用户–server_id冲突;
3.可能导致复制冲突的各种设置;
6.mysqlreplicate:在两个服务器之间启动复制,报告不匹配警告消息;
7.mysqlrplshow:显示主服务器与从属服务器之间的复制拓扑或者递归显示整个拓扑;
mysqlrplshow 实用程序显示如下所示的复制拓扑:
# Replication Topology Graph localhost:3311 (MASTER)
|
+--- localhost:3312 - (SLAVE + MASTER)
|
+--- localhost:3313 - (SLAVE + MASTER)
|
+--- localhost:3311 < --> (SLAVE)
端口3311处的服务器出现两次:一次作为主服务器,一次作为从属服务器;< -->符号指示拓扑内的循环;
-- 异步复制;
1.从属服务器请求二进制日志并应用其内容,从属服务器通常滞后于主服务器;
2.主服务器不关注从属服务器何时应用日志,主服务器继续运行而不等待从属服务器;
3.在单独的线程中,主服务器将二进制日志流处理到连接的从属服务器,因为主服务器提交更改而不等待任何从属服务器的响应,所以这称为异步复制;
4.最重要的是,这意味着在主服务器向应用程序报告成功时从属服务器尚未应用事务;通常,这不是个问题,但是,如果在主服务器提交事务之后而该事务复制到任何从属服务器之前,该主服务器出现故障并且数据丢失,则该事务将丢失,即使应用程序已经向用户报告成功也是如此;
5.如果主服务器在提交事务之前等待所有从属服务器应用其更改,则复制称为是同步的;虽然MySQL复制不是同步的,但MySQL Cluster在内部使用同步复制来确保整个群集中的数据一致性,并且MySQL客户机请求是同步的,因为客户机在向服务器发出查询后等 待服务器响应;
-- 半同步复制;
半同步复制:
1.在主服务器和至少一个从属服务器上需要插件和启用选项:
1.插件:
1.rpl_semi_sync_master(在主服务器上)
2.rpl_semi_sync_slave(在从属服务器上)
2.选项:
1.rpl_semi_sync_master_enabled(在主服务器上)
2.rpl_semi_sync_slave_enabled(在从属服务器上)
3.如果在主服务器上启用半同步复制,它的行为是异步的,直到至少一个半同步从属服务器连接;
2.阻止每个主服务器事件,直到至少一个从属服务器接收该事件:
1.这意味着在主服务器向应用程序报告成功时至少一个从属服务器已经收到了每个事务;
2.如果主服务器在提交事务后出现故障且数据丢失并且应用程序已经向用户报告了成功,则该事务还存在于至少一个从属服务器上;
3.如果发生超时则切换到异步复制;
1.半同步复制需要您在性能和数据完整性之间进行权衡,使用半同步复制时事务速度比使用异步复制时慢,因为主服务器在提交之前等待从属服务器响应;
2.每个事务花费的额外时间至少是它为以下项花费的时间:
1.TCP/IP往返以将提交发送到从属服务器;
2.从属服务器在其中继日志中记录提交;
3.主服务器等待从属服务器确认该提交;
3.这意味着对于物理上位于同一位置,通过快速网络通信的服务器,半同步复制最有效;
4.如果主服务器在超时期间内没有收到半同步从属服务器的响应,该主服务器仍提交该事务,但恢复为异步模式;可以使用rpl_semi_sync_master_timeout变量配置超时,其包含以毫秒为单位的值,默认值是10000,表示十秒;
-- 测验;
b
-- 查看二进制日志记录;
二进制日志:
1.包含数据和模式更改及其时间戳:基于语句或基于行的日志记录;
2.用于从备份的时间点恢复,从备份的完全恢复以及复制;
3.在下列情况下轮转:
1.MySQL重新启动;
2.其达到max_binlog_size设置的最大大小;
3.您发出FLUSH LOGS语句;
4.可以各种方式进行检查:
1.元数据:SHOW BINARY LOGS,SHOW MASTER STATUS;
2.内容:mysqlbinlog;
-- 复制日志;
从属服务器维护有关复制事件的信息:
1.中继日志集:
1.包括中继日志和中继日志索引文件;
2.包含主服务器的二进制日志事件的副本;
3.MySQL自动管理中继日志文件集,在其已经重放了所有事件时删除这些文件并在当前文件超过最大中继日志文件大小时创建新文件;
4.中继日志使用与二进制日志相同的格式存储;可以使用mysqlbinlog查看那些日志;
5.默认情况下,中继日志文件名为-relay-bin.,索引文件名为-relay-bin.index;要使服务器配置不受将来可能的主机名更改影响,请通过设置以下选项来进行这些更改:--relay-log和--relay-log-index;
2.从属服务器状态日志:
1.包含执行复制所需的信息:
1.存储关于如何连接到主服务器的信息;
2.主服务器的二进制日志和从属服务器的中继日志的最近复制的日志坐标;
2.存储在文件或表中:
1.master.info和relay-log.info文件(默认情况下);
2.mysql数据库中的slave_master_info和slave_relay_log_info表;
1.主服务器信息:此日志包含关于主服务器的信息,包括主机名和端口,用于连接的凭证以及主服务器二进制日志的最近下载的日志坐标等信息;
2.中继日志信息:此日志包含中继日志的最近执行的坐标以及从属服务器的已复制事件落后于主服务器的那些事件的秒数;
-- 故障安全(Crash-Safe)复制;
1.二进制日志记录是故障安全的:
1.MySQL仅记录完成事件或事务;
2.使用sync-binlog提高安全性:
1.默认情况下,值是0,表示操作系统根据其内部规则向文件写入;
2.将sync-binlog设置为1,强制操作系统在每个事务之后写入文件,或者将其设置为任何较大数值以在该数量的事务 之后写入;
2.将从属服务器状态日志存储在表中以进行故障安全复制:
1.选项:master-info-repository和relay-log-info-repository;
2.可能值为FILE(默认值)和TABLE;
3.TABLE是故障安全的:复制使用事务存储引擎(例如InnoDB)的数据时,通过将master-info-repository和relay-log-info-repository的值从FILE(默认值)更改为TABLE,来将状态日志存储在事务表中以提高性能并确保故障安全复制;该表称为slave_master_info和slave_relay_log_info,都存储在mysql数据库中,并且都使用InnoDB引擎确保事务完整性和故障安全行为;
-- 复制线程;
MySQL在主服务器和从属服务器上创建线程来执行复制工作:
1.主服务器创建Binlog转储线程:
1.从二进制日志读取事件并将其发送到从属服务器I/O线程;
2.从属服务器成功连接到主服务器时,主服务器启动称为Binlog转储线程的复制主服务器线程;
3.如果从属服务器配置为使用自动定位协议(CHANGE MASTER TO MASTER_AUTO_POSITION),则该线程显示为“Binlog转储GTID”;在从属服务器已连接时,此线程会在二进制日志内的事件到达时将其发送到从属服务器;
4.主服务器为每个连接的从属服务器创建一个Binlog转储线程;
2.从属服务器至少创建两个线程:
1.从属服务器I/O线程:从主服务器的Binlog转储线程读取事件并将其写入从属服务器的中继日志;
2.从属服务器SQL线程:
1.在单线程从属服务器上应用中继日志事件:
1.默认配置会导致从属服务器滞后;
2.如果主服务器具有多个客户机连接则并行应用更改,但是串行执行其二进制日志中的所有事件;
从属服务器在单个线程中顺序执行这些事件,在高流量环境中或者当从属服务器的硬件不足以处理单个线程中的通信流量时,这会成为瓶颈;
2.在多线程从属服务器上的工作线程之间分配中继日志事件;
3.从属服务器工作线程:在多线程从属服务器上应用中继日志事件;
1.MySQL支持多线程从属服务器以避免单线程从属服务器引起的一些滞后;
2.如果在从属服务器上将slave_parallel_workers变量设置为大于零的值,它会创建该数量的工作线程;
3.在这种情况下,从属服务器SQL线程不直接执行事件,相反,它按数据库将事件分配给工作线程,这使多线程从属服务器在要在多个数据库中复制数据的环境中特别有用;
4.如果工作线程执行并行操作的顺序与其在主服务器上的执行顺序不同,此选项可能导致数
据库之间不一致,所以您必须确保不同数据库中的数据是独立的,由单个线程复制的一个数据库中的数据将保证是一致的;
5.如果将slave_parallel_workers变量设置为大于复制中所用数据库数量的值,一些工作线程将保持空闲;
-- 控制从属服务器线程;
1.控制从属服务器线程:
START SLAVE;
STOP SLAVE;
2.单独控制线程:
START SLAVE IO_THREAD;
STOP SLAVE SQL_THREAD;
3.启动线程直到指定的条件:
START SLAVE UNTIL SQL_AFTER_MTS_GAPS;
START SLAVE IO_THREAD UNTIL SQL_AFTER_GTIDS = 0ed18583-47fd-11e2-92f3-0019b944b7f7:338;
-- 监视复制;
mysql> SHOW SLAVE STATUS\G
***************** 1. row *********************
Slave_IO_State: Queueing master event to the relay log
...
Master_Log_File: mysql-bin.005
Read_Master_Log_Pos: 79
Relay_Log_File: slave-relay-bin.005
Relay_Log_Pos: 548
Relay_Master_Log_File: mysql-bin.004
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
...
Exec_Master_Log_Pos: 3769
...
Seconds_Behind_Master: 8
1.Slave_*_Running:Slave_IO_Running和Slave_SQL_Running列标识从属服务器的I/O线程和SQL线程当前正在运行,未运行还是正在运行但尚未连接到主服务器;可能值分别为Yes,No或Connecting;
2.主服务器日志坐标:Master_Log_File和Read_Master_Log_Pos列标识主服务器二进制日志中I/O线程已经传输的最近事件的坐标;这些列可与您在主服务器上执行SHOW MASTER STATUS时显示的坐标进行比较,如果Master_Log_File和Read_Master_Log_Pos的值远远落后于主服务器上的那些值,这表示主服务器与从属服务器之间事件的网络传输存在延迟;
3.中继日志坐标:Relay_Log_File和Relay_Log_Pos列标识从属服务器中继日志中SQL线程已经执行的最近事件的坐标;这些坐标对应于Relay_Master_Log_File和Exec_Master_Log_Pos列标识的主服务器二进制日志中的坐标;如果Relay_Master_Log_File和Exec_Master_Log_Pos列的输出远远落后于Master_Log_File和Read_Master_Log_Pos列(表示I/O线程的坐标),这表示SQL线程(而不是I/O线程)中存在延迟,即,它表示复制日志事件快于执行这些事件;在多线程从属服务器上,Exec_Master_Log_Pos包含任何未提交事务之前最后一点的位置,这并不始终与中继日志中的最近日志位置相同,因为多线程从属服务器在不同数据库上执行事务的顺序可能与二进制日志中显示的顺序不同;
4.Seconds_Behind_Master:此列提供中继日志中SQL线程执行的最近事件的时间戳(在主服务器上)与从属服务器的实际时间之间的秒数;当主服务器并行处理大量事件而从属服务器必须串行处理这些事件时,或者当高通信流量期间从属服务器的硬件不足以处理与主服务器可以处理的相同量的事件时,通常会发生这种类型的延迟;如果从属服务器未连接到主服务器,此列为NULL;
-- 复制从属服务器I/O线程状态;
从属服务器I/O线程的SHOW PROCESSLIST输出的State列中所显示的最常见状态,这些状态还显示在SHOW SLAVE STATUS显示的Slave_IO_State列中;
1.Connecting to master:线程正尝试连接到主服务器;
2.Waiting for master to send event:线程已经连接到主服务器并且正在等待二进制日志事件到达;如果主服务器处于空闲状态,此状态可能持续很长时间;如果等待持续slave_read_timeout秒,则发生超时,此时,线程考虑断开连接并尝试重新连接;
3.Queueing master event to the relay log:线程已经读取事件并且正在将其复制到中继日志,从而SQL线程可以处理该事件;
4.Waiting to reconnect after a failed binlog dump request:如果二进制日志转储请求失败(由于断开连接),线程在其休眠时转入此状态,然后定期尝试重新连接;可以使用--master-connect-retry选项指定重试之间的时间间隔;
5.Reconnecting after a failed binlog dump request:线程正尝试重新连接到主服务器;
6.Waiting to reconnect after a failed master event read:读取时出错(由于断开连接),线程在尝试重新连接之前休眠master-connect-retry秒;
7.Reconnecting after a failed master event read:线程正尝试重新连接到主服务器;重新建立连接后,状态变为Waiting for master to send event;
8.Waiting for the slave SQL thread to free enough relay log space:该状态显示正在使用非零relay_log_space_limit值,并且中继日志已经增加得足够大,以至其合并大小超过了此值;I/O线程正在等待,直到SQL线程通过处理中继日志内容以便可以删除一些中继日志文件来释放足够空间;
-- 复制从属服务器SQL线程状态;
从属服务器SQL线程和工作线程的State列中显示的最常见状态:
1.Waiting for the next event in relay log:这是Reading event from the relay log之前的初始状态;
2.Reading event from the relay log:线程已经从中继日志中读取了事件,从而可以处理该事件;
3.Making temp file:线程正在执行 LOAD DATA INFILE 语句,并且正在创建包含数据的临时文件,从属服务器从该数据中读取行;
4.Slave has read all relay log; waiting for the slave I/O thread to update it:线程已经处理了中继日志文件中的所有事件,现在正在等待I/O线程将新事件写入中继日志;
5.Waiting until MASTER_DELAY seconds after master executed event:SQL线程已经读取事件,但是正等待从属服务器延迟结束;通过CHANGE MASTER TO的MASTER_DELAY选项设置此延迟;
6.Waiting for an event from Coordinator:在多线程从属服务器上,工作线程正等待协调线程向工作队列分配作业;
-- 排除MySQL复制故障;
1.查看错误日志:错误日志可以为您提供足够信息来确定和更正复制中的问题;
2.在主服务器上发出SHOW MASTER STATUS语句:如果位置值非零则启用日志记录;
3.确认主服务器和从属服务器都具有唯一的非零服务器ID值:主服务器和从属服务器必须具有不同的服务器ID;
4.在从属服务器上发出SHOW SLAVE STATUS命令:
1.如果从属服务器运行正常,Slave_IO_Running和Slave_SQL_Running显示Yes;
2.Last_IO_Error和Last_SQL_Error:分别导致I/O线程或SQL线程停止的最新错误的错误消息;在正常复制过程中,这些字段是空的,如果发生错误并导致消息显示在以上任一字段中,则错误值也显示在错误日志中;
3.Last_IO_Errno和Last_SQL_Errno:与分别导致I/O线程或SQL线程停止的最新错误关联的错误编号,在正常复制过程中,这些字段包含编号0;
4.Last_IO_Error_Timestamp和Last_SQL_Error_Timestamp:分别导致I/O线程或SQL线程停止的最新错误的时间戳,格式为YYMMDD HH:MM:SS,在正常复制过程中,这些字段是空的;
-- 课后练习;
补充:
-- Master-Slave模式:
1.修改master端的配置文件my.cnf,如果需要指定只复制某几个数据库,使用binlog-do-db参数;
server-id = 1 # 必须是一个1 － 2^32-1的值,默认是1;
log-bin = mysql-bin # 这个参数在备库不需要设置,但是推荐设置;
2.设置slave端的配置文件my.cnf,如果需要指定只复制某几个数据库,使用replicate-do-db参数;不推荐使用master-host这几个参数,实验中总是起不来mysql服务,貌似已经弃用了;
server-id = 2
log-bin = mysql-bin
3.启动master端和slave端的mysql服务;
4.在master端创建用户复制的用户:grant replication slave on *.* to 'repl_slave'@'192.168.10.56' identified by 'mysql';
5.查看master端二进制日志的状态:show master status;(如果有业务在写数据,可以先flush tables with read lock,把数据dump出来,然后unlock tables解锁,把数据同步到slave端);
6.在slave端执行CHAGE MASTER TO命令,然后开启slave模式:CHANGE MASTER TO MASTER_HOST='192.168.10.66', MASTER_PORT=3306, MASTER_USER='repl_slave', MASTER_PASSWORD='mysql', MASTER_LOG_FILE='mysql-bin.000003', MASTER_LOG_POS=265;
7.启动slave复制:start slave;然后查看slave端的状态:show slave status;(如果发生uuid冲突,删除$MYSQL_DATADIR/auto.cnf文件,MySQL会创建该文件并生成新的UUID,将其放在该新文件中;)
8.在slave端会生成保存master端状态的master.info文件,以及中继日志文件(mysql-relay-bin.NNNNNN);
9.查看slave端的进程,发现多了系统两个进程:show processlist;
10.在master端写入数据,slave端马上可以查看到,测试成功;
-- Master-Master模式:
1.在Master-Slave基础上;
2.在slave端创建用户复制的用户:grant replication slave on *.* to 'repl_slave'@'192.168.10.66' identified by 'mysql';
3.查看slave端二进制日志的状态:show master status;
4.在master端执行CHAGE MASTER TO命令,然后开启slave模式:CHANGE MASTER TO MASTER_HOST='192.168.10.56', MASTER_PORT=3306, MASTER_USER='repl_slave', MASTER_PASSWORD='mysql', MASTER_LOG_FILE='mysql-bin.000003', MASTER_LOG_POS=265;
5.启动slave复制:start slave;然后查看slave端的状态:show slave status;(如果发生uuid冲突,手动修改auto.cnf中uuid的值)
6.在master端会生成保存slave端状态的master.info文件,以及中继日志文件(mysql-relay-bin.NNNNNN);
7.查看slave端的进程,发现多了系统两个进程:show processlist;
8.其实Master-Master模式就是把Master-Slave反向再做一次而已;
-- MySQL半同步复制(Semi-Synchronous Replication)
1.配置Master服务器端:
1.安装插件:install plugin rpl_semi_sync_master soname 'semisync_master.so';(通过视图查看:SELECT * FROM information_schema.PLUGINS WHERE PLUGIN_NAME='rpl_semi_sync_master'\G);
2.设置开启半同步复制:set global rpl_semi_sync_master_enabled=1;
3.设置延迟时间,即Master等待Slave响应的时间:set global rpl_semi_sync_master_timeout=1000;默认为10s,修改为1s;
4.并在配置文件my.cnf中添加rpl_semi_sync_master_enabled=1,rpl_semi_sync_master_timeout=1000设置,以后重启服务就不用重新配置;
5.查看设置的变量:show variables like 'rpl%';
2.配置Slave服务器端:
1.安装插件:install plugin rpl_semi_sync_slave soname 'semisync_slave.so';
2.设置开启版同步复制:set global rpl_semi_sync_slave_enabled=1;
3.在配置文件my.cnf中添加rpl_semi_sync_slave_enabled=1之后重启服务就不用重新配置;
4.查看设置的变量:show variables like 'rpl%';
3..取消插件:uninstall plugin rpl_semi_sync_master;
-- 设置GTID复制:
1.设置数据库只读:SET @@global.read_only = ON;
2.停止停止所有的slave:stop slave;并关闭所有的数据库;
3.修改配置文件;
在my.cnf中添加配置:
[mysqld]
gtid_mode=ON # 开启gtid模式;
log-slave-updates=ON
enforce-gtid-consistency=ON # 强制GTID的一致性;
4.从库指向主库;
CHANGE MASTER TO MASTER_HOST='192.168.10.66', MASTER_PORT=3306, MASTER_USER='repl_slave', MASTER_PASSWORD='mysql', MASTER_AUTO_POSITION = 1;
START SLAVE;
5.设置数据库读写:SET @@global.read_only = OFF;