cug_jiang126com的专栏

原创 Server has authorization schema version 3,but found a schema version 1 user

原创 xtrbackup限速测试

原创 Gone away故障原因排查

原创 xtrabackup对于flush tables with read lock操作的设置

参数说明版本  percona-xtrabackup-2.4.8-Linux-x86_64 --kill-long-queries-timeout=N  指的是执行flush tables with read lock以后，如果flush操作被卡了N秒，则杀掉卡住它的线程，默认0的情况就是不杀死任何卡住flush的sql，直到该sql执行完成--kill-long-query-type=all|s...

原创 mysql统计信息收集设置

innodb_stats_persistent决定两种收集方式默认为on，指定InnoDB索引统计信息是否保存到磁盘。如果为off，那么在服务器重启或者一些其他操作时会清空之前的统计信息，其实就是清空mysql.innodb_table_stats和mysql.innodb_index_stats表数据。当下一次表访问时再次重新计算，这可能会导致查询执行计划发生变化。可以在创建表之前在全局级别设置...

原创 mongos数据分布不均匀，move chunk失败

现象2018-02-06T14:41:05.130+0800 I SHARDING [Balancer] moveChunk result: { cause: { ok: 0.0, errmsg: "can't accept new chunks because  there are still 1236 deletes from previous migration" }, ok: 0.0,

原创 跨版本导入数据导致mysqld崩溃

现象mysqld突然崩溃，错误日志Attempting backtrace. You can use the following information to find outwhere mysqld died. If you see no messages after this, something wentterribly wrong...stack_bottom = 7f

原创 mongo3.0.9库命名的一个S级bug

现象db每隔一段时间崩溃一次，完全停服的情况下不会崩溃，mongod日志如下2018-01-16T20:21:43.573+0800 E STORAGE  [conn18] no cursor for uri: table:asd()/collection-15-28950403216381666652018-01-16T20:21:43.573+0800 I -        [co

原创 大量短连接导致haproxy服务器端口耗尽

现象现象1：在haproxy中间件层查看netstat会有大量的time_wait，大概有几万个以上现象2：查看haproxy日志会有部分显示端口耗尽Jan  9 14:59:04 127.0.0.1 haproxy[37]: Connect() failed for backend ha-proxy: no free ports.Jan  9 14:59:04 127.0

原创 故障处理--mongos count不准

故障现象业务上并无对这个表的delete操作，通过mongostat可以查看。但是mongos对一个表进行count操作时，发现它的计数结果会慢慢变少，然后突然有一个大幅增长，随后又逐渐减少，现象如下mongos> db.ebay_us_detail.count()154462481mongos> db.ebay_us_detail.count()154462463mong

原创 mysql唯一索引的一个小常识--Duplicate entry 'XXX' for key 'XXX'

概述之前一直有个小误区，我以为mysql的唯一索引肯定是区分大小写的，然而实际上utf8字符集下，默认排序规则utf8_general_ci 情况下，是不区分大小写的。而在排序规则utf8_bin下是区分大小写的，这就有可能出现以下情况：之前字段是varchar  binary类型，即排序规则为utf8_bin，后来将该字段改回varchar的话，就会导致唯一键冲突错误测试

原创 利用mongosync做数据库迁移

背景有些情况下，官方推荐的迁移方法不是那么便捷，比如mongos集群的整体迁移步骤非常繁琐，且对网络的要求很高；mongosync支持mongos集群迁移，目前支持3.0及以下版本，特别适合mongodb跨机房的迁移目前有这么一个需求机房A有一套mongos集群，需要迁移到机房B，A和B之间的mongo实例网络不通，但是在其中一个中转服务器上能够分别ping通A机房和B机房的mon

原创 gtid主从报错When@@SESSION.GTID_NEXT is set to a GTID

故障现象gtid主从报错信息When@@SESSION.GTID_NEXT is set to a GTID, you must explicitly set it to a differentvalue after a COMMIT or ROLLBACK. Please check GTID_NEXT variable manual pagefor detailed explana

原创 mongos分片集群下db数量过多导致服务不可用

故障现象每隔一段时间发现mongos连不上，mongos日志出现大量的socket连接错误2017-08-08T17:09:31.095+0800 I SHARDING [conn52677] couldn't find database [d4ee211b4024a2d9e6bd57d4a28679339d6b0692] in config db2017-08-08T17:09:33

转载 利用binlog2sql实现闪回

转载来自 https://github.com/danfengcao/binlog2sql/blob/master/example/mysql-flashback-priciple-and-practice.mdMySQL闪回原理与实战DBA或开发人员，有时会误删或者误更新数据，如果是线上环境并且影响较大，就需要能快速回滚。传统恢复方法是利用备份重搭实例，再应用去除错误sq

原创 双主+haproxy手工切换的一个注意点

之前设计的切换逻辑1 查询slve的延迟情况，超过N秒延迟则等待或者返回失败，确保业务影响时间最短2 登陆proxy节点，disable当前hproxy，使得后续通过proxy的业务连接失败3 登陆proxy节点，shutdown当前通过proxy连接的会话（如果sql能快速完成，这步其实可用不做，可以做个时间阈值检测，当N秒以后还有业务层连接则kill）4 记录当前主库的binl

原创 sql_log_bin在GTID复制下的一个现象

背景现网环境是M-M GTID+haproxy+组成的高可用需要做一个基于时间点的回档之前的方法：1 新建出另外一组M-M GTID高可用集群。我们将新的集群成为B，旧的集群称为A2  分别导入A的历史备份到B集群的两个实例上，分开导入，导入期间双主同步不关，但会关闭sql_log_bin3 分别导入A的增量binlog到B集群的两个实例上，分开导入，导入期间双主同步不关，但会

原创 故障案例---innodb表出现大量的Waiting for table level lock

故障现象show  full processlist发现大量的innodb表出现Waiting for table level lock，业务将近不可用原因分析1 一开始当然是认为这是myisam引擎导致的，扫了一圈发现该db下确实有一个myisam表；2 不过故障时无论是show  processlist还是innodb_trx等结果看，都没有发现这个myisam表的记录；3

原创 ProxySQL快速上手

安装并登陆管理界面1 wgethttps://github.com/sysown/proxysql/releases/download/v1.3.6/proxysql-1.3.6-1-centos67.x86_64.rpm2 yum install perl-DBD-MySQL3 rpm -ivh proxysql-1.3.6-1-centos67.x86_64.rpm 4 ser

原创 warning: ClientCursor::staticYield can't unlock b/c of recursive lock ns:

故障现象大量的日志刷屏warning: ClientCursor::staticYield can't unlock b/c of recursive lock ns: 日志级别已经是quiet大概每小时就写十几G，分分钟磁盘要被刷爆mongo版本：2.6故障原因没去深究处理方法对应的查询没有索引，加上索引以后就没有类似的warning信息了

翻译 proxysql的配置系统

proxysql的配置系统特点1 允许轻松自动更新配置。为此，有一个MySQL兼容的管理界面2 允许在运行时修改尽可能多的配置项，而无需重新启动守护程序3 允许轻松回滚错误的配置这是使用多层配置系统实现的，允许设置从一层移动到另一层。配置系统的3层如下图所示：+-------------------------+|         RUNTIME         |

原创 故障案例--mongo 3.0鉴权导致cpu居高不下

故障现象CPU奇高，达到接近物理机核数上限；错误日志中的业务SQL执行较快，SQL不存在问题；错误日志大量的刷屏以下信息原因分析从错误日志看，绝大部分情况都处于saslStart，查看资料发现这是mongo 3.0的鉴权机制正是SCRAM-SHA-1，于是怀疑是这个鉴权机制导致了CPU飙升；通过了解，业务采用的是短连接，进一步确定原因应该是短时间大量的连接过来触发的

原创 mongos分片集群版本升级方案

总体思路Mongos整个分片集群版本升级时，先确定升级mongos和config server，因为经过测试，假如先升级sharding节点的话，会导致mongos查询不可用，存在版本兼容性问题，报错截图如下另一方面，如果先升级mongos和config server节点的话，就不存在兼容性问题，3.0的mongos和config server能够正常读取低版本的shardin

原创 故障案例--mongo备份文件损坏，导致mongorestore中断

故障现象备份显示成功，不过有次准备用这个备份恢复数据库时，mongorestore却失败了，报错如下 2017-05-11T23:52:48.050+0800  Progress: 348374754/1256078901 27% (bytes)INVALID OBJECT - going to try and print out size: 377error: bson 

原创 故障案例--mongodb writeconcern为majority时的又一个bug

前言之前的文章有提到过majority的一个坑，还谈不上bug，链接如下点击打开链接故障现象majority下应用层一直报错，但实际数据写入成功，包括主从节点都成功；w设置为1以后没有报错，写入成功 044dd16e-7706-4a49-b4ff-73d86a99d6fd:PRIMARY> db.setWriteConcern({w:"majority",wtimeout:30

原创 故障案例--寻找瓶颈SQL的一种方法

故障现象DB响应非常慢，连接数暴涨直到打满；任何SQL看起来都是慢查询，都要几十秒以上；show  processlist时SQL种类非常多，短时间无法分辨哪个是引起故障的SQL，挑了几个看SQL问题不大；CPU,IO都非常低，看样子无系统瓶颈，也无任何硬件层面的报错；故障原因和定位方法猜测是高并发引起的性能瓶颈，通过show engine innodb status\G结

原创 故障案例--通过create server创建federate引擎导致主从失败

故障现象主从同步失败，报错如下Error 'Unknown storage engine 'FEDERATED'' on query. Default database: 'test'. Query: 'create table test_federated(`id` int(20) NOT NULL AUTO_INCREMENT,   `name` varchar(32) NOT NUL

原创 主从同步失败---Illegal mix of collations

故障现象：主从同步报错，Error 'Illegal mix of collations (utf8mb4_unicode_ci,COERCIBLE), (latin1_swedish_ci,IMPLICIT), (utf8mb4_unicode_ci,COERCIBLE) for operation 'concat'' on query. Default database: 'hhrchin

原创 config server高可用的怀疑(非副本集模式)

SCCC和CRCS的区别在mongo3.4版本之前，configsvr的高可用有两种方式，一种是SCCC，即非副本集模式，一种是CSRS(副本集模式)。在mongo3.4以后已经不支持SCCC了，就我使用SCCC模式的经验看，SCCC确实太坑。个人认为，CSRS相对SCCC大概有以下优点1 节点宕机后SCCC模式只读不可写，这时mongos无法负载均衡。而CSRS存在副本集的高可用，宕机一

转载 mongos删除库表的一个bug

ISSUE SUMMARYWhen dropping a database / collection in a sharded cluster, even if the drop is reported as successful it is possible the database / collection may still be present in some nodes in the

原创 从最近的mysql故障谈海量数据库的备份系统设计

前言最近炉石传说，gitlab数据库故障在业界传得沸沸扬扬，造成了无法挽回的数据丢失。对于越是大规模的数据库系统, 如何设计一个可靠的备份系统越是至关重要。本文主要以UCloud云数据库产品UDB的备份系统为例，阐述下在海量数据库情况下，备份系统该如何设计，如何确保备份的安全性，如何避免数据库从删库到跑路的窘境。大型备份系统设计大型备份系统设计考虑因素如果一个DBA只需要维

翻译 组复制官方文档翻译(依赖和限制)

Group Replication Requirements要用于组复制的服务器实例必须满足以下要求。基础设施InnoDB Storage Engine. 数据必须存储在InnoDB事务存储引擎中。事务以乐观的方式执行，然后在提交时检查冲突。如果存在冲突，为了保持整个组的一致性，某些事务将回滚。这意味着需要事务存储引擎。此外，InnoDB提供了一些额外的功能，当与组复制一起操作时，

翻译 组复制官方文档翻译(安全性)

IP地址白名单组复制插件具有一个配置选项，用于确定从哪些主机可以接受传入的组通信连接。此选项称为group_replication_ip_whitelist。如果在服务器s1上设置此选项，则当服务器s2正在建立与s1的连接以便进行组通信时，s1在接受s2传过来的连接之前，首先会检查白名单。如果s2在白名单中，则s1接受连接，否则s1拒绝s2的连接尝试。如果未配置任何白名单，则服务器会自

翻译 组复制官方文档翻译(group replication operations)

Deploying in Multi-Primary or Single-Primary Mode组复制可以在以下不同模式下运行：single-primary 模式multi-primary 模式默认模式为单主。不可能让组的成员部署在不同的模式，例如一个配置在多主模式，而另一个在单主模式。要在模式之间切换，需要使用不同的配置并重新启动组而不单个成员。无论部署模式如何，组复制不处理客

原创 mongodb启动很慢

故障现象mongodb重启后，等了几十分钟还一直没启动完成，单节点副本集，状态一直处于startup原因分析查看mongod的错误日志，发现一直处于building index，但根据之前的经验，只有在重做secondary节点的时候才会经常处于building index状态，而这个db是primary节点，于是详细查看了关于这个building index的全部信息 201

原创 5.6mysqldump gtid的一个小坑

故障现象Master-slave+GTID架构下，从master导入5.6的备份，发现数据没有同步到从库，通过查看备份文件内容，发现sql_log_bin被设置为0从而在导入时禁用了binlog引起。/*!40101 SET@OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;/*!40111 SET@OLD_SQL

翻译 组复制官方文档翻译(组复制监控)

Monitoring Group Replication如果mysql编译了performance_schema，那么可以使用Perfomance schema表监视组复制。组复制添加以下两个新的P_S表：• performance_schema.replication_group_member_stats• performance_schema.replication_group_m

翻译 组复制官方文档翻译(Getting Started)

Deploying Group Replication in Single-Primary Mode组中的每个服务器实例可以在独立的物理机器上运行，也可以在同一台机器上运行。本节介绍如何在一台物理机上创建具有三个MySQL Server实例的复制组。这意味着需要三个数据目录，每个MySQL Server实例占用一个，您需要独立配置每个实例。本教程介绍如何使用组复制插件获取和部署MySQL

原创 故障案例：高可用切换后数据不一致，旧主库数据丢失

故障现象：有台物理机宕机，复制架构是master-master+半同步，期间触发了高可用容灾切换，后台显示成功切换到了备库。但是等旧主库起来后，主从状态正常，但是旧主库上却丢失了一部分数据，通过对比发现这些数据都是在宕机瞬间的写操作原因分析：1 假设旧主库A丢失的数据记录为X，我们去A上解析发现宕机那段时间并无X记录的binlog信息，可确定在宕机瞬间该记录X没有binlog落盘；

翻译 组复制官方文档翻译（组复制原理）

Group Replication Background（组复制技术原理）创建容错系统的最常见方法是使组件冗余，换句话说，部分组件可以删除，系统应该继续按预期运行。这产生了一系列挑战，将这种系统的复杂性提高到一个完全不同的水平。具体来说，复制的数据库必须处理这样的情况，即它们需要维护和管理几个服务器而不是一个。此外，由于多个服务器组成了一个“组”的概念来相互协同工作，必须处理几个其他经典分布式