最近在我们线上库物理备份的时候出现一个奇怪的现象:    我们备份都在从库上备份的,在业务低一般是在晚上2点钟开始备份.有天发现从库的延迟一直在增加,登录上实例,通过show processlist 发现,sql 线程在等待 binlog lock.同时看到我们从2点钟开始的压缩远程备份并没有完成,备份日志还在扫面ibd文件.    那么这个binlog lock 是谁持有的呢?仔细想想我们的业务场景,这是一个只读从库,且库上便没有提供任何读的服务,唯一的一个疑点就是我们的备份导致的,通过…

背景: 对于MySQL的binlog的查看都是用其自带的工具mysqlbinlog进行操作的,其实还有另一个方法来操作binlog,就是Replication中的SQL线程去操作binlog,其实binlog和relaylog的格式是一样的.下面开始介绍如何用该方法进行对binlog的操作. 测试1: ---初始化: root : aaa ::>reset master; Query OK, rows affected (0.12 sec) root : aaa ::>reset slave;…

背景: 对于MySQL的binlog的查看都是用其自带的工具mysqlbinlog进行操作的,其实还有另一个方法来操作binlog,就是Replication中的SQL线程去操作binlog,其实binlog和relaylog的格式是一样的.下面开始介绍如何用该方法进行对binlog的操作. 测试1: ---初始化: root@192.168.200.25 : aaa 03:51:38>reset master; Query OK, 0 rows affected (0.12 sec) root…

背景: 主从环境一样,字符集是utf8. Slave复制报错,平时复制都正常也没有出现过问题,今天突然报错: :: :: :: :: Error_code: :: perror 1366 MySQL error code (ER_TRUNCATED_WRONG_VALUE_FOR_FIELD): Incorrect %-.32s value: '%-.128s' for column '%.192s' at row %ld 从上面2个信息得到从库复制失败的原因是因为字符集的问题引起的. 分析:…

mysql  Bug#19843808 自动修复记录 MySQL5.6和Xtrabackup之间存在一个bug,这个bug在5.6.23中已经修复. Xtrabackup备份的时候执行flushs tables with read lock和show slave status会有可能和SQL Thread形成死锁,导致SQL Thread一直被卡主,STOP也没有用,Kill我们测试会丢失数据,只有Restart Server才行. 原因是SQL Thread的DML操作完成之后,持有rli->…

故障现象: 进入slave服务器,运行: mysql> show slave status\G ....... Relay_Log_File: localhost Relay_Log_Pos: Relay_Master_Log_File: localhost Slave_IO_Running: Yes Slave_SQL_Running: No Replicate_Do_DB: Replicate_Ignore_DB: ...... 解决办法一. Slave_SQL_Running: No1.程…

Java 5 之后,Java在内置关键字sychronized的基础上又增加了一个新的处理锁的方式,Lock类. 由于在Java线程间通信:volatile与sychronized中,我们已经详细的了解了synchronized,所以我们现在主要介绍一下Lock,以及将Lock与synchronized进行一下对比. 1. synchronized的缺陷 2. Lock类接口设计 3. ReentrantLock可重入锁 3.1. ReentrantLock概述 3.2. ReentrantLo…

[问题] 假设有这种场景,误操作DROP DB或TABLE,常规的恢复操作是还原全备份,并用mysqlbinlog追加到drop操作前的位置. 如果需要恢复的binlog的日志量比较大而我们只希望恢复某个DB或某张表,常规操作会花费较长的时间. 在网上看到了借助SQL Thread来应用binlog的方法,做测试验证是可行的. [原理] 1.Binlog是MySQL Server产⽣的,记录数据库的逻辑变化 2.Relay-log 是Master/Slave结构中Slave的IO_thread从…

mysql基于binlog主从复制架构,IO.SQL线程运行为YES,从库没有同步数据 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: ht,ht_prod 解决问题: replicate-do-db = ht,ht_prod 修改为:replicate-do-db = ht replicate-do-db = ht_prod…

问题 在Ubuntu中,执行apt install后,出现以下问题: Waiting for cache lock: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 3365 (unattended-upgr) 看着描述就是有3365的进程进行占用了source文件. 解决办法: 删除锁定的文件 rm /var/lib/dpkg/lock 实在没办法解除,直接进行干掉进程. kill -9 3365 注意…