MySQL中sync_relay_log选项对I/O thread的影响分析

最新推荐文章于 2021-02-17 13:26:15 发布

转载最新推荐文章于 2021-02-17 13:26:15 发布 · 207 阅读

搭建好的一套从库，发现延迟很高，一直追不上，从库的bin_log没开，flush_log_at_trx_commit设置为0，简化的状态如下：

发现Master_Log_File,Read_Master_Log_Pos一直进展比较缓慢，一般来说内网的瓶颈不会在网络，同时一般I/O THREAD并不存再CPU密集型操作，那么瓶颈很可能在I/O,使用iotop命令查看服务器I/O情况如下：

>>>阅读全文

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

sweetfire

关注关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
分享

复制链接

分享到 QQ

分享到新浪微博

扫一扫
举报

举报

MySQL半同步与sync_relay_log关系1

敖尔其楞的专栏

06-04

488

sync_relay_log 肯定是与relay log相关，所以从rpl_slave.cc处理relay log的代码开始入手 extern "C" void *handle_slave_io(void *arg) /* XXX: 'synced' should be updated by queue_event to indicate whether event has been synced to disk */ bool synced= 0; if (que

MySQL四种日志binlog/redolog/relaylog/undolog

程序猿进阶

08-08

1808

因为功能的不同，redo log 存储的是物理数据的变更，如果我们内存的数据已经刷到了磁盘了，那redo log的数据就无效了。这也应该容易理解，毕竟回滚嘛，跟需要修改的操作相反就好，这样就能达到回滚的目的。的存在为了：当我们修改的时候，写完内存了，但数据还没真正写到磁盘的时候。时，并不是马上就刷入中继日志里，而是由操作系统决定何时来写入，虽然安全性降低了，但减少了大量的磁盘。中继日志里，这样是最安全的，因为在崩溃的时候，你最多会丢失一个事务，但会造成磁盘的大量。我们还是会对这次的事务回滚，将无效的。

参与评论您还未登录，请先登录后发表或查看评论

mysql 5.7 1秒延迟_MySQL 5.7复制延迟之sync_relay_log

weixin_42514288的博客

02-17

171

一、描述MySQL 5.7版本主从复制，批量时候显示延迟上万秒。二、现象1、io使用率高#iostat -dxm 1 1000Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %utilscd0 0.00 0.00 ...

MYSQL sync_relay_log对I/O thread的影响分析

cri5768的博客

04-21

248

搭建好的一套从库，发现延迟很高，一直追不上，从库的bin_log没开，flush_log_at_trx_commit设置为0，简化的状态如下： mysql> show slave status \G ***...

sync_relay_log_info

zhaoyangjian724的专栏

07-04

1637

slave上的sync_relay_log_info 值有server 的relay_log_info_repository 决定（FILE OR TABLE) 如果是表, 额外的用于relay log info表时transactional 的(比如InnoDB) 或者(MyISAM) 如果是TABLE 且是Transactional ，每一笔交易后，该表被更新。（

sync_relay_log

zhaoyangjian724的专栏

07-04

1707

sync_relay_log : If the value of this variable is greater than 0, the MySQL server synchronizes its relay log to disk (using fdatasync()) after every sync_relay_log events are written to the relay

mysql sync relay log_MySQL 5.7复制延迟之sync_relay_log

weixin_35201342的博客

01-19

355

二、现象1、io使用率高#iostat -dxm 1 1000Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %utilscd0 0.00 0.00 0.00 0.00 0.00 0.0...

如果将relay_log_recovery设置为0会发生什么？

woqutechteam的博客

01-21

1771

| 背景在MySQL5.7版本中，开启并行复制后，设置relay-log-recovery=1，从库启动后偶尔会报错，类似于https://bugs.mysql.com/bug.php?id=83713。所以尝试将relay-log-recovery设置为0，观察会发生什么。 | 环境 MySQL5.7.22 GTID模式 relay-log-recovery=0 ...

mysql数据库relay_完美起航-MySQL案例实战--MySQL数据库主从复制--高级进阶功能

weixin_35538148的博客

02-08

297

前言本环境是基于 Centos 7.8 系统构建MySQL-5.7.14具体构建，请参考 MySQL-5.7.14 环境构建一、延时同步功能介绍是我们人为配置的一种特殊从库.人为配置从库和主库延时N小时.为什么要有延时从：解决数据库故障的问题物理损坏: 主从复制非常擅长解决物理损坏，比如主库rm 删除数据库数据，直接将应用切换到从库.逻辑损坏：普通主从复制没办法解决逻辑损坏，比如主库 drop d...

mysql8.0 malloc_mysql8.0.20 二进制安装

weixin_39541869的博客

02-04

184

关闭selinuxsed -i 's/SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/configsetenforce 0修改系统限制参数cat >> /etc/security/limits.conf << EOF####custom#* soft nofile 20480* ...

MySQL5.1主从同步出现Relay log read failure错误解决方法

09-10

主要介绍了MySQL5.1主从同步出现Relay log read failure错误解决方法,需要的朋友可以参考下

mysql sync_relay_log_MySQL 5.7复制延迟之sync_relay_log

weixin_39990138的博客

01-19

238

mysql syncrelaylog_MySQL 5.7复制延迟之sync_relay_log

weixin_39928480的博客

01-19

347

MySQL 5.7复制延迟之sync_relay_log

bitan9646的博客

09-16

634

一、描述MySQL 5.7版本主从复制，批量时候显示延迟上万秒。二、现象 1、io使用率高 #iostat -dxm 1 1000 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util scd0 0.00 ...

sync_relay_log&sync_relay_log_info等参数

jc_benben的专栏

03-29

6868

有时候为了避免master.info和中继日志崩溃，在容忍额外的fsync()带来的开销，推荐设置 sync_master_info = 1 sync_relay_log = 1 sync_relay_log_info = 1 当然，如果备库跟主库延迟特别大，备库的io线程谢了很多中继日志，通过relay_log_purge设置，sql线程重放完一个中继日志中的事件后会尽快将删除。

mysql sync relay log_MYSQL sync_relay_log对I/O thread的影响分析

weixin_42512183的博客

01-19

161

搭建好的一套从库，发现延迟很高，一直追不上，从库的bin_log没开，flush_log_at_trx_commit设置为0，简化的状态如下：mysql> show slave status \G*************************** 1. row ***************************Slave_IO_State: Queueing master event...

mysql sync relay log_MySQL的诡异同步问题-重复执行一条relay-log

weixin_36162906的博客

01-19

313

MySQL的诡异同步问题近期遇到一个诡异的MySQL同步问题，经过多方分析和定位后发现居然是由于备份引发的，非常的奇葩，特此记录一下整个问题的分析和定位过程。现象同事扩容的一台slave死活追不上同步，具体的现象是SBM=0，但是Exec_Master_Log_Pos执行的位置和Read_Master_Log_Pos完全对不上，且服务器本身CPU和IO都消耗的非常厉害。——total-cpu-us...

mysql 启动不见了计算机管理_MySQL的日志 - relay log

weixin_39635567的博客

01-05

302

[client] port=3306 [mysql] no-beep default-character-set = utf8mb4 [mysqld] init_connect='SET autocommit=0;' init_file=E:\\MySQL\\init.sql # 基础配置 port=3306 datadir=E:\MySQL\Data default-storage-engine=INNODB server-id=1 lower_case_table_names=1 secure-file-priv="C:/ProgramData/MySQL/MySQL Server 8.2/Uploads" # 修复连接问题的关键设置 bind-address=0.0.0.0 # 允许所有IP连接 skip_name_resolve=ON # 禁用DNS反向解析 # 认证策略修复 authentication_policy=mysql_native_password, # 字符集 character-set-server=utf8mb4 collation-server=utf8mb4_0900_ai_ci # SQL模式 sql-mode="ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION" # 日志配置 log-output=FILE general-log=0 general_log_file="XIANJH.log" slow-query-log=1 slow_query_log_file="XIANJH-slow.log" long_query_time=3 log-error="XIANJH.err" log-bin="XIANJH-bin" binlog_expire_logs_seconds=604800 # 内存优化 max_connections=300 table_open_cache=5000 table_open_cache_instances=16 temptable_max_ram=2G tmp_table_size=512M max_heap_table_size=512M internal_tmp_mem_storage_engine=TempTable # InnoDB优化 innodb_buffer_pool_size=40G innodb_log_file_size=2G innodb_buffer_pool_instances=16 innodb_log_buffer_size=256M innodb_redo_log_capacity=4G innodb_flush_log_at_trx_commit=2 innodb_autoinc_lock_mode=2 bulk_insert_buffer_size=256M innodb_doublewrite=ON innodb_io_capacity=8000 innodb_io_capacity_max=16000 innodb_use_native_aio=ON innodb_flush_method=normal # 线程优化 innodb_thread_concurrency=0 innodb_parallel_read_threads=10 innodb_read_io_threads=10 innodb_write_io_threads=10 thread_cache_size=50 innodb_purge_threads=4 # 连接与网络 max_allowed_packet=256M net_buffer_length=32K max_connect_errors=1000 wait_timeout=300 interactive_timeout=300 # 文件与缓存 open_files_limit=10000 innodb_open_files=5000 innodb_file_per_table=ON innodb_autoextend_increment=128 # 查询优化 join_buffer_size=4M sort_buffer_size=4M read_buffer_size=1M read_rnd_buffer_size=1M # 性能与安全 performance_schema=ON innodb_checksum_algorithm=0 innodb_old_blocks_time=1000 innodb_stats_on_metadata=0 flush_time=0 # 复制相关 binlog_row_event_max_size=8K sync_source_info=10000 sync_relay_log=10000 # MySQL X Protocol loose_mysqlx_port=33060 这是我目前的my.ini的配置，我电脑是WIN10的操作系统，MYSQL版本是8.2，CPU是10核20线程的E5 2666V3，运存是4通道共64G服务器DD3内存，硬盘是SATA协议的1T SSD