端午节到了，3天的假期可以好好放松下紧张了又一个月的神经，同时也可以总结一下近期的工作；遗憾的是，自从工作了就再也没能吃到老妈包的粽子了（姜米配上红豆、花生、大红枣，我的最爱）。

DBA的工作不知不觉已经经历了第二个月，比第一个月更加“凶险”——死里逃生（未知），我似乎成为了运维部的【问题焦点】，信任、仔细、积极、能力、诚实等等属性都面临着各方面的考验。曾经一度想逃离，工作的郁闷，自己内心的沉重，问题冒呀冒；我怕，真的开始怕了，怕打开终端执行每一条命令，怕后面又有什么问题在等着我，怕看到同事质问眼神，怕被领导冰冷的气场所笼罩，一点都不夸张，我甚至开始恐惧去公司，那个让我压抑的舞台，尽管我喜欢这份工作。第一次体会到工作带给我这么多的感受。庆幸的是，我坚挺了下来，学着慢慢调整心态；世界杯的到来也让我心情放松了很多，即便被开，也有理由——为了看世界杯休息一个月嘛，毕竟4年才一次，尽情享受一个个美妙和谐的夜晚。（Come on Portugal,Come on C’Ronaldo!）
      » 继续阅读 DBA工作初体验之死里逃生

1、复制进程
MySQL的复制（Replication）是一个异步的复制，从一个MySQL instace（称之为Master）复制到另一个MySQL instance（称之Slave）。实现整个复制操作主要由三个进程完成的，其中两个进程在Slave（Sql进程和IO进程），另外一个进程在 Master（IO进程）上。

要实施复制，首先必须打开Master端的binary log（bin-log）功能，否则无法实现。因为整个复制过程实际上就是Slave从Master端获取该日志然后再在自己身上完全顺序的执行日志中所记录的各种操作。

Master上的bin-log文件的大小可以通过max_binlog_size来设置，默认是1GB，最多不能超过4GB。如果写入的bin-log超过设置的最大值的话，bin-log会被拆分。你需要重新写另外一个新的log。旧的bin-log文件不会自动被删除，你需要定期的清理他们，可以使用命令“PURGE BINARY LOGS”，

详细地命令见http://dev.mysql.com/doc/refman/5.1/en/purge-binary-logs.html

复制的基本过程如下：
1)、Slave上面的IO进程连接上Master，并请求从指定日志文件的指定位置（或者从最开始的日志）之后的日志内容；
2)、Master接收到来自Slave的IO进程的请求后，通过负责复制的IO进程根据请求信息读取制定日志指定位置之后的日志信息，返回给Slave 的IO进程。返回信息中除了日志所包含的信息之外，还包括本次返回的信息已经到Master端的bin-log文件的名称以及bin-log的位置；
3)、Slave的IO进程接收到信息后，将接收到的日志内容依次添加到Slave端的relay-log文件的最末端，并将读取到的Master端的 bin-log的文件名和位置记录到master-info文件中，以便在下一次读取的时候能够清楚的告诉Master“我需要从某个bin-log的哪个位置开始往后的日志内容，请发给我”；
4)、Slave的Sql进程检测到relay-log中新增加了内容后，会马上解析relay-log的内容成为在Master端真实执行时候的那些可执行的内容，并在自身执行。

实际上在老版本的MySQL的复制实现在Slave端并不是两个进程完成的，而是由一个进程完成。但是后来发现这样做存在较大的风险和性能问题，主要如下：

      » 继续阅读 [Shasha系列]MySQL Replication(复制)基本原理