住处附近是咖啡馆荒漠，星巴克早已不是能长时间待着的"第三空间"，漫咖啡常常人满为患人声鼎沸，需要天时地利和运气来找到一个位置，独立咖啡馆要么面积很小霸占一个座位就霸占了百分之好几十的空间，要么周末干脆不营业，找一个能专注读会儿书、用电脑处理点事情或者放空一下的地方很不容易。就在前几天，2019 年进度条剩下 1% 的时候，我才知道 2019 年是"中国付费自习室元年"，才发现原来还有这种神奇的地方，在元年的最后一个周末，我去体验了一下。 ...继续阅读 (21)

总共租过四次房子，第一次租房就被一个跟"诚信"倒着来，名字叫"信诚"的中介坑了，诚惶诚恐倍加爱惜，退房的时候还是被硬生生扣了几百块钱，理由是：厨房里有油。自那之后，我就没再跟中介租过房子了，遇到了几位有意思的房东。 ...继续阅读 (23)

more今天，3 月 6 日，是豆瓣 11 岁生日，我做梦一样游了 798，看到大蔡司，还以为蔡司在这里开店了呢，后来才发现污龙了，然后莫名其妙来到中二街，稀里糊涂和自由女神合了个影，受到了严重警告，突然醒悟虽然圆外那么大，但可能眼界之内都是荒草。说完正经的，接下来是不正经的。我基本上是一个严肃的人，尤其是前些年工作中讨论或者解决技术问题的时候，这倒也符合其他角色对工程师的一贯印象，想起来大概是 08 年的时候，在前东家做 Intacct 的一个项目，Intacct 的 CTO Aaron Harris 对我的其他评价我现在已经记不清了，但是 “Poker face” 我至今都还记得很清楚，形容得相当精准，翻译成中文的话，我想最接近的应该是「面瘫」。去年参加了几次培训，遇到了一群全都不是工程师的人，第一天的时候我如坐针毡脸上自然也是 “Poker face” 状，当然后面几天也没比第一天好到哪儿去，回来之后，有位同学看到我时不时在朋友圈里讲冷笑话，说：「哦，原来你不是我想象中的那种工程师。」其实，工作和生活中都有很多很好玩的事情，谐音、双关、翻译、重复、断句、曲解、自黑，处处都是脑洞，我还能记起来最早亲历的冷笑话，比我被称作 Poker face 还要更早一些，是同事们教老外 BA 学汉语时说，立春，意思就是 Standing Spring，他们还把公司的中文名字「华美汉盛」翻译成 ...继续阅读 (53)

more今天，3 月 6 日，是豆瓣 11 岁生日，我做梦一样游了 798，看到大蔡司，还以为蔡司在这里开店了呢，后来才发现污龙了，然后莫名其妙来到中二街，稀里糊涂和自由女神合了个影，受到了严重警告，突然醒悟虽然圆外那么大，但可能眼界之内都是荒草。说完正经的，接下来是不正经的。我基本上是一个严肃的人，尤其是前些年工作中讨论或者解决技术问题的时候，这倒也符合其他角色对工程师的一贯印象，想起来大概是 08 年的时候，在前东家做 Intacct 的一个项目，Intacct 的 CTO Aaron Harris 对我的其他评价我现在已经记不清了，但是 “Poker face” 我至今都还记得很清楚，形容得相当精准，翻译成中文的话，我想最接近的应该是「面瘫」。去年参加了几次培训，遇到了一群全都不是工程师的人，第一天的时候我如坐针毡脸上自然也是 Poker 状，当然后面几天也没比第一天好到哪儿去，回来之后，有位同学看到我时不时在朋友圈里讲冷笑话，说：「哦，原来你不是我想象中的那种工程师。」其实，工作和生活中都有很多很好玩儿的事情，谐音、双关、翻译、重复、断句、曲解、自黑，处处都是脑洞，我还能记起来最早亲历的冷笑话，比我被称作 Poker face 还要更早一些，是同事们教老外 BA 学汉语时说，立春，意思就是 Standing Spring，他们还把公司的中文名字「华美汉盛」翻译成 “Chin ...继续阅读 (31)

more今天，3 月 6 日，是豆瓣 11 岁生日，我做梦一样游了 798，看到大蔡司，还以为蔡司在这里开店了呢，后来才发现污龙了，然后莫名其妙来到中二街，稀里糊涂和自由女神合了个影，受到了严重警告，突然醒悟虽然圆外那么大，但可能眼界之内都是荒草。说完正经的，接下来是不正经的。我基本上是一个严肃的人，尤其是前些年工作中讨论或者解决技术问题的时候，这倒也符合其他角色对工程师的一贯印象，想起来大概是 08 年的时候，在前东家做 Intacct 的一个项目，Intacct 的 CTO Aaron Harris 对我的其他评价我现在已经记不清了，但是 “Poker face” 我至今都还记得很清楚，形容得相当精准，翻译成中文的话，我想最接近的应该是「面瘫」。去年参加了几次培训，遇到了一群全都不是工程师的人，第一天的时候我如坐针毡脸上自然也是 Poker 状，当然后面几天也没比第一天好到哪儿去，回来之后，有位同学看到我时不时在朋友圈里讲冷笑话，说：「哦，原来你不是我想象中的那种工程师。」其实，工作和生活中都有很多很好玩儿的事情，谐音、双关、翻译、重复、断句、曲解、自黑，处处都是脑洞，我还能记起来最早亲历的冷笑话，比我被称作 Poker face 还要更早一些，是同事们教老外 BA 学汉语时说，立春，意思就是 Standing Spring，他们还把公司的中文名字「华美汉盛」翻译成 “Chin ...继续阅读 (20)

同事最近在拆分数据库和清理数据，这当中有一些趣事，比如在拆分一个叫 luz 的集群时，新拆出的集群被命名为了 lua，可以从至少两个角度来理解这个名字，比如最显而易见的它是一门语言，除此之外它还代表从 z 到 a 的新一轮轮回；再比如拆分另一个叫 eag 的集群时，新集群被命名为 eager，不过它诞生时的含义其实是「eag 的 er 砸」。more也有一些哭笑不得的问题，比如发现有些表的数据清理 cron 曾经有日子没被成功执行，导致数据文件的体积相比它应有的大小暴涨了一个数量级；还有比如发现Sentry的nodestore_node表涨到了几百 GB，检查的时候发现了 nodestore 的粗糙设计，但其实很多开源软件甚至名声大噪的商业产品都是如此。比如近距离看一下 Sentry nodestore 的 schema：1234567CREATETABLE`nodestore_node`(`id`varchar(40)NOTNULL,`data`longtextNOTNULL,`timestamp`datetimeNOTNULL,PRIMARYKEY(`id`),KEY`nodestore_node_d80b9c9a`(`timestamp`))ENGINE=InnoDBDEFAULTCHARSET=utf8;它都有哪些问题呢？脱离业务场景，孤立地看这个 schema，除了这三点 ...继续阅读 (37)

同事最近在拆分数据库和清理数据，这当中有一些趣事，比如在拆分一个叫 luz 的集群时，新拆出的集群被命名为了 lua，可以从至少两个角度来理解这个名字，最显而易见的它是一门语言，除此之外它还代表从 z 到 a 的新一轮轮回；再比如拆分另一个叫 eag 的集群时，新集群被命名为 eager，不过它诞生时的含义其实是「eag 的 er 砸」。more也有一些哭笑不得的问题，比如发现有些应用的数据清理 cron 曾经有日子没被成功执行，导致数据文件的体积相比它应有的大小暴涨了一个数量级；还有比如发现Sentry的nodestore_node表涨到了几百 GB，检查的时候看到 nodestore 的 schema：1234567CREATETABLE`nodestore_node`(`id`varchar(40)NOTNULL,`data`longtextNOTNULL,`timestamp`datetimeNOTNULL,PRIMARYKEY(`id`),KEY`nodestore_node_d80b9c9a`(`timestamp`))ENGINE=InnoDBDEFAULTCHARSET=utf8;它都有哪些问题呢？脱离业务场景，孤立地看这个 schema，除了这三点可疑之处外其实并没有太多值得挑剔的：Primary key 比较长（40 个字符），通常是一个不当设计的预警信号。写入 ...继续阅读 (29)

同事最近在拆分数据库和清理数据，这当中有一些趣事，比如在拆分一个叫 luz 的集群时，新拆出的集群被命名为了 lua，可以从至少两个角度来理解这个名字，最显而易见的它是一门语言，除此之外它还代表从 z 到 a 的新一轮轮回；再比如拆分另一个叫 eag 的集群时，新集群被命名为 eager，不过它诞生时的含义其实是「eag 的 er 砸」。more也有一些哭笑不得的问题，比如发现有些应用的数据清理 cron 曾经有日子没被成功执行，导致数据文件的体积相比它应有的大小暴涨了一个数量级；还有比如发现Sentry的nodestore_node表涨到了几百 GB，检查的时候看到 nodestore 的 schema：1234567CREATETABLE`nodestore_node`(`id`varchar(40)NOTNULL,`data`longtextNOTNULL,`timestamp`datetimeNOTNULL,PRIMARYKEY(`id`),KEY`nodestore_node_d80b9c9a`(`timestamp`))ENGINE=InnoDBDEFAULTCHARSET=utf8;它都有哪些问题呢？脱离业务场景，孤立地看这个 schema，除了这三点可疑之处外其实并没有太多值得挑剔的：Primary key 比较长（40 个字符），通常是一个不当设计的预警信号。写入 ...继续阅读 (20)

MySQL 对 SQL 有很多扩展，有些用起来很方便，但有一些被误用之后会有性能问题，还会有一些意料之外的副作用，比如 REPLACE INTO。more比如有这样一张表：12345678CREATE TABLE `auto` (`id` int(10) unsigned NOT NULL AUTO_INCREMENT,`k` int(10) unsigned NOT NULL,`v` varchar(100) DEFAULT NULL,`extra` varchar(200) DEFAULT NULL,PRIMARY KEY (`id`),UNIQUE KEY `uk_k` (`k`)) ENGINE=InnoDB DEFAULT CHARSET=latin1auto 表有一个自增的 id 字段作为主键，字段 k 有 UNIQUE KEY 做唯一性约束。写入几条记录之后会是这样：1234567891011121314151617181920212223242526xupeng@diggle7:3600(dba_m) [dba] mysql> INSERT INTO auto (k, v, extra) VALUES (1, '1', 'extra 1'), (2, '2', 'extra 2'), (3, '3', 'extra 3');Query OK, 3 rows affe ...继续阅读 (44)

MySQL 对 SQL 有很多扩展，有些用起来很方便，但有一些被误用之后会有性能问题，还会有一些意料之外的副作用，比如 REPLACE INTO。more比如有这样一张表：12345678CREATE TABLE `auto` (`id` int(10) unsigned NOT NULL AUTO_INCREMENT,`k` int(10) unsigned NOT NULL,`v` varchar(100) DEFAULT NULL,`extra` varchar(200) DEFAULT NULL,PRIMARY KEY (`id`),UNIQUE KEY `uk_k` (`k`)) ENGINE=InnoDB DEFAULT CHARSET=latin1auto 表有一个自增的 id 字段作为主键，字段 k 有 UNIQUE KEY 做唯一性约束。写入几条记录之后会是这样：1234567891011121314151617181920212223242526xupeng@diggle7:3600(dba_m) [dba] mysql> INSERT INTO auto (k, v, extra) VALUES (1, '1', 'extra 1'), (2, '2', 'extra 2'), (3, '3', 'extra 3');Query OK, 3 rows a ...继续阅读 (35)

MySQL 对 SQL 有很多扩展，有些用起来很方便，但有一些被误用之后会有性能问题，还会有一些意料之外的副作用，比如 REPLACE INTO。more比如有这样一张表：12345678CREATE TABLE `auto` (`id` int(10) unsigned NOT NULL AUTO_INCREMENT,`k` int(10) unsigned NOT NULL,`v` varchar(100) DEFAULT NULL,`extra` varchar(200) DEFAULT NULL,PRIMARY KEY (`id`),UNIQUE KEY `uk_k` (`k`)) ENGINE=InnoDB DEFAULT CHARSET=latin1auto 表有一个自增的 id 字段作为主键，字段 k 有 UNIQUE KEY 做唯一性约束。写入几条记录之后会是这样：1234567891011121314151617181920212223242526xupeng@diggle7:3600(dba_m) [dba] mysql> INSERT INTO auto (k, v, extra) VALUES (1, '1', 'extra 1'), (2, '2', 'extra 2'), (3, '3', 'extra 3');Query OK, 3 rows a ...继续阅读 (19)

前几天又有同事掉进了给 SQL 的 IN 条件传参的坑，就像 SELECT col1, col2 FROM table1 WHERE id IN (1, 2, 3) 这类 SQL，如果是一个可变的列表作为 IN 的参数，那这个参数应该怎么传呢？more我见过至少这么几种：12id_list=[1,2,3]cursor.execute('SELECT col1, col2 FROM table1 WHERE id IN (%s)',id_list)这种方式是语法错误的，原因是 MySQLdb 做字符串格式化时占位符和参数个数不匹配。12id_list=[1,2,3]cursor.execute('SELECT col1, col2 FROM table1 WHERE id IN (%s)',(id_list,))这种方式语法是正确的，但语义是错误的，因为生成的 SQL 是 SELECT col1, col2 FROM table1 WHERE id IN ((‘1’, ‘2’, ‘3’))123id_list=[1,2,3]id_list=','.join([str(i)foriinid_list])cursor.execute('SELECT col1, col2 FROM table1 WHERE id IN ...继续阅读 (44)

前几天又有同事掉进了给 SQL 的 IN 条件传参的坑，就像 SELECT col1, col2 FROM table1 WHERE id IN (1, 2, 3) 这类 SQL，如果是一个可变的列表作为 IN 的参数，那这个参数应该怎么传呢？more我见过至少这么几种：12id_list=[1,2,3]cursor.execute('SELECT col1, col2 FROM table1 WHERE id IN (%s)',id_list)这种方式是语法错误的，原因是 MySQLdb 做字符串格式化时占位符和参数个数不匹配。12id_list=[1,2,3]cursor.execute('SELECT col1, col2 FROM table1 WHERE id IN (%s)',(id_list,))这种方式语法是正确的，但语义是错误的，因为生成的 SQL 是 SELECT col1, col2 FROM table1 WHERE id IN ((‘1’, ‘2’, ‘3’))123id_list=[1,2,3]id_list=','.join([str(i)foriinid_list])cursor.execute('SELECT col1, col2 FROM table1 WHERE id IN ...继续阅读 (34)

前几天又有同事掉进了给 SQL 的 IN 条件传参的坑，就像 SELECT col1, col2 FROM table1 WHERE id IN (1, 2, 3) 这类 SQL，如果是一个可变的列表作为 IN 的参数，那这个参数应该怎么传呢？more我见过至少这么几种：12id_list=[1,2,3]cursor.execute('SELECT col1, col2 FROM table1 WHERE id IN (%s)',id_list)这种方式是语法错误的，原因是 MySQLdb 做字符串格式化时占位符和参数个数不匹配。12id_list=[1,2,3]cursor.execute('SELECT col1, col2 FROM table1 WHERE id IN (%s)',(id_list,))这种方式语法是正确的，但语义是错误的，因为生成的 SQL 是 SELECT col1, col2 FROM table1 WHERE id IN ((‘1’, ‘2’, ‘3’))123id_list=[1,2,3]id_list=','.join([str(i)foriinid_list])cursor.execute('SELECT col1, col2 FROM table1 WHERE id IN ...继续阅读 (18)

在 Linux 下要确认一个进程的发起者身份，比如用户 tom 登录系统，sudo su -到 root，然后执行了脚本hey.sh，要想在hey.sh中追溯到发起进程的是 tom 这个用户，并不是很容易做到准确无误，花了点时间，找到了一个相对靠谱的方式。more先说说遇到的几个问题：用户登录之后，使用sudo hey.sh的方式执行hey.sh，倒是可以通过环境变量SUDO_USER获取到sudo之前的用户，但没有办法解决上面提到的sudo su -这样不继承之前用户环境变量的问题。可以用tty命令获取当前进程的 controlling terminal，然后通过 controlling terminal 文件的属主来确认登录用户，这可以解决 1 中提到的问题，但是如果当前进程的父进程是 daemon 或者关掉了标准输入，就没有 controlling terminal。可以通过读取/proc/self/loginuid获取当前进程的登录用户 ID，对于没有 controlling terminal 的进程也可以获取到 ID，但对于 daemon 进程来说，获取的 ID 可能是 4294967295。在我的场景下，对于第三个问题，并不是特别要紧，找不到对应的用户，fallback 回 effective user 就好， 所以，用来追溯进程发起用户身份的 bash 脚本是这样：1 ...继续阅读 (43)

在 Linux 下要确认一个进程的发起者身份，比如用户 tom 登录系统，sudo su -到 root，然后执行了脚本hey.sh，要想在hey.sh中追溯到发起进程的是 tom 这个用户，并不是很容易做到准确无误，花了点时间，找到了一个相对靠谱的方式。more先说说遇到的几个问题：用户登录之后，使用sudo hey.sh的方式执行hey.sh，倒是可以通过环境变量SUDO_USER获取到sudo之前的用户，但没有办法解决上面提到的sudo su -这样不继承之前用户环境变量的问题。可以用tty命令获取当前进程的 controlling terminal，然后通过 controlling terminal 文件的属主来确认登录用户，这可以解决 1 中提到的问题，但是如果当前进程的父进程是 daemon 或者关掉了标准输入，就没有 controlling terminal。可以通过读取/proc/self/loginuid获取当前进程的登录用户 ID，对于没有 controlling terminal 的进程也可以获取到 ID，但对于 daemon 进程来说，获取的 ID 可能是 4294967295。在我的场景下，对于第三个问题，并不是特别要紧，找不到对应的用户，fallback 回 effective user 就好， 所以，用来追溯进程发起用户身份的 bash 脚本是这样：1 ...继续阅读 (36)

在 Linux 下要确认一个进程的发起者身份，比如用户 tom 登录系统，sudo su -到 root，然后执行了脚本hey.sh，要想在hey.sh中追溯到发起进程的是 tom 这个用户，并不是很容易做到准确无误，花了点时间，找到了一个相对靠谱的方式。more先说说遇到的几个问题：用户登录之后，使用sudo hey.sh的方式执行hey.sh，倒是可以通过环境变量SUDO_USER获取到sudo之前的用户，但没有办法解决上面提到的sudo su -这样不继承之前用户环境变量的问题。可以用tty命令获取当前进程的 controlling terminal，然后通过 controlling terminal 文件的属主来确认登录用户，这可以解决 1 中提到的问题，但是如果当前进程的父进程是 daemon 或者关掉了标准输入，就没有 controlling terminal。可以通过读取/proc/self/loginuid获取当前进程的登录用户 ID，对于没有 controlling terminal 的进程也可以获取到 ID，但对于 daemon 进程来说，获取的 ID 可能是 4294967295。在我的场景下，对于第三个问题，并不是特别要紧，找不到对应的用户，fallback 回 effective user 就好， 所以，用来追溯进程发起用户身份的 bash 脚本是这样：1 ...继续阅读 (23)

得知下厨房的数据被误删了，正在紧张恢复中。作为犯过很多次严重错误的人，我最想说的是，善待当事人吧，此刻他在承受着巨大的压力，比其他任何人都要心焦，他会很感激你的善言和善意。这几年犯过很多次严重影响线上服务的错误，像重启了错误的节点这样的事情应该算作能够对线上造成影响的最微不足道的错误，就只简单说几件现在都还让我心有余悸的事吧。more停用线上 memcache 集群在调整 memcache 客户端配置的使用和部署方式之前，尽管经过了多次测试，比如在部分节点先上线，确认没有问题之后上线所有的应用服务器，但还是使用了错误的配置，导致线上所有应用禁用了 memcache，巨大的访问压力瞬间拖垮了数据库，从发现问题到完全恢复持续了将近二十分钟。软件 bug 导致线上 memcache 集群被污染上线的代码在特定条件下会禁掉对 memcache 的使用，导致在本应清除 cache 的情况下没有清除，污染了整个线上的 memcache 集群，后果是各处功能出现诡异的问题，比如提醒死也叉不掉… 不得不将整个 memcache 集群 flush 一遍消除影响，耗时半天。恢复数据时删除了更多数据线上有豆列被误删了，从备份紧急恢复时，使用 mysqldump 导出需要恢复的那部分数据，但是遗憾的是连DROP TABLE ...也一起 dump 了，并且在线上执行之前都没有意识到。结果，原本需要恢复的只 ...继续阅读 (37)

得知下厨房的数据被误删了，正在紧张恢复中。作为犯过很多次严重错误的人，我最想说的是，善待当事人吧，此刻他在承受着巨大的压力，比其他任何人都要心焦，他会很感激你的善言和善意。这几年犯过很多次严重影响线上服务的错误，像重启了错误的节点这样的事情应该算作能够对线上造成影响的最微不足道的错误，就只简单说几件现在都还让我心有余悸的事吧。more停用线上 memcached 集群在调整 memcached 客户端配置的使用和部署方式之前，尽管经过了多次测试，比如在部分节点先上线，确认没有问题之后上线所有的应用服务器，但还是使用了错误的配置，导致线上所有应用禁用了 memcached，巨大的访问压力瞬间拖垮了数据库，从发现问题到完全恢复持续了将近二十分钟。软件 bug 导致线上 memcached 集群被污染上线的代码在特定条件下会禁掉对 memcached 的使用，导致在本应清除 cache 的情况下没有清除，污染了整个线上的 memcached 集群，后果是各处功能出现诡异的问题，比如提醒死也叉不掉… 不得不将整个 memcached 集群 flush 一遍消除影响，耗时半天。恢复数据时删除了更多数据线上有豆列被误删了，从备份紧急恢复时，使用 mysqldump 导出需要恢复的那部分数据，但是遗憾的是连DROP TABLE ...也一起 dump 了，并且在线上执行之前都没有意识到。结果，原 ...继续阅读 (31)

得知下厨房的数据被误删了，正在紧张恢复中。作为犯过很多次严重错误的人，我最想说的是，善待当事人吧，此刻他在承受着巨大的压力，比其他任何人都要心焦，他会很感激你的善言和善意。这几年犯过很多次严重影响线上服务的错误，像重启了错误的节点这样的事情应该算作能够对线上造成影响的最微不足道的错误，就只简单说几件现在都还让我心有余悸的事吧。more停用线上 memcached 集群在调整 memcached 客户端配置的使用和部署方式之前，尽管经过了多次测试，比如在部分节点先上线，确认没有问题之后上线所有的应用服务器，但还是使用了错误的配置，导致线上所有应用禁用了 memcached，巨大的访问压力瞬间拖垮了数据库，从发现问题到完全恢复持续了将近二十分钟。软件 bug 导致线上 memcached 集群被污染上线的代码在特定条件下会禁掉对 memcached 的使用，导致在本应清除 cache 的情况下没有清除，污染了整个线上的 memcached 集群，后果是各处功能出现诡异的问题，比如提醒死也叉不掉… 不得不将整个 memcached 集群 flush 一遍消除影响，耗时半天。恢复数据时删除了更多数据线上有豆列被误删了，从备份紧急恢复时，使用 mysqldump 导出需要恢复的那部分数据，但是遗憾的是连DROP TABLE ...也一起 dump 了，并且在线上执行之前都没有意识到。结果，原 ...继续阅读 (20)

之前一直以为hosts不支持把一个名字解析到多个 IP，因此凡是有解析到多个 IP 需求的场景，全部都使用了 DNS，偶然看host.conf的 man page，发现并不是这样，有些场景下仍然是可以使用hosts的。more使用hosts解析时，resolver 顺序读取 hosts 文件，返回第一条匹配记录对应的 IP，这也是我之前对hosts的理解，比如对于这样的hosts文件：121.1.1.1 host11.1.1.2 host1ping host1会看到1.1.1.1这个 IP，但如果在/etc/host.conf中设置multi on，虽然ping host1仍然只能看到1.1.1.1这个 IP，但 resolver 会返回hosts中对应于host1条目的所有 IP，以 Python 为例：12>>> socket.gethostbyname_ex('host1')('host1', [], ['1.1.1.1', '1.1.1.2'])获取到的 IP 列表顺序和hosts中定义的顺序一样，且是固定的，这与 Round-robin DNS 的行为仍有区别，但在有些场景下使用hosts+ 推送 +nscd名字缓存可以获得相对于 DNS 更好的总体性能和稳定性，比如doubanservice客户端获取服务器列表或许就可以改为使用hosts替换 DNS，获得更好的性能，同 ...继续阅读 (29)

之前一直以为hosts不支持把一个名字解析到多个 IP，因此凡是有解析到多个 IP 需求的场景，全部都使用了 DNS，偶然看host.conf的 man page，发现并不是这样，有些场景下仍然是可以使用hosts的。more使用hosts解析时，resolver 顺序读取 hosts 文件，返回第一条匹配记录对应的 IP，这也是我之前对hosts的理解，比如对于这样的hosts文件：121.1.1.1 host11.1.1.2 host1ping host1会看到1.1.1.1这个 IP，但如果在/etc/host.conf中设置multi on，虽然ping host1仍然只能看到1.1.1.1这个 IP，但 resolver 会返回hosts中对应于host1条目的所有 IP，以 Python 为例：12>>> socket.gethostbyname_ex('host1')('host1', [], ['1.1.1.1', '1.1.1.2'])获取到的 IP 列表顺序和hosts中定义的顺序一样，且是固定的，这与 Round-robin DNS 的行为仍有区别，但在有些场景下使用hosts+ 推送 +nscd名字缓存可以获得相对于 DNS 更好的总体性能和稳定性，比如doubanservice客户端获取服务器列表或许就可以改为使用hosts替换 DNS，获得更好的性能，同 ...继续阅读 (27)

之前一直以为hosts不支持把一个名字解析到多个 IP，因此凡是有解析到多个 IP 需求的场景，全部都使用了 DNS，偶然看host.conf的 man page，发现并不是这样，有些场景下仍然是可以使用hosts的。more使用hosts解析时，resolver 顺序读取 hosts 文件，返回第一条匹配记录对应的 IP，这也是我之前对hosts的理解，比如对于这样的hosts文件：121.1.1.1 host11.1.1.2 host1ping host1会看到1.1.1.1这个 IP，但如果在/etc/host.conf中设置multi on，虽然ping host1仍然只能看到1.1.1.1这个 IP，但 resolver 会返回hosts中对应于host1条目的所有 IP，以 Python 为例：12>>> socket.gethostbyname_ex('host1')('host1', [], ['1.1.1.1', '1.1.1.2'])获取到的 IP 列表顺序和hosts中定义的顺序一样，且是固定的，这与 Round-robin DNS 的行为仍有区别，但在有些场景下使用hosts+ 推送 +nscd名字缓存可以获得相对于 DNS 更好的总体性能和稳定性，比如doubanservice客户端获取服务器列表或许就可以改为使用hosts替换 DNS，获得更好的性能，同 ...继续阅读 (14)

发现在 MySQL master 上用 GRANT 语句授予用户权限和用 REVOKE 语句收回权限的操作没有被同步到 slave 上，有两个 bug 报告的行为和我遇到的一致：#25482#50460，但从文档看，#25482 描述的是 bug，而 #50460 描述的内容则是 MySQL 的预期行为。more这里和这里描述了 MySQL 如何判定是否要写 binlog，对于我遇到的问题，原因是做 GRANT/REVOKE 操作时没有选择默认数据库，而 MySQL 在没有默认数据库的情况下根本就不会把 GRANT/REVOKE 操作写入 binlog，当然也就不会被同步到 slave 上，要解决这个问题，在 GRANT/REVOKE 之前USE任意没有被--replicate-ignore-db忽略的数据库即可。 ...继续阅读 (35)

发现在 MySQL master 上用 GRANT 语句授予用户权限和用 REVOKE 语句收回权限的操作没有被同步到 slave 上，有两个 bug 报告的行为和我遇到的一致：#25482#50460，但从文档看，#25482 描述的是 bug，而 #50460 描述的内容则是 MySQL 的预期行为。more这里和这里描述了 MySQL 如何判定是否要写 binlog，对于我遇到的问题，原因是做 GRANT/REVOKE 操作时没有选择默认数据库，而 MySQL 在没有默认数据库的情况下根本就不会把 GRANT/REVOKE 操作写入 binlog，当然也就不会被同步到 slave 上，要解决这个问题，在 GRANT/REVOKE 之前USE任意没有被--replicate-ignore-db忽略的数据库即可。 ...继续阅读 (35)

发现在 MySQL master 上用 GRANT 语句授予用户权限和用 REVOKE 语句收回权限的操作没有被同步到 slave 上，有两个 bug 报告的行为和我遇到的一致：#25482#50460，但从文档看，#25482 描述的是 bug，而 #50460 描述的内容则是 MySQL 的预期行为。more这里和这里描述了 MySQL 如何判定是否要写 binlog，对于我遇到的问题，原因是做 GRANT/REVOKE 操作时没有选择默认数据库，而 MySQL 在没有默认数据库的情况下根本就不会把 GRANT/REVOKE 操作写入 binlog，当然也就不会被同步到 slave 上，要解决这个问题，在 GRANT/REVOKE 之前USE任意没有被--replicate-ignore-db忽略的数据库即可。 ...继续阅读 (21)

有朋友用 PHP 写了一个工具（limit.php），用来限制另一个进程的执行时间，代码如下：morelimit.php12345678910111213141516171819php<2)die("Wrong parameter\n");$cmd=$argv[1];$tl=isset($argv[2])?intval($argv[2]):3;$pid=pcntl_fork();if(-1==$pid){die('FORK_FAILED');}elseif($pid==0){exec($cmd);posix_kill(posix_getppid(),SIGALRM);}else{pcntl_signal(SIGALRM,create_function('$signo',"die('EXECUTE_ENDED\n');"));sleep($tl);posix_kill($pid,SIGKILL);die("TIMEOUT_KILLED :$pid\n");}使用这个工具对php -r 'while(1){sleep(1);echo PHP_OS;};'做测试：1php limit.php"php -r 'while(1){sleep(1);echo PHP_OS;};'"10可以看到共有三个进程：1234$ps -u$USER-opid,ppid,pgid,command|grep ...继续阅读 (52)

有朋友用 PHP 写了一个工具（limit.php），用来限制另一个进程的执行时间，代码如下：morelimit.php12345678910111213141516171819<?phpdeclare(ticks=1);if($argc<2)die("Wrong parameter\n");$cmd=$argv[1];$tl=isset($argv[2])?intval($argv[2]):3;$pid=pcntl_fork();if(-1==$pid){die('FORK_FAILED');}elseif($pid==0){exec($cmd);posix_kill(posix_getppid(),SIGALRM);}else{pcntl_signal(SIGALRM,create_function('$signo',"die('EXECUTE_ENDED\n');"));sleep($tl);posix_kill($pid,SIGKILL);die("TIMEOUT_KILLED :$pid\n");}使用这个工具对php -r 'while(1){sleep(1);echo PHP_OS;};'做测试：1php limit.php"php -r 'while(1){sleep(1);echo ...继续阅读 (41)

有朋友用 PHP 写了一个工具（limit.php），用来限制另一个进程的执行时间，代码如下：morelimit.php12345678910111213141516171819<?phpdeclare(ticks=1);if($argc<2)die("Wrong parameter\n");$cmd=$argv[1];$tl=isset($argv[2])?intval($argv[2]):3;$pid=pcntl_fork();if(-1==$pid){die('FORK_FAILED');}elseif($pid==0){exec($cmd);posix_kill(posix_getppid(),SIGALRM);}else{pcntl_signal(SIGALRM,create_function('$signo',"die('EXECUTE_ENDED\n');"));sleep($tl);posix_kill($pid,SIGKILL);die("TIMEOUT_KILLED :$pid\n");}使用这个工具对php -r 'while(1){sleep(1);echo PHP_OS;};'做测试：1php limit.php"php -r 'while(1){sleep(1);echo ...继续阅读 (21)

这周遇到了三个值得说一说的问题，每一个问题都带来了不小的麻烦，作为教训再来回顾一下。more第一个问题，在某次上线之后，突然出现了很多AttrubuteError和TypeError，这些错误看起来都是不应该出现的，究其原因，是从 memcached 中取回的数据和预期的不同。在代码中对容易出问题的 key 做跟踪，却找不到有任何代码对这些 key 做过 set 操作，但 memcached 中的数据的确是错的，由此基本可以推定并不是有代码 set 了错误的 key。在定位问题的过程中发现，重启应用时会有很大的机率触发 memcached 数据错乱，以此为线索，hongqn最终定位到了导致此问题的原因：Quixote在 fork 子进程之前 import 了部分应用代码，某个 changset 中的改动又使得部分代码在被 import 时就创建了到 memcached 的连接，多个子进程使用同一个 memcached 连接，数据包交织导致了 memcached 通讯混乱。这里主要有两个问题：Quixote在 fork 之前调用了应用代码、memcached 客户端库非线程安全；解决这两个问题中的任意一个都可以避免数据错乱的问题发生，第二个问题也可以通过在 fork 之后重新建立连接来作为 workaround 手段而绕过其线程安全的问题。第二个问题危害就更大了，几乎所有的 MySQ ...继续阅读 (26)