最近洪荒之力火了，我觉得此生能让DBA使出洪荒之力的也就是回档了。要虐哭一个游戏DBA，其实蛮简单的，让他回一次档，如果不行，就回二次。毕竟回档这事儿是件擦屁股的活，你想呀，游戏bug，开发；道具发错，产品；版本部署，业务运维；没一个省心的，感觉身体都要被掏空了。但作为DBA如果不回一两次档那跟咸鱼有啥区别呢？​怨念了一大段的回档，光说不练假把式。听，天空一声巨响，某MMOG游戏就闪亮登场了。整个回档时间从 2016-07-19 09:40:19 开始，在2016-07-19 23:54:30结束，整个过程持续近 14 个小时，其中从远程备份系统拉取数据，占了几乎全部时间。聪明如你或许已经想到一个问题，停机时间这么长？玩家不投诉吗？你猜对了，玩家是上帝，不供着不行滴，我们在回档前了解到受影响到模块和排行榜相关，如果关闭并不影响整个游戏可玩性，所以在回档前已经协调产品发布公告，将此模块关闭：万万没想到，一个礼拜后又双叒叕回档。要是你同学朋友中有做游戏DBA的，那请他们吃个饭吧，反正他们也去不了。当你感到憋屈，则是复盘的时候。因为在结果导向的文化下，没有增值的辛苦，都是假辛苦。宝宝心里苦，但宝宝不说。元芳，此事你怎么看？大人，我用RTX看。深入浅出了RTX回档群，致电RD沟通，发现每次回档都涉及到排行榜模块，并且都是同一张表，该表不需要binlog做增量恢 ...继续阅读 (6)

我认为工作的核心就是闭环，如果想做优秀员工，必须完成闭环。在过去的一年里，我慢慢学会了团队的一个习惯，那便是，这件事情的闭环标准是什么？也许，老板有老板的标准，但不管何时，在交付前他通常不知道自己想要什么，除非你给他需要的东西。从这个角度讲，不管遇到什么事情，都应该扪心自问：“怎样才算做好？”，如果能把任务分而治之，那么确定“做好”的标准或许清晰些，因为每个子任务的闭环标准可能已经自然存在，起码有这么一条：“如果这个做不好，那么下一个就没法开始……”那么，什么是闭环？我举个例子：2015-12-25日协同开发参与优化QT语音下属的掌盟俱乐部话题业务计数，在优化前业务侧是通过SQL实现俱乐部话题业务数的统计，方式如下：yw@Tencent64[db_circle]mysql> select count(1) from t_circle_topic_74 force index(idx_app_circle_id) where app_id=1 and circle_id='13'; +----------+ | count(1) | +----------+ | 1403174 | +----------+ 1 row in set (4.11 sec)这种方式响应时间为4秒，较搓，产品不能忍。优化手段是通过新建一张计数表 t_circle_topic_total ，含app ...继续阅读 (12)

你会数数吗？很多人对这个问题大概是嗤之以鼻吧，因为小时候爸爸妈妈就教我们数天上的星星，地上的羊。因此大部分人第一反应我想应该是：“你在逗我吗？”也正是因为这种如此小儿科的简单到我们不愿意青眼相加的事情，让我们在日常的变更支持中屡屡将自己落入尴尬的状态，给玩家的体验、公司的利益、团队的影响带来负面的评价。DBA在跑完一个变更脚本后，便是检查日志，查看变更过程的详情，最经常使用的也就是grep -Ei error.log，更有甚者，Oracle DBA转MySQL的可能还会有grep -Ei ora 这种惊人举动。那warnings呢？真的可以做到置之不理吗？我们在天涯明月刀落地TokuDB大概1-2个月后，某天业务运维反馈现网版本加字段时间很长，这和TokuDB支持在线加字段相悖，线下通过测试重演，发现MySQL 5.6用了新的时间类型，如果低版本含有时间字段，并且通过原地升级上来的，则无法使用TokuDB原生的在线加字段。对这个结果的发现，我们则是通过warnings日志，而实际上每次的DB版本变更也都是有这个warnings，只是我们“视而不见”。所以，在这里我想提一个观点，便是任何变更我们都要数对的，而不是数错的。那么我们如何才能做到数对的呢？也就是我们应该怎么数才能数对？一方面，数内容。有个例子，12.24 号幻想世界22号大区DB切换后玩家数据回档，22号大区已经从26迁移 ...继续阅读 (23)

你会数数吗？很多人对这个问题大概是嗤之以鼻吧，因为小时候爸爸妈妈就教我们数天上的星星，地上的羊。因此大部分人第一反应我想应该是：“你在逗我吗？”也正是因为这种如此小儿科的简单到我们不愿意青眼相加的事情，让我们在日常的变更支持中屡屡将自己落入尴尬的状态，给玩家的体验、公司的利益、团队的影响带来负面的评价。DBA在跑完一个变更脚本后，便是检查日志，查看变更过程的详情，最经常使用的也就是grep -Ei ...继续阅读 (9)

天堂等于天下？是的，你的眼睛没有花~，看下面例子mysql> create table t (a varchar(12) default null,b varchar(12) default null, unique key idx_a (a),unique key idx_b (b)) engine=innodb default charset=latin1; Query OK, 0 rows affected (0.00 sec) mysql> mysql> insert into t values ("天堂",1); Query OK, 1 row affected (0.00 sec) mysql> mysql> insert into t values ("天下",1); ERROR 1062 (23000): Duplicate entry '天下' for key 'idx_a' mysql>这是由于'天堂'和'天下'gbk编码在latin1_swedish_ci排序集下是相等的。'天堂' --- CCECCCC3'天下' --- CCECCFC2线上的业务修改方法，建议如下：mysql> alter table t change a a varchar(20) CHARACTER SET latin1 collate latin1_bin; Que ...继续阅读 (26)

天堂等于天下？是的，你的眼睛没有花~，看下面例子mysql> create table t (a varchar(12) default null,b varchar(12) default null, unique key idx_a (a),unique key idx_b (b)) engine=innodb default charset=latin1; Query OK, 0 rows ...继续阅读 (4)

2012/12/20某业务合服后在唯一索引键上出现了重复键现象:mysql> select count(RoleGID) from RoleData_0; +----------------+ | count(RoleGID) | +----------------+ | 41255 | +----------------+ 1 row in set (0.00 sec) mysql> select count(distinct RoleGID) from RoleData_0; +-------------------------+ | count(distinct RoleGID) | +-------------------------+ | 41123 | +-------------------------+ 1 row in set (0.00 sec)其中RoleGID是表RoleData_0的唯一索引，但是部分数据却出现重复。【问题回顾】运维同事反馈，问题是这样产生的：1.执行合服脚本，脚本会向db_roledata_102504库导入RoleData_*表的数据2.由于脚本没有后台运行，并且过程中跳板机挂死，因此必须重新执行脚本，但此时已有部分数据入库。3.合服脚本中是使用mysql –f参数导入数据，会 ...继续阅读 (35)

2012/12/20某业务合服后在唯一索引键上出现了重复键现象 mysql> select count(RoleGID) from RoleData_0; +----------------+ | count(RoleGID) | +----------------+ | 41255 | +----------------+ 1 row in set (0.00 sec) ...继续阅读 (6)

腾讯游戏数据自愈服务方案简介1.引言在正式介绍项目背景之前，让我们先看一组数据：这是2个灰度的业务，都是Z3服务器，我们先只从时间成本的收益角度来看：⑴ 左一业务数据量是330G，数据不一致时通过重做slave需要150分钟左右，而借助pt-table-sync只需要5分钟，速度提升30倍。⑵ 右一业务的量是93G，通过sync工具花费3分钟，而如果重做slave要35分钟，速度提升12倍。引入这组数据意在指明，整个过程不仅解放了DBA的双手，也符合”零运维”的趋势，数据自愈将是互娱DBA团队在未来提供的服务之一。2. 背景MySQL数据库基于binlog的数据同步方案，绝大部分情况下能保证主备数据完全一致，但某些异常情况下，例如开发使用了unsafe statement的SQL（如带limit）及硬件故障等，都可能导致主备数据不一致。DBA通过checksum工具可以发现这些不一致的情况，但往往需要重新做一个热备来恢复主备数据一致性，并且此过程可能需要10小时以上，而实际情况上主备数据通常仅有少量不一致，在线修复这些数据差异可以更高效地完成一个数据一致的热备。3. 收益重做热备是我们目前首选的修复方案，但有时候没有备用的新机子却让修复步伐戛然而止，而如果没有修复，倘若master故障，由于数据不一致，切换到slave是存在数据丢失的风险，那么又不得不执行修复，DBA就需要评估 ...继续阅读 (25)

周一（2014-11-17）有个项目进行变更，而且是重大变更，DB测操作从早上持续到下午17点，QA同事到晚上10点测试后发现，slave上的数据与master上不一致。忘介绍了，该项目的该模块有读请求以及delete逻辑在上面，被吓到没？这个问题应该在情理之中但又在意料之外，其实DBA在下午DB变更时便遇到slave卡住：Could not execute Delete_rows event on table codcpc_1004pc_0x3EC.mail; Can't find record in 'mail ', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log binlog.010464, end_log_pos 82113, Error_code: 1032 141117 7:54:31 [Warning] Slave: Can't find record in 'mail' Error_code: 1032我当时的做法是直接跳过不存在的表，写了下面这个脚本：mysqlconn="mysql -uADMIN -p4word" #while [ "1" = "1" ] for i in `seq 1 30` do status=`$mysqlconn -e ...继续阅读 (33)

周一（2014-11-17）有个项目进行变更，而且是重大变更，DB测操作从早上持续到下午17点，QA同事到晚上10点测试后发现，slave上的数据与master上不一致。忘介绍了，该项目的该模块有读请求以及delete逻辑在上面，被吓到没？这个问题应该在情理之中但又在意料之外，其实DBA在下午DB变更时便遇到slave卡住：Could not execute Delete_rows event o ...继续阅读 (8)

背景是某个业务的logdb历史oss_log(MyISAM表类型)例行删除，有时候会告"deadlock"。当时我的第一反应是认为表很大，我并没有对这种一厢情愿的想法提出质疑，于是乎，我让运维找开发要了脚本，我希望通过优化脚本来优化执行时间！吭叽吭叽的准备开搞，而且也很高兴的想到了优化脚本的方法.....但从一开始我就没有从多个角度来看待这个问题，思维定式地认为这个是因为数据量大的原因。下面这幅图从2个角度看得到的东西是南辕北辙啊很多时候，在动手之前，先拿出笔和纸张，把问题认认真真分析一下，从不同角度会得到比较严谨而靠谱的方法，believe me！分析slow log发现有些删除需要很长时间，比如：drop table 2014_10_17_oss_abandonquest 花费了15041.2410秒。删除行为在凌晨4点发出，刚好落在备份期间，因为5.5有了MDL（Meta data lock），所以–single-transaction时，事务内操作过的表都会持有MDL，因此不会被DDL破坏。所以，查看get_status.err会有如下日志：11966363,hardcore,localhost,oss_log,Query,11084,Waiting for table metadata lock,drop table 2014_10_17_oss_abandonquest ...继续阅读 (18)

背景是某个业务的logdb历史oss_log(MyISAM表类型)例行删除，有时候会告"deadlock"。分析slow log发现有些删除需要很长时间，比如：drop table 2014_10_17_oss_abandonquest 花费了15041.2410秒。删除行为在凌晨4点发出，刚好落在备份期间，因为5.5有了MDL（Meta data lock），所以–single-transact ...继续阅读 (8)

㈠ 背景介绍：2014/8/18 13点37分收到前端说反馈有玩家掉线情况，检查CPU、慢查询、DB请求量，并未发现异常，DB表现一如往常。㈡ 定位原因：INSERT INTO t (col1, col2, col3, col4, col5, col6, col7) VALUES ('3532082239485507011_130_99', '130_99', 130, 99, 3532082239485507011, 2172353000317425008, 29078)这个长事务执行 1个多小时没有退出，Kill 掉对应的进程，程序前端恢复正常㈢ 处理思路：⑴ 查询视图select trx_id,trx_state,trx_started,trx_requested_lock_id,trx_weight,trx_mysql_thread_id from information_schema.innodb_trx where trx_state='RUNNING';⑵ show engine innodb status\G; 关注Transactions部分提取SQL及事务信息㈣ 我的疑问：为什么这条执行了1个多小时的SQL没有被记录到慢查询日志中呢？？㈤ 原来如此：Query_time - Lock_time > long_query_time <===记录Query_tim ...继续阅读 (20)

㈠ 背景介绍：    2014/8/18 13点37分收到前端说反馈有玩家掉线情况，检查CPU、慢查询、DB请求量，并未发现异常，DB表现一如往常。㈡ 定位原因：INSERT INTO t (col1, col2, col3, col4, col5, col6, col7) VALUES ('3532082239485507011_130_99', '130_99', 130, 99, 35320 ...继续阅读 (7)

早上做数据迁移，部署完slave2,发现3台机子的日志狂刷：旧slave：2014-05-29 14:35:35 996 [Note] Slave: received end packet from server, apparent master shutdown: 2014-05-29 14:35:35 996 [Note] Slave I/O thread: Failed reading log event, reconnecting to retry, log 'mysql-bin.000005' at position 407 2014-05-29 14:35:35 996 [Warning] Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommende新slave：2014-05-29 14:35:35 16770 [Note] Slave: received end packet from server, apparent master shutdown: 2014-05-29 14:35:35 16770 [Note] Slave I/O thread: Failed readin ...继续阅读 (145)

早上做数据迁移，部署完slave2,发现3台机子的日志狂刷：旧slave：2014-05-29 14:35:35 996 [Note] Slave: received end packet from server, apparent master shutdown: 2014-05-29 14:35:35 996 [Note] Slave I/O thread: Failed reading l ...继续阅读 (7)

一. 需求最近在做数据库迁移，经常需要打包实例传输，传统scp感觉很慢。二. 软件信息1. 软件主页：http://tsunami-udp.sf.net/2. 软件安装：直接源码make && make install三. 简单使用以下介绍简明步骤：在源机子开启tsunami进程：tsunamid *在目标机子 connect ip && get四. 测试在几台待迁移服务器上(机子比较老)传输时发现在70Mb/s左右五. 使用经验如果做tar包，建议不使用压缩。六. 注意事项tsunami在传输的时候还是很消耗带宽的。如果对速度不要求可以不必使用。如果有，需要确认源主机上是否有其他优先级更高的业务在跑。By 迦叶2014-05-28Good Luck！ ...继续阅读 (23)

一. 需求      最近在做数据库迁移，经常需要打包实例传输，传统scp感觉很慢。二. 软件信息      1. 软件主页：http://tsunami-udp.sf.net/      2. 软件安装：直接源码make && make install三. 简单使用      以下介绍简明步骤：      在源机子开启tsunami进程：tsunamid *      在目标机子 connect ...继续阅读 (12)

昨天同事在做主从时，从库报如下错误：Got fatal error 1236 from master when reading data from binary log: 'Misconfigured master - server id was not set'粗粗看好像是master的server-id没有设置，但同事做如下查询：备库采集： root@localhost Fri May 23 14:18:59 2014 14:18:59 [(none)]> show variables like '%server_id%'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | server_id | 2 | +---------------+-------+ 主库采集： mysql> show variables like '%server%'; +----------------------+-------------------+ | Variable_name | Value | +----------------------+-------------------+ | character_set_ser ...继续阅读 (23)

昨天同事在做主从时，从库报如下错误：Got fatal error 1236 from master when reading data from binary log: 'Misconfigured master - server id was not set'粗粗看好像是master的server-id没有设置，但同事做如下查询：备库采集： root@localhost Fri May 23 ...继续阅读 (7)

复合索引最令人困惑的当属索引列的顺序，不仅依赖于使用该索引的查询，更需考虑排序和分组。前段时候我发了个帖子：where条件顺序和复合索引字段顺序。感兴趣的朋友不妨参与讨论。今天我提个自己的观点。在应用开发阶段，【选择性】是我们首要考虑因素，请看简图：当出现sql性能问题时，你可能需要注意以下几个：1. 随机IO2. 排序(order by)3. 分组(group by or distinct)这时不必也不应该在关注【选择性】我的经验便是，在你手上已经有Top N SQL时，我们应该优先考虑【值的分布】，而不是选择性。那么该如何判断【值的分布】，我们通过一种被geek称之为 【sarg】的方法，具体操作如下：假如，我们有如下query：select * from userresult_f where askid=800808 and uid=110996854;则有2个索引可供选择：1. idx_1 (askid,uid)2. idx_2 (uid,askid)是1 还是2 ？利用【sarg】方法：mysql> select sum(askid=800808),sum(uid=110996854) from userresult_f\G; *************************** 1. row *************************** sum(askid= ...继续阅读 (30)

复合索引最令人困惑的当属索引列的顺序，不仅依赖于使用该索引的查询，更需考虑排序和分组。前段时候我发了个帖子：where条件顺序和复合索引字段顺序。感兴趣的朋友不妨参与讨论。今天我提个自己的观点。在应用开发阶段，【选择性】是我们首要考虑因素，请看简图：当出现sql性能问题时，你可能需要注意以下几个：1. 随机IO2. 排序(order by)3. 分组(group by or distinct)这时 ...继续阅读 (11)

以下面关键字眼为例：1 物理备库健康检查依据：Tue Apr 22 16:44:51 CST 2014Media Recovery Log /data/CMS/arch_log/1_58334_722210153_58334arch.dbfMedia Recovery Waiting for thread 1 sequence 58335 (in transit)2 逻辑备库健康检查依据：Tue Apr 22 16:44:48 CST 2014LOGMINER: Begin mining logfile for session 1 thread 1 sequence 58335, /data/CMS/standbyredo22.logBy 数据牧羊人Good Luck！ ...继续阅读 (17)

以下面关键字眼为例：1 物理备库健康检查依据：Tue Apr 22 16:44:51 CST 2014Media Recovery Log /data/CMS/arch_log/1_58334_722210153_58334arch.dbfMedia Recovery Waiting for thread 1 sequence 58335 (in transit)2 逻辑备库健康检查依据：Tue ...继续阅读 (14)

事情是这样的，我们DBA组有位同学误删了备库的一个临时表，导致复制出错老大给力，江湖救急。关于该参数，淘宝丁奇写了篇文章还不错：MySQL小误区：关于set global sql_slave_skip_counter=N 命令的一些点还有360的杨挺也有一篇：sql_slave_skip_counter 介绍这2篇文章看下大概理解了最后说下，保险点的做法是 N恒等于 1，比较不容易出错 :-)当然跳得多了主从的不一致性的gap就越大如果对一致性要求较严格的业务不妨试下pt-table-checksum+pt-table-sync或mysqlreplsyncGood Luck！ ...继续阅读 (25)

事情是这样的，我们DBA组有位同学误删了备库的一个临时表，导致复制出错老大给力，江湖救急。关于该参数，淘宝丁奇写了篇文章还不错：MySQL小误区：关于set global sql_slave_skip_counter=N 命令的一些点还有360的杨挺也有一篇：sql_slave_skip_counter 介绍这2篇文章看下大概理解了最后说下，保险点的做法是 N恒等于 1，比较不容易出错 :-)当然 ...继续阅读 (12)

我们在基于物理standby的基础上搭建逻辑备库过程过程中，在执行：alter database recover to logical standby READDB;卡住不动，并且alert也没有报错信息，无比郁闷，咨询了别人，聊天记录如下：我们的业务是passport应用，无法停止或者停掉非常麻烦，总之，药不能停。经过摸索，我们得到一个经验：需要等到MRP应用日志到跟主库一致，此时执行该命令才不会hang住。具体流程大概是这样的：1. 开启实时日志应用ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION在这个过程中，我们可以边查看日志应用情况，在备库执行如下命令：SELECT SEQUENCE#,APPLIED FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;直到主备日志一致，判断SQL如下：在主库执行：archive log list在备库执行：select max(sequence#) from v$archived_log;根据这2个值即可判断日志是否一致2. 接着，我们需要在备库停掉MRP进程：alter database recover managed standby database cancel;注意，此 ...继续阅读 (39)

我们在基于物理standby的基础上搭建逻辑备库过程过程中，在执行：alter database recover to logical standby READDB;卡住不动，并且alert也没有报错信息，无比郁闷，咨询了别人，聊天记录如下：我们的业务是passport应用，无法停止或者停掉非常麻烦，总之，药不能停。经过摸索，我们得到一个经验：需要等到MRP应用日志到跟主库一致，此时执行该命令才不 ...继续阅读 (11)

前天在搭建物理standby时，前面步骤都没错(实际上是有错)，在验证归档日志是否同步到备库时发现：ORA-16047: DGID mismatch between destination setting and standby我们的处理方案是：在主备同时设置log_archive_config1. 备库idle> show parameter log_archive_config; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ log_archive_config string DG_CONFIG=(ORCL_PRY,ORCL_PHY)2. 主库sys@ORCL> show parameter log_archive_config; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ log_archive_config string DG_CONFIG=(ORCL_PRY,ORCL_PHY)什么是log_archive_confi ...继续阅读 (36)