加入收藏 | 设为首页 | 会员中心 | 我要投稿 核心网 (https://www.hxwgxz.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 编程 > 正文

MySQL的复制性能

发布时间:2022-03-23 04:59:17 所属栏目:编程 来源:互联网
导读:什么是复制功能? MySQL 的复制功能是将备份的数据移动到其他服务器的功能,通过简单的设定即可使用 主从(master -slave)架构。 主服务器上发生数据变更,变更内容传送到从服务器,从服务器接受主服务器的变更内容, 将变更内容反映到数据库。 复制功能的
       什么是复制功能?
      MySQL 的复制功能是将备份的数据移动到其他服务器的功能,通过简单的设定即可使用
 
      主→从(master ->slave)架构。
 
      主服务器上发生数据变更,变更内容传送到从服务器,从服务器接受主服务器的变更内容,
 
      将变更内容反映到数据库。
 
复制功能的优点
1. 提高查询性能
 
     查询处理负载高的情况下,可以通过增加从服务器来实现负载均衡,提高性能
 
2. 实现高可用性
 
     主服务器发生故障时,可以将从服务器升级为主服务器
 
3. 实现异地复制
 
构建异地容灾系统
 
4. 用作备份服务器
 
在从服务器上进行备份,可以不影响主服务器的性能
 
例如可以实现主服务器不停机运行,将从服务器的数据库停止以后进行备份
 
复制功能的组成
主服务器的所有变更点都记录在二进制日志里面。二进制日志里记录了与更新相关的SQL文,执行查询的日期时间等元数据也记录在内。事务提交的同时以二进制的形式进行记录(sync_binlog=1)。
 
mysqlbinlog 命令可以查看日志内容。指定启动选项进行输出二进制日志。
 
--log-bin[=file_name]
 
推荐将输出路径与数据文件路径放在不同的硬盘上。日志文件的扩展名以连号的形式记录
 
例)file_name-bin.001, file_name-bin.002, 等等。当前正在使用的日志号码会记录在索引文件里面 (file_name.index)
 
 
 
主服务器的所有变更点都记录在日志里面,在从服务器启动复制功能,将二进制日志的内容传送到从服务器后执行。
 
 
 
从服务器上的文件、线程
文件
 
中继日志文件:记录主服务器变更点的文件。
 
二进制日志文件:记录从服务器变更点的文件。 (log-slave-updates有效时才会输出)
 
master.info :记录连接主服务器的必要信息、读取日志起始位置等信息的文件。 (MySQL 5.6开始可以保存在表内)
 
relay-log.info :记录中继日志执行位置的文件。  (MySQL 5.6开始可以保存在表内)
 
线程
 
I/O 线程:将从主服务器上接收的二进制日志作为中继日志保存
 
SQL 线程:将中继日志里面的更新内容反映到DB里面
 
复制的种类
二进制日志的记录方式不同
 
STATEMENT :文(SQL文)
 
ROW :行
 
MIXED :文和行混合
 
 
 
不确定的SQL文——执行过程中结果可能会发生变化的SQL
 
UUID() 、UUID_SHORT()
 
USER()
 
FOUND_ROWS()
 
LOAD_FILE()
 
SYSDATE()
 
GET_LOCK() 、RELEASE_LOCK()
 
IS_FREE_LOCK() 、IS_USED_LOCK()
 
MASTER_POS_WAIT()
 
SLEEP()
 
VERSION()
 
没有排序的LIMIT句
 
UDF 、非决定性的存储过程/函数
 
查询INFORMATION_SCHEMA
 
READ-COMMITTED/READ-UNCOMMITTED
 
 
 
同步方式不同
 
异步:将变更点异步传送
 
半同步:将变更点同步传送,向DB反映时候为异步
 
 
 
异步(默认)
 
异步传送变更点
 
优点:相比半同期方式,主服务器的更新响应迅速
 
缺点:主服务器发生故障时,故障发生前的部分内容可能没有传送到从服务器
 
适用于负载均衡
(故障发生前的数据需要保护的情况下,需要应用程序对应)
 
半同步(MySQL 5.5开始追加的功能)
 
变更点同步传送,异步将数据向DB反映
 
优点:主服务器发生故障时,故障发生前的更新数据可以确保传送到从服务器
 
缺点:与异步模式相比主服务器的更新响应差
 
适用于高可用性的运用 (需要保护故障发生前的更新数据)
 
 
 
是否使用GTID
 
不使用GTID传统的复制模式
 
使用GTID:MySQL 5.6新追加的模式
 
多台服务器组成的复制环境里可以很容易的跟踪比较事务
 
事务在全局里拥有唯一的识别ID,可以记录在二进制日志里面
 
使用时和传统的方式有变化
 
复制开始时自动识别位置
 
故障切换时,可以自动识别最新的从服务器
 
很容易组成多层复制
 
 
 
GTID 的优点:
 
可以自动识别日志文件里的位置,不需手动指定
(主服务器发生故障时,无需确认日志的位置可以实现故障切换)
 
GTID 的缺点:
 
限制因素
 
只能使用InnoDB
 
不能使用“CREATE TABLE ... SELECT“
 
不能在事务中使用“CREATE TEMPORARY TABLE” 和 "DROP TEMPORARY TABLE"
 
不支持sql_slave_skip_counter
 
从服务器需要输出二进制日志
 
无法使用复制功能的过滤功能,使用过滤功能GTID里面会出现从未使用过的ID
 
使GTID有效需要全部的服务器停止后再转成GTID模式。
 
MySQL 5.7 可以每台服务器轮番启动设置GTID
 
 
 
复制功能的设定方法(不使用GTID)
 
1 .设定复制功能的参数
 
2 .在主服务器上建立复制用的用户
 
3 .备份主服务器数据,将其恢复到从服务器,需要记录备份时的二进制日志名称和位置
 
4 .从服务器上执行 CHANGE MASTER TO
 
5 .从服务器上执行 START SLAVE
 
 
 
主服务器:设置下记选项后启动
 
server-id
 
log-bin
 
datadir *
 
从服务器:设置下记选项后启动
 
server-id
 
datadir *
 
port *
 
socket *   (Lunix 系OS)
 
read_only   ( 推荐设置)
 
 
 
给用户赋予“REPLICATION SLAVE”权限
 

 
CREATE USER 'repl'@'localhost' IDENTIFIED BY 'repl';
 
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'localhost';
 
 
 
将主服务器的备份数据恢复到从服务器(不使用GTID)
 
将冷备份的数据恢复
 
使用mysqldump进行数据备份和恢复
 
备份
 
 $ mysqldump --user=root --password=root --master-data=2
 
 --socket=/usr/local/mysql/data/mysql.sock
 
 --hex-blob --default-character-set=utf8 --all-databases
 
 --single-transaction > mysql_bkup_dump.sql
 
※需要记录备份的日志文件名称和位置
 
补充:mysqldump的选项
 
--master-data=2
 
将备份时的文件名和位置作为注释记录在备份文件里
 
--hex-blob
 
将二进制类型(BINARY、VARBINARY、BLOG) 和BIT类型的数据以16进制输出
 
--default-character-set
 
设置mysqldump的默认字符
 
通常情况下与系统变量default-character-set设置一致
 
--all-databases
 
备份全部的数据库
 
--lock-all-tables
 
将所有的表加锁后进行备份
 
--single-transaction
 
利用InnoDB支持的事务处理,对InnoDB的表进行一致性备份
 
 
 
注意事项:使用mysqldump备份
 
为了保证数据的完整性,备份中不执行DDL(※)
 
ALTER TABLE, CREATE TABLE, DROP TABLE, RENAME TABLE, TRUNCATE TABLE
 
 
 
引用手册里关于”--single-transaction”的说明
 
「While a --single-transaction dump is in process, to ensure a valid dump file (correct table contents and binary log coordinates), no other connection should use the following statements: ALTER TABLE, CREATE TABLE, DROP TABLE, RENAME TABLE, TRUNCATE TABLE.
 
4 .从服务器上执行 CHANGE MASTER TO
 
5 .从服务器上执行 START SLAVE  (不使用GTID)
 
执行CHANGE MASTER TO
 
执行START SLAVE
 

 
CHANGE MASTER TO MASTER_HOST=‘localhost',
 
 -> MASTER_USER=‘repl',
 
 -> MASTER_PASSWORD=‘repl',
 
 -> MASTER_LOG_FILE='bin.000001',
 
 -> MASTER_LOG_POS=1790;
 
 START SLAVE;
 
 
 
  复制功能的设定方法(使用GTID)
 
1 .设定复制功能的参数
 
2 .在主服务器上建立复制用户
 
3 .将主服务器的数据备份后恢复到从服务器,无需使用日志的名称和位置
 
4 .从服务器执行 CHANGE MASTER TO
 
5 .从服务器执行 START SLAVE
 
 
 
1 .设置复制功能的参数(使用GTID)
 
主服务器:设置以下选项后启动
 
server-id
 
log-bin
 
datadir *
 
gtid-mode=on
 
enforce-gtid-consistency=on
 
log-slave-updates
 
从服务器:设置以下选项后启动
 
server-id
 
log-bin
 
datadir *
 
port *
 
socket *   ( 使用Lunix)
 
read_only   ( 推荐设置)
 
gtid-mode=on
 
enforce-gtid-consistency=on
 
log-slave-updates
 
赋予用户“REPLICATION SLAVE”权限
 

 
CREATE USER ‘repl'@'localhost' IDENTIFIED BY ‘repl';
 
GRANT REPLICATION SLAVE ON *.* TO ‘repl'@'localhost';
 
 
 
3 .将主服务器的数据备份后恢复到从服务器(使用GTID)
 
冷备份后恢复数据
 
删除Datadir下面的auto.cnf
 
( 目的为主从服务器的server-uuid一致(※))
 
 
 
使用mysqldump进行备份和恢复
 
备份例
 
 $ mysqldump --user=root --password=root –master-data=2
 
 --socket=/usr/local/mysql/data/mysql.sock
 
 --hex-blob --default-character-set=utf8 --all-databases
 
 --single-transaction --triggers --routines --events > mysql_bkup_dump.sql
 
 
 
 4 .从服务器执行 CHANGE MASTER TO
 
 5 .从服务器执行 START SLAVE (使用GTID)
 

 
CHANGE MASTER TO MASTER_HOST=‘localhost',
 
 -> MASTER_USER=‘repl',
 
 -> MASTER_PASSWORD=‘repl',
 
 -> MASTER_AUTO_POSITION=1;
 
 START SLAVE;
 
 
 
管理日志
 
使用SHOW MASTER STATUS 确认现在的日志名称和位置
 
使用SHOW MASTER LOGS 列出全部的日志文件名
 
使用FLUSH [BINARY] LOGS 命令或者MySQL服务器再启动的时候日志轮换
 
使用PURGE MASTER 删除特定时点的日志
 
使用RESET MASTER 删除全部的日志
 
管理复制功能的命令(从服务器)
 
START SLAVE [SLAVE_TYPE] 启动从服务器
 
STOP SLAVE [SLAVE_TYPE] 停止从服务器
 
SHOW SLAVE STATUS 确认从服务器的状态
 
确认I/O线程传送二进制日志的位置
 
确认SQL线程执行的relay日志位置
 
STOP SLAVE;
 
SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1;
 
STAT SLAVE; 忽略下一个事务
 
发生错误时,确认状态以后需要将特定的事务忽略的情况下使用
 
GTID 模式下该方法不适用
 
 
 
其他注意事项
 
MySQL 复制自身不具备的功能
 
高可用时候的故障切换功能
 
 =>MySQL 5.6的MySQL Utilities提供自动故障切换的脚本
 
读写分离、负载均衡的控制功能
 
 =>Connector/J(Java)或mysqlnd_ms(PHP)等可以控制
 
一次不要执行大量的更新处理
 
防止从服务器的延迟
 
主服务器事务提交后,将变更的内容传送到从服务器,如果事务执行时间过长的话,反映到从服务器会产生延迟
 
 
 
监视复制功能
通过SHOW SLAVE STATUS的结果,来监视下面内容
 
I/O 线程、SQL线程是否正常活动?
 
I/O 线程 : Slave_IO_Running
 
SQL 线程 : Slave_SQL_Running
 
复制是否有延迟?
 
复制是否有延迟 : Seconds_Behind_Master
 
二进制日志和中继日志的执行位置等
 
二进制日志的传送状况 : Master_Log_File、Read_Master_Log_Pos
 
中继日志的执行状况 : Relay_Master_Log_File、Exec_Master_Log_Pos
 
确认网络延时需要在主服务器上执行SHOW MASTER STATUS 来确认。(比较SHOW SLAVE STATUS 的Master_Log_File、Read_Master_Log_Pos)
 
监视慢查询日志
 
确认延迟原因和查询执行时间长的原因
 
主从服务器的磁盘剩余空间
 
从服务器的磁盘空间减少的话无法删除中继日志,复制功能会停止
 
主从服务器的资源使用状况
 
(CPU 、内存、I/O量,网络流量)
 
复制功能构成高可用性
优点
 
MySQL 的标准功能不需要使用共享磁盘、软件等等,成本低廉
 
可以实现高可用性和查询处理的负载均衡
 
缺点
 
故障切换需要使用其他方法实现,运用的时候考虑事项较多
 
发生故障时候,使用什么样的方法进行切换?
 
发生故障切换的时候,应用程序的连接需要切换
 
(MySQL 5.5 之前) 没有崩溃安全机制,从服务器发生故障时,需要重新安装从服务器。

(编辑:核心网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    热点阅读