过新年,洗键盘

网上淘回来的二手小茶轴键盘,转眼已经用了1年多了..

机械键盘就是好,手感依然没有变化,只是已经脏得不成样子了.

本来想换个HHKB用一下,无奈囊中羞涩..只好继续让这个发光发热了.

新年新气象,给它洗个澡吧

先上一张洗澡前照片:

把所有键帽拔下来,浸到清水里面:

以下是本次清洗大行动的强力武器, 纳米科技海绵,效果真不是盖的..感谢妈妈友情提供,哈哈.

经过一个多小时的搏斗,换水N次(N=1)之后,终于洗干净啦~~

晾干之后就可以装回去啦,在此之前,郑重感谢本人生活秘书老婆大人伸出援助之手,独立承担了清洁键盘主体的工作,希望再接再厉,来年承包整个键盘的清洗,咔咔.

是不是象新的一样? yeah~!

mysql replication 故障处理一则

今早收到报警邮件,来至一台mysql slave

***_db : Slave io may not running.

 

 登陆到那台服务器上查看

mysql> show slave status\G

的确看到

Slave_IO_Running: No

 

不解,遂继续查看mysql slave 的error log

090107 11:57:41 [ERROR] Error reading packet from server: Client requested master to start replication from impossible position ( server_errno=1236)
090107 11:57:41 [ERROR] Got fatal error 1236: 'Client requested master to start replication from impossible position' from master when reading data from binary log
090107 11:57:41 [Note] Slave I/O thread exiting, read up to log '***-bin.000147', position 660737192

 

slave 去读取binary log,但是超出了master 上实际log的大小, 奇怪,我再登陆到master上查看


-rw-rw----  1 mysql mysql  660726317 Jan  7 08:04 ***-bin.000147
-rw-rw----  1 mysql mysql    7791850 Jan  7 08:54 ***-bin.000148
-rw-rw----  1 mysql mysql   19955513 Jan  7 11:59 ***-bin.000149

明白了,***-bin.000147 只有660726317  bytes,但是slave 要读取的是第660737192个byte, 当然失败了.估计是master 曾经出错重启了,丢失了部分的binary log.


接下来是如何处理, 安全可靠的办法当然是重新copy一份master数据到slave上,初始化一遍,从头开始.
在数据完整性要求不是这么强的前提下,可以用另外一个方法.
强制slave读取下一个log文件

mysql> CHANGE MASTER TO MASTER_LOG_FILE = '***-bin.000148' , MASTER_LOG_POS = 0;
mysql> slave start;

 
搞定!