长沙网站制作工作室,手机记事本做网站,个人买域名有什么用,广州高端网站建设公司开启binlog后#xff0c;如何使用binlog的功能#xff0c;部署复制架构#xff0c;通过Replication来实现读写分离、高可用呢? 一. 配置复制的方式 1.1 位点通过指定主库的二进制日志的当前位点来进行数据的同步#xff0c;通过change master to命令进行配置。 位点怎么获… 开启binlog后如何使用binlog的功能部署复制架构通过Replication来实现读写分离、高可用呢? 一. 配置复制的方式 1.1 位点通过指定主库的二进制日志的当前位点来进行数据的同步通过change master to命令进行配置。 位点怎么获取呢 在主库执行show master status File、Position列的信息指出了当前的二进制文件和位置信息执行mysqldump --master-data1/2记录下change master to信息使用mydumper工具进行逻辑备份查看metadata文件 v0.9.5还不支持mysql 8.0的caching_sha2_password认证插件需要改成mysql_native_password认证插件使用percona-xtrabackup工具进行物理备份查看备份目录下的xtrabackup_binlog_info文件在从库上的备份(使用--slave-info选项并行复制环境需要MySQL开启GTID)查看备份目录下的xtrabackup_slave_info文件获取到位点后执行change master to命令 change master to \master_host,\master_userxx,\master_passwordxx,\master_port,\master_log_file,\master_log_posbinlog position;基于位置点的方式如出现错误(在5.6版本之前常见1032找不到行、1062 主键冲突)可以通过设置sql_slave_skip_counter跳过事务(事务表非事务表是指事件)或通过change master to语句重新指定。 1.2 GTID 5.6 开始支持GTID(Global Transaction Identifier)全局事务标识符由UUID(实例的唯一标识存储在数据目录的auto.cnf文件中)和sno(单调递增的序号)组成用来唯一标识一个事务一个事务的GTID在所有复制集群中都是一致和唯一的。 通过使用GTID减少了用位点建立复制的困难性如用位点时当原master发生切换后其余的slave要跟新master建立复制关系需要确定位点就比较繁琐如使用GTID模式都不需要关心位点通过主从自动定位(MASTER_AUTO_POSITION)就可以知道差异的事务。 基于GTID如发生错误时可以用空事务的方式跳过事务(有损方式依情况而定为了避免数据的一致性如出现从库数据异常建议重新搭建从库或结合pt-table-checksum、pt-table-sync工具进行主从数据校验和差异数据补偿) SET GTID_NEXTaaa-bbb-ccc-ddd:N;BEGIN;COMMIT;SET GTID_NEXTAUTOMATIC; 二. 如何保障复制的安全?什么是复制安全当slave挂掉后能够重新从挂掉的位置开始进行事件的拉取和应用即需要保障IO线程和SQL线程的安全同时保证redo安全写入磁盘保障innodb存储引擎的持久性。IO线程从主库接收事件然后将事件写入到relay log同时也会记录位置信息写入到master.info文件由参数sync_master_info控制fsync操作为0时将由OS进行刷新。SQL线程从relay log读取事件并进行应用同时记录位置信息写入到relay-log.info文件由参数sync_relay_log_info控制fsync操作为0时将由OS进行刷新。在5.5时位置点信息都是依赖文件进行存储如果设置 sync_master_info1和 sync_relay_log_info1因每次写一个事务就要将位置信息写入磁盘造成性能很差 如果从库发生crashSQL线程可能从relay log读取已经应用过的事件引起主从中断同时如表无唯一键时还会造成主从数据不一致的问题。5.6开始支持将位置信息存储到数据库里面通过参数master_info_repositoryTABLE和relay_log_info_repositoryTABLE进行控制分别存储在 mysql.slave_master_info和slave_relay_log_info表中利用事务的特性解决了将位置信息存储在文件中位置跟事务不一致的问题(主要是解决SQL线程IO线程因是写relay log文件还是会存在不一致)同时参数relay_log_recovery1可以在slave crash时让IO线程从SQL线程的位点开始重新拉取事件写入到新的relay logSQL线程从其位点进行事件的应用。使用GTID时通过Executed_gtid_set(变量gtid_executed)判断跟主库的差异不依赖relay log进行恢复在5.6时因变量gtid_executed是内存存储需要依赖binlog进行GTID信息的获取5.7开始使用表(mysql.gtid_executed)存储GTID信息不需要依赖binlog进行恢复。gtid_executed表结构如下 当使用并行复制时多个worker线程并行进行事件的应用可能会出现后写入的事件在从库先执行如果从库发生crash将会出现gap5.7使用参数slave_preserve_commit_order1slave_parallel_typeLOGICAL_CLOCK避免gap发生。5.7.28开始如果使用GTID模式slave的恢复也不再依赖relay log就只需要保证GTID信息的一致性就可以保障slave crash安全而GTID信息已经存储到了表中即只要保证事务的持久性设置双1(sync_binlog1,innodb_flush_log_at_trx_commit1)。 小结下相关各版本保证slave crash安全的配置 三. 自动化工具在面临一主多从以及从备份中进行数据恢复进行扩容或备份恢复效验怎么实现自动化的进行主从环境配置呢我们可以通过编写各种脚本实现自己所需的功能同时我们也可以使用现成的工具如MySQL Utilities的mysqlreplicate现在已经没更新了使用MySQL Shell8.0.22 也开始支持异步复制自动FAILOVER机制当复制源节点发生错误时可以自动地从另一个复制源进行复制有没有发现借鉴了MongoDB的特性 。自己编写工具时如用Python Django编写一个视图提供一个POST的接口(可提供用户名、密码、位点等信息)结合celery进行任务队列调度测试环境可以使用DBdeployer工具来快速的搭建一个环境其支持各种版本和复制架构的部署。 四. 监控通过show slave status的Seconds_Behind_Master值来监控延迟Slave当前时间戳和正在处理事件记录的时间戳之间的差值实际是测量的SQL线程和I/O线程的时间差值如果网络慢I/O线程慢就不准确了(如从监控上看突然一个小尖刺)。通过pt-heatbeat进行心跳监控默认每秒通过往主库一张表里面更新时间戳对比主从时间戳的差值来判断延迟相对于SBM值来说更精确。心跳表的表结构 CREATE TABLE heartbeat ( ts varchar(26) NOT NULL, server_id int(10) unsigned NOT NULL, file varchar(255) DEFAULT NULL, position bigint(20) unsigned DEFAULT NULL, relay_master_log_file varchar(255) DEFAULT NULL, exec_master_log_pos bigint(20) unsigned DEFAULT NULL, PRIMARY KEY (server_id)) ENGINEInnoDB;监控命令 pt-heartbeat \-D test --update \--create-table \-h 127.0.0.1 \-P 3307 \--daemonize -D指定存放心跳表的db名称--create-table当心跳表不存在时进行自动的创建--daemonize放置后台进行持续的心跳表更新 使用以下命令查看延迟(连接到从库)或其他orzdba工具mysqld_exporter也支持该工具进行从库延迟的监控 pt-heartbeat \-D test \--monitor \-h 127.0.0.1 \-P 3307 使用Prometheus的mysqld_exporter进行主从延迟的监控需要给账号授权process,select(查询pt-heartbeat心跳表),replication slave,replication client 启动命令 mysqld_exporter \--collect.heartbeat.databasetest \--collect.heartbeat \--config.my-cnf/root/.my.cnf 连接数据库的用户名和密码信息写在/root/.my.cnf文件(安全性有点弱设置好文件的权限)如 [client]userpasswordhost127.0.0.1port3307 关于主从延迟的监控项是mysql_slave_lag_seconds当使用心跳表时延迟监控项为mysql_heartbeat_lag_seconds。 # Record slave lag seconds for pre-computed timeseries that takes# mysql_slave_status_sql_delay into accountmysql_slave_lag_seconds mysql_slave_status_seconds_behind_master - mysql_slave_status_sql_delay# Record slave lag via heartbeat methodmysql_heartbeat_lag_seconds mysql_heartbeat_now_timestamp_seconds - mysql_heartbeat_stored_timestamp_seconds IO和SQL线程状态的监控是mysql_slave_status_slave_io_runningmysql_slave_status_slave_sql_running。 五. 总结Replication是MySQL高可用和读写分离的一个非常重要的机制为了保障主从的高可用需要确保主从库都设置为双1同时使用GTID模式同时避免各个版本的差异在5.7版本开始推荐配置如下(从库开启binlog是在高可用环境下从库也可能切换为主库) server_id 100 #复制集内实例保证唯一relay_log_recovery ON #IO线程安全relay_log_info_repository TABLE #SQL线程安全binlog_formatROWlog-binmysql-binlog_slave_updates 1gtid_mode 1enforce_gtid_consistency 1loose_slave_preserve_commit_order ONsync_binlog 1innodb_flush_log_at_trx_commit 1# 5.7.22之后版本loose_slave-parallel-typeLOGICAL_CLOCKloose_slave-parallel-workers8loose_transaction_write_set_extractionXXHASH64loose_binlog_transaction_dependency_trackingwriteset全文完辛苦你的眼睛做个眼保健操吧 如果文章对您有帮助请友情帮转发点赞哦
