精选技术长文、实践记录与系统化阅读
低噪声、高可扫读；标题、摘要、来源、标签一目了然。
采集自各技术站点的近期文章。
文章主要讨论的是 MySQL 备份和其恢复机制，以及对维护数据表的正确维护，其中主要包括的两种不同表的类型有MyISAM与 Innodb，文中所设计的 MySQL 版本为 5.0.22。以下就是具体内容的描述。 目前 MySQL 支持的免费MySQL 备份工具有：mysqldump、mysqlhotcopy，还可以用 SQL 语法进行备份：BACKUP TABLE 或者 SELECT INTO OUTFILE，又或者备份二进制日志（binlog），还可以是直接拷贝数据文件和相关的配置文件。MyISAM 表是保存成文件的形式，因此相对比较容易备份，上面提到的几种方法都可以使用。Innodb 所有的表都保存在同一个数据文件 ibdata1 中（也可能是多个文件，或者是独立的表空间文件），相对来说比较不好备份，免费的方案可以是拷贝数据文件、备份 binlog，或者用 mysqldump。 1、m
以下的文章主要介绍的是MySQL数据类型，MySQL数据库中的5种数据类型是：字符型，文本型，数值型，逻辑型与日期型，以下就是文章的详细内容介绍，希望在你今后的学习中会有所帮助。 MySQL数据类型之一字符型 VARCHAR VS CHAR VARCHAR型和CHAR型数据的这个差别是细微的，但是非常重要。他们都是用来储存字符串长度小于255的字符。 假如你向一个长度为四十个字符的VARCHAR型字段中输入数据Bill Gates。当你以后从这个字段中取出此数据时，你取出的数据其长度为十个字符——字符串Bill Gates的长度。 现在假如你把字符串输入一个长度为四十个字符的CHAR型字段中，那么当你取出数据时，所取出的数据长度将是四十个字符。字符串的后面会被附加多余的空格。 当你建立自己的站点时，你会发现使用VARCHAR型字段要比CHAR型字段方便的多。使用VA
此文章主要介绍的是获得MySQL命令行中常用命令的小招数，如果你掌握了获得MySQL命令行中常用命令的小招这项技术，会在以后的学习或是工作中带来很大的帮助。以下就是文章的主要内容描述。 MySQL命令行常用命令 第一招、MySQL服务的启动和停止 net stop MySQL net start MySQL MySQL命令行常用命令 第二招、登陆MySQL 语法如下： MySQL -u用户名 -p用户密码 键入命令MySQL -uroot -p， 回车后提示你输入密码，输入12345，然后回车即可进入到MySQL中了，MySQL的提示符是： MySQL> 注意，如果是连接到另外的机器上，则需要加入一个参数-h机器IP MySQL命令行常用命令 第三招、增加新用户 格式：grant 权限 on 数据库.* to 用户名@登录主机 identified by "密码"
首先我们要知道，或许有一项技术存在很多理由让我们可以选择使用它，但是让我们不使用它往往只要有一个理由就足够了。选择一个软件产品同样也是如此。 MySQL数据库虽然应用很广泛，受到大家的青睐，但MySQL数据库也有负面的作用，下面就介绍五个不适用 MySQL数据库的给力理由。 1、MySQL(和PHP搭配之最佳组合)的授权方式 MySQL(和PHP搭配之最佳组合)采用双重授权(Dual Licensed)，它们是GPL和MySQL(和PHP搭配之最佳组合) AB制定的商业许可协议。 如果你在一个遵循GPL的自由(开源)项目中使用MySQL(和PHP搭配之最佳组合)，那么你可以遵循GPL协议使用MySQL(和PHP搭配之最佳组合)。然而，如果你的项目不是在GPL协议下的话，你必须为使用MySQL(和PHP搭配之最佳组合)来支付许可费用，或者你可能因为这个因素而将你的项目改为遵循GPL，那么你
前些日子收到一封邮件咨询怪蜀黍，大意是，如果在公司内部可借力的资源比较少，是否还有可能白手起家地去做电子邮箱项目？我对这个话题很感兴趣，借景抒情，单起一篇日志谈谈“体制内创业”的事情。“体制”的意思是，你所在环境有它成功的核心业务，以及配套的管理规范。“创业”的意思是，除了有限的核心人员，几乎一无所有白手起家。这两个词混搭在一起很奇妙，但却是2012年很多公司面临的现状。先从体制说起。整个2011年，几乎所有互联网公司都面对同一个难题：“找项目”。这时，2008年后越刮越猛的产品风渐渐消停。四年来上马了无数新产品，最后存活率不足百分之五，成功率不足千分之一，只留下疮痍满目的烂摊子，烂尾楼。但凡有点头脑的大公司头头都意识到两件事情：第一，好机会真的很少，容易实现的需求早就被满足了，轮不到自己抢滩。第二，假如管理基因不合，有些机会即便看到了也抓不住的，而基因几乎无法改造。与此同时，作为公司、部
如果你用lighttpd1.5(以下lighttpd均指1.5)做静态文件服务器，或者你虽然用lighttpd处理php请求，但是用到$PHYSICAL作为mod_proxy_core的条件， 且某个时候你的单机流量很低(几个/s), 或许你也有类似的问题，但是影响程度或许不会引起你的注意！ 1.Lighttpd的mod_proxy_core不建议用$PHYSICAL作为条件； 2.Lighttpd的stat cache机制没有节省任何开销； 3.Lighttpd子线程和主线程通过管道+epoll的通信机制，存在event丢失问题； 现象用户反馈凌晨的时候访问百度某页面，某些模块的数据出不来；其它依赖于我们的前端接口的产品线反馈访问时间有时候超过1s；我们自己的QA环境偶尔也会出现请求超过1s的问题；因此我们打开lighttpd的日志的%D配置，打印ms级别的处理时间，发现
引言 当前的“云计算”一词已经被神话，似乎快成了放之四海皆准的时髦真理，就好比当初言必称“希腊”一般，表面光芒四射，但实际上却无比教条、且越来越令人生厌。 作为“云计算”的一个普通开发者和是推广者，很有必要通过亲身实践，以正视听，希望能让后来者(云计算系统的开发者)少走弯路——有所为、有所不为。
[导读] 本次学习的内容是如何有效分发cron任务,有效分发,大家都懂的,以及如何解发更新puppet 动作,运维人员 都知道,通常配置文件变更,需要重新reload服务,以应用的新的配置文件.大家看过sky之前的文章,其中都有
元旦前，腾讯微博开放新版测试，试用后颇多感慨。因懒惰拖了一个半月，才来写这篇文章。整个2011年，一直有人说“新浪微博不行了”“新浪微博滑坡了”。狼来了喊了一整年，到年末似乎声音越来越大，这倒不是什么大灾变，有可能仅仅是轻微的触顶回弹，甚至只是上升速度放缓而已。对淡出新浪微博的用户做了几个小样本访谈，原因很雷同，都对公共话题感到麻木，又厌倦了大路货转发。看上去，似乎正印证了“社交才是微博的出路”“腾讯微博才是最后的赢家”，我可不这么想。我访谈的用户在新浪微博也有自己的社交关系，同事/同学/家人等等，小圈子里经常发一些生活类的话题。尤其在淡出新浪之后，他们并没有回归原本常泡的人人、豆瓣，或转战腾讯微博，而是处于一种“什么都玩腻了”的飘忽状态，像是被重口味“吃伤到了”……对于社交之于微博，我有几个观点：★国内用户分享生活的频度并不高，主打社交牌的话，无法维持微博的热度与速度，因此还需要引入公共
前几天因为测试新版的Flashcache，为了便于监控性能指标，用Perl写了个秒级的监控程序Flashstat，一开始是通过定期获取dmsetup status的信息做解析，后来在flashcache-dev邮件列表中讨论时，Flashcache的...
我们可以用内存来模拟一个性能很好的Flash设备，当然这有一个缺点，就是主机重启后就啥都没了，不过用于实验测试这应该不是什么大问题。用内存来模拟块设备有两种方法，ramdisk或者tmpfs+loop device。由于ramdisk要调整大小需要修改grub并重启，这里我们用tmpfs来实现。
前文简单介绍了block device和device mapper。有了这两个基础，再来看flashcache的代码，就容易理解多了。Flashcache是一个内核模块，要更清晰的理解代码，还需要了解一下内核模块编写的一些基础知...
前文简单的介绍了block device，别急，虽然这个系列的主要目的是介绍Flashcache，这一篇还是不会切入正题，因为我们还需要先了解下什么是device mapper。 假如一台主机插入了多块硬盘，单块硬盘...
Cache is king. 在计算机系统中，cache的魔爪无处不在。CPU中有L1,L2,甚至L3 cache;Linux有pagecache，MySQL有buffer cache/query cache;IO系统中Raid卡/磁盘也有cache;在大型互联网系统中，数据库前面一般也都有一层...
教科书上的B+Tree是一个简化了的，方便于研究和教学的B+Tree。然而在数据库实现时，为了 更好的性能或者降低实现的难度，都会在细节上进行一定的变化。下面以InnoDB为例，来说说。
在Linux 2.4 IPv4 FIB的数据结构基础上实现IPv6的FIB是否可行呢？如果读了我前面这篇文字你应该会有一个判断。IPv4的FIB实现可以说有些拙劣，如果照搬一个IPv6版本，最差情况下需要进行128次hash key计算这还不包括链表的查找过程。看了一下Linux 2.6的IPv6 FIB实现，已经有了调整，用了Patrix(Radix)树实现了这个算法，下面是一些背景知识：首先是Trie树，下图是Wiki http://en.wikipedia.org/wiki/Trie 之中的一个例子 Trie树，尤其是二叉Trie树属于：是一直被使用 ，从未被(教科书)重视的东东。其特点是键值的内容成为树的检索路径，例如上图的to，tea等几条键值标明的路径。如果要对trie分类的话，我想只能按照出度来分类，上图假定键值的每一字节取值a-z，则这个trie是26叉trie树，最小
List是工程师的基本功，这里并不描述list增删这些细节的内容，仅仅根据我的理解写一下工程中List库的设计和实践考量。看过几个不同的list库的实现，基本上涉及到如下的设计考量： 1.List数据结构上的差异有没有头结点，是否循环，是否双向。这样就有多种组合，不罗嗦。 2.list的读写的保护。 3.List直接指针遍历还是仿照STL的Iterator方式遍历。 4.List同实际用户数据是采取一体式还是干湿分离式。 5.系统对于数据结构和算法的影响 1.从数据结构上将，Linux Kernel之中的List是双向无头节点链表。空链表如下： 非空链表如下： 我觉得维护头结点的理由之一就是可以存放list size，而无需用户在应用部分进行维护。如果没有list size，用户需要在List删减的结束的时候维护list size，如果不愿意如此麻烦，只能悲催的在需要读取
兼回忆贴，大概在03年开始接触Linux的协议栈代码，那个时候还找不到什么参考书，有些东西自己搞明白了但是也从来没想过在那个论坛发个帖子什么的，也没有现在的记录总结的习惯. 后来有一本08年版的《TCP/IP Architecture, Design and Implementation in Linux》其中解析了Linux2.4 协议栈的多数代码，其中第五章专门涉及skbuff的代码实现讲解，非常详细，这个小短文不翻译整个章节，各种网文很多，只是想根据关键部分说一下我理解的设计背后的原因。 skbuff的形态1 上面是最基本的一个sk_buff了，一个TCP报文的skbuff示意图，这里隐含着一些内容：报文分析的标准模式 skbuff采用的大块控制结构对象指向数据区是标准的实现模式，例如BSD这样的OS以及工程实现中都是这样的。参数的集中与其提供多个对象或者多个参数保存
在Linux2.4的时候，对于Linux的FIB表有些研究。凭着残存的记忆和code，恢复一下FIB的数据结构。首先扫盲一下几个路由协议架构相关的概念： 上图为路由协议的基本架构，相关内容在Cisco出版社出版的某一本图书上有概念描述，大概是《Routing TCP》。 1． 每个路由协议根据自己收集到的路由信息产生内部的路由表。所有的路由协议的路由信息汇聚到统一的RIB之中。 2． RIB的管理模块根据RIB之中的路由条目按照优先级优选出实际用于转发的路由下发到FIB之中。 3． 最终在Packet到来的时候，系统查找FIB表做路由查找。对于FIB的主要需求有两个： 1. 组织和存储选出的路由表项。 2. 按照LPM(最长掩码匹配)算法提供路由检索接口。下图是Linux24之中的FIB表中几个主要的数据对象的数据结构关系。 具体字段不做解释，最终的目的就是找到dn_fib_n
JavaScript 中通过call或者apply用来代替另一个对象调用一个方法，将一个函数的对象上下文从初始的上下文改变为由 thisObj 指定的新对象。简单的说就是改变函数执行的上下文，这是最基本的用法。两个方法基本区别在于传参不同。 call(obj,arg1,arg2,arg3);call第一个参数传对象，可以是null。参数以逗号分开进行传值，参数可以是任何类型。 apply(obj,[arg1,arg2,arg3]);apply第一个参数传对象，参数可以是数组或者arguments 对象。
