知之 ['zhi]

昨天为一个项目做前奏，给mysql的一张大约有100w条记录的大表加两个字段。很显然，如果直接用alter语句直接添加，会使得mysql锁表大约20分钟，这将是不可接受的。通常的做法是

1. 创建一张新表new_table，这个新表是有加字段后的schema

2. copy 原始表original_table的数据到新表，新增字段给默认值

3. rename两个表：original_table -> old_table，new_table -> original_table

创建新表没有悬念。

copy数据这一步之需要执行一个sql：

insert into new_table(col1,col2,col3...,new_...

或许你不太会喜欢异常，特别是那些发生后继而沉默在应用日志里那些，你不知道从何开始，因为它们看起来并非那么平易近人，但是用户吵着他的数据有问题，你只得硬着头皮在多个服务器的日志里，翻箱倒柜，试着从堆栈里发现些什么，但是毫无线索，因为你发现这根本是一桩无头命案，没有足够的上下文，不知道哪个才是这个用户的某个操作引起的异常，请求链接更无从谈起，好吧，再去nginx日志里看看吧……但幸运的是，你不是孤独的，Disqus也面临着同样的问题，因此而开发了Sentry，它是一款精致的Django应用，目的在于帮助开发人员从散落在多个不同服务器上毫无头绪的日志文件里发掘活跃的异常，继而找到潜在的臭虫，当然这个...

    这些模式就像设计模式一样，在我们的系统中不是看你使用了多少模式，或者说是否严格的遵守了这些模式，模式能解决的是大部分通用的情景，但是在实际应用时也要看上下文。

    Why bother this? 我们系统不是孤立存在，他依赖着很多服务（一个完全不依赖任何资源、服务的系统，几乎是不存在的，当然你可以举出反例，但我觉得这个系统的存在也没有太多意义），很多时候他和这些服务工作的很好但是如果你对他们没有任何防范的话，某天他会让你尝到苦头。

    在Release it! 一书中举出一些模式以防止某些经常发生的问题再次发生（本书作者提到自己所解决过的线上故障都是新问题，是因为他从不让同...

    我个人是比较喜欢抱怨的，对许多事情不满，有悖于James Murphy说的The best way to complain is to make things.但是我毅然决然stop from making things，而且最近又有人建议我“顺其自然”，那我就随性牢骚一下。