<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[cug_jiang126com的专栏]]></title><description><![CDATA[]]></description><link>https://blog.youkuaiyun.com/cug_jiang126com</link><language>zh-cn</language><generator>https://blog.youkuaiyun.com/</generator><copyright><![CDATA[Copyright &copy; cug_jiang126com]]></copyright><item><title><![CDATA[Server has authorization schema version 3,but found a schema version 1 user]]></title><link>https://blog.youkuaiyun.com/cug_jiang126com/article/details/80354377</link><guid>https://blog.youkuaiyun.com/cug_jiang126com/article/details/80354377</guid><author>cug_jiang126com</author><pubDate>Thu, 17 May 2018 17:41:39 +0800</pubDate><description><![CDATA[]]></description><category></category></item><item><title><![CDATA[xtrbackup限速测试]]></title><link>https://blog.youkuaiyun.com/cug_jiang126com/article/details/80353171</link><guid>https://blog.youkuaiyun.com/cug_jiang126com/article/details/80353171</guid><author>cug_jiang126com</author><pubDate>Thu, 17 May 2018 16:43:22 +0800</pubDate><description><![CDATA[]]></description><category></category></item><item><title><![CDATA[Gone away故障原因排查]]></title><link>https://blog.youkuaiyun.com/cug_jiang126com/article/details/80192418</link><guid>https://blog.youkuaiyun.com/cug_jiang126com/article/details/80192418</guid><author>cug_jiang126com</author><pubDate>Fri, 04 May 2018 11:17:20 +0800</pubDate><description><![CDATA[]]></description><category></category></item><item><title><![CDATA[xtrabackup对于flush tables with read lock操作的设置]]></title><link>https://blog.youkuaiyun.com/cug_jiang126com/article/details/79489962</link><guid>https://blog.youkuaiyun.com/cug_jiang126com/article/details/79489962</guid><author>cug_jiang126com</author><pubDate>Thu, 08 Mar 2018 21:29:28 +0800</pubDate><description><![CDATA[参数说明版本  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...]]></description><category></category></item><item><title><![CDATA[mysql统计信息收集设置]]></title><link>https://blog.youkuaiyun.com/cug_jiang126com/article/details/79290575</link><guid>https://blog.youkuaiyun.com/cug_jiang126com/article/details/79290575</guid><author>cug_jiang126com</author><pubDate>Thu, 08 Feb 2018 15:51:51 +0800</pubDate><description><![CDATA[innodb_stats_persistent决定两种收集方式默认为on，指定InnoDB索引统计信息是否保存到磁盘。如果为off，那么在服务器重启或者一些其他操作时会清空之前的统计信息，其实就是清空mysql.innodb_table_stats和mysql.innodb_index_stats表数据。当下一次表访问时再次重新计算，这可能会导致查询执行计划发生变化。可以在创建表之前在全局级别设置...]]></description><category></category></item><item><title><![CDATA[mongos数据分布不均匀，move chunk失败]]></title><link>https://blog.youkuaiyun.com/cug_jiang126com/article/details/79283263</link><guid>https://blog.youkuaiyun.com/cug_jiang126com/article/details/79283263</guid><author>cug_jiang126com</author><pubDate>Wed, 07 Feb 2018 18:41:48 +0800</pubDate><description><![CDATA[现象
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,]]></description><category></category></item><item><title><![CDATA[跨版本导入数据导致mysqld崩溃]]></title><link>https://blog.youkuaiyun.com/cug_jiang126com/article/details/79193682</link><guid>https://blog.youkuaiyun.com/cug_jiang126com/article/details/79193682</guid><author>cug_jiang126com</author><pubDate>Mon, 29 Jan 2018 11:56:31 +0800</pubDate><description><![CDATA[现象
mysqld突然崩溃，错误日志
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 7f]]></description><category></category></item><item><title><![CDATA[mongo3.0.9库命名的一个S级bug]]></title><link>https://blog.youkuaiyun.com/cug_jiang126com/article/details/79078947</link><guid>https://blog.youkuaiyun.com/cug_jiang126com/article/details/79078947</guid><author>cug_jiang126com</author><pubDate>Tue, 16 Jan 2018 20:55:37 +0800</pubDate><description><![CDATA[现象
db每隔一段时间崩溃一次，完全停服的情况下不会崩溃，mongod日志如下
2018-01-16T20:21:43.573+0800 E STORAGE  [conn18] no cursor for uri: table:asd()/collection-15-2895040321638166665
2018-01-16T20:21:43.573+0800 I -        [co]]></description><category></category></item><item><title><![CDATA[大量短连接导致haproxy服务器端口耗尽]]></title><link>https://blog.youkuaiyun.com/cug_jiang126com/article/details/79012979</link><guid>https://blog.youkuaiyun.com/cug_jiang126com/article/details/79012979</guid><author>cug_jiang126com</author><pubDate>Tue, 09 Jan 2018 15:38:18 +0800</pubDate><description><![CDATA[现象
现象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]]></description><category></category></item><item><title><![CDATA[故障处理--mongos count不准]]></title><link>https://blog.youkuaiyun.com/cug_jiang126com/article/details/78902622</link><guid>https://blog.youkuaiyun.com/cug_jiang126com/article/details/78902622</guid><author>cug_jiang126com</author><pubDate>Tue, 26 Dec 2017 15:19:01 +0800</pubDate><description><![CDATA[故障现象
业务上并无对这个表的delete操作，通过mongostat可以查看。但是mongos对一个表进行count操作时，发现它的计数结果会慢慢变少，然后突然有一个大幅增长，随后又逐渐减少，现象如下
mongos> db.ebay_us_detail.count()
154462481
mongos> db.ebay_us_detail.count()
154462463
mong]]></description><category></category></item><item><title><![CDATA[mysql唯一索引的一个小常识--Duplicate entry 'XXX' for key 'XXX']]></title><link>https://blog.youkuaiyun.com/cug_jiang126com/article/details/78500102</link><guid>https://blog.youkuaiyun.com/cug_jiang126com/article/details/78500102</guid><author>cug_jiang126com</author><pubDate>Fri, 10 Nov 2017 15:36:42 +0800</pubDate><description><![CDATA[概述
之前一直有个小误区，我以为mysql的唯一索引肯定是区分大小写的，然而实际上utf8字符集下，默认排序规则utf8_general_ci 情况下，是不区分大小写的。而在排序规则utf8_bin下是区分大小写的，这就有可能出现以下情况：之前字段是varchar 
 binary类型，即排序规则为utf8_bin，后来将该字段改回varchar的话，就会导致唯一键冲突错误


测试
]]></description><category></category></item><item><title><![CDATA[利用mongosync做数据库迁移]]></title><link>https://blog.youkuaiyun.com/cug_jiang126com/article/details/78104938</link><guid>https://blog.youkuaiyun.com/cug_jiang126com/article/details/78104938</guid><author>cug_jiang126com</author><pubDate>Tue, 26 Sep 2017 17:43:13 +0800</pubDate><description><![CDATA[背景
有些情况下，官方推荐的迁移方法不是那么便捷，比如mongos集群的整体迁移步骤非常繁琐，且对网络的要求很高；
mongosync支持mongos集群迁移，目前支持3.0及以下版本，特别适合mongodb跨机房的迁移
目前有这么一个需求
机房A有一套mongos集群，需要迁移到机房B，A和B之间的mongo实例网络不通，但是在其中一个中转服务器上能够分别ping通A机房和B机房的mon]]></description><category></category></item><item><title><![CDATA[gtid主从报错When@@SESSION.GTID_NEXT is set to a GTID]]></title><link>https://blog.youkuaiyun.com/cug_jiang126com/article/details/77371559</link><guid>https://blog.youkuaiyun.com/cug_jiang126com/article/details/77371559</guid><author>cug_jiang126com</author><pubDate>Fri, 18 Aug 2017 17:18:12 +0800</pubDate><description><![CDATA[故障现象
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]]></description><category></category></item><item><title><![CDATA[mongos分片集群下db数量过多导致服务不可用]]></title><link>https://blog.youkuaiyun.com/cug_jiang126com/article/details/77073705</link><guid>https://blog.youkuaiyun.com/cug_jiang126com/article/details/77073705</guid><author>cug_jiang126com</author><pubDate>Thu, 10 Aug 2017 22:05:30 +0800</pubDate><description><![CDATA[故障现象
每隔一段时间发现mongos连不上，mongos日志出现大量的socket连接错误
2017-08-08T17:09:31.095+0800 I SHARDING [conn52677] couldn't find database [d4ee211b4024a2d9e6bd57d4a28679339d6b0692] in config db
2017-08-08T17:09:33]]></description><category></category></item><item><title><![CDATA[利用binlog2sql实现闪回]]></title><link>https://blog.youkuaiyun.com/cug_jiang126com/article/details/76854699</link><guid>https://blog.youkuaiyun.com/cug_jiang126com/article/details/76854699</guid><author>cug_jiang126com</author><pubDate>Mon, 07 Aug 2017 17:53:09 +0800</pubDate><description><![CDATA[转载来自 https://github.com/danfengcao/binlog2sql/blob/master/example/mysql-flashback-priciple-and-practice.md


MySQL闪回原理与实战


DBA或开发人员，有时会误删或者误更新数据，如果是线上环境并且影响较大，就需要能快速回滚。传统恢复方法是利用备份重搭实例，再应用去除错误sq]]></description><category></category></item><item><title><![CDATA[双主+haproxy手工切换的一个注意点]]></title><link>https://blog.youkuaiyun.com/cug_jiang126com/article/details/74530304</link><guid>https://blog.youkuaiyun.com/cug_jiang126com/article/details/74530304</guid><author>cug_jiang126com</author><pubDate>Thu, 06 Jul 2017 11:23:39 +0800</pubDate><description><![CDATA[之前设计的切换逻辑
1 查询slve的延迟情况，超过N秒延迟则等待或者返回失败，确保业务影响时间最短
2 登陆proxy节点，disable当前hproxy，使得后续通过proxy的业务连接失败
3 登陆proxy节点，shutdown当前通过proxy连接的会话（如果sql能快速完成，这步其实可用不做，可以做个时间阈值检测，当N秒以后还有业务层连接则kill）
4 记录当前主库的binl]]></description><category></category></item><item><title><![CDATA[sql_log_bin在GTID复制下的一个现象]]></title><link>https://blog.youkuaiyun.com/cug_jiang126com/article/details/74332749</link><guid>https://blog.youkuaiyun.com/cug_jiang126com/article/details/74332749</guid><author>cug_jiang126com</author><pubDate>Tue, 04 Jul 2017 17:48:53 +0800</pubDate><description><![CDATA[背景
现网环境是M-M GTID+haproxy+组成的高可用需要做一个基于时间点的回档
之前的方法：
1 新建出另外一组M-M GTID高可用集群。我们将新的集群成为B，旧的集群称为A
2  分别导入A的历史备份到B集群的两个实例上，分开导入，导入期间双主同步不关，但会关闭sql_log_bin
3 分别导入A的增量binlog到B集群的两个实例上，分开导入，导入期间双主同步不关，但会]]></description><category></category></item><item><title><![CDATA[故障案例---innodb表出现大量的Waiting for table level lock]]></title><link>https://blog.youkuaiyun.com/cug_jiang126com/article/details/73549960</link><guid>https://blog.youkuaiyun.com/cug_jiang126com/article/details/73549960</guid><author>cug_jiang126com</author><pubDate>Wed, 21 Jun 2017 16:23:20 +0800</pubDate><description><![CDATA[故障现象
show  full processlist发现大量的innodb表出现Waiting for table level lock，业务将近不可用
原因分析
1 一开始当然是认为这是myisam引擎导致的，扫了一圈发现该db下确实有一个myisam表；
2 不过故障时无论是show  processlist还是innodb_trx等结果看，都没有发现这个myisam表的记录；
3]]></description><category></category></item><item><title><![CDATA[ProxySQL快速上手]]></title><link>https://blog.youkuaiyun.com/cug_jiang126com/article/details/73167912</link><guid>https://blog.youkuaiyun.com/cug_jiang126com/article/details/73167912</guid><author>cug_jiang126com</author><pubDate>Tue, 13 Jun 2017 11:59:23 +0800</pubDate><description><![CDATA[安装并登陆管理界面
1 wgethttps://github.com/sysown/proxysql/releases/download/v1.3.6/proxysql-1.3.6-1-centos67.x86_64.rpm
2 yum install perl-DBD-MySQL
3 rpm -ivh proxysql-1.3.6-1-centos67.x86_64.rpm 
4 ser]]></description><category></category></item><item><title><![CDATA[warning: ClientCursor::staticYield can't unlock b/c of recursive lock ns:]]></title><link>https://blog.youkuaiyun.com/cug_jiang126com/article/details/73135648</link><guid>https://blog.youkuaiyun.com/cug_jiang126com/article/details/73135648</guid><author>cug_jiang126com</author><pubDate>Mon, 12 Jun 2017 19:55:26 +0800</pubDate><description><![CDATA[故障现象
大量的日志刷屏warning: ClientCursor::staticYield can't unlock b/c of recursive lock ns: 
日志级别已经是quiet
大概每小时就写十几G，分分钟磁盘要被刷爆
mongo版本：2.6


故障原因
没去深究


处理方法
对应的查询没有索引，加上索引以后就没有类似的warning信息了]]></description><category></category></item></channel></rss>