以前一般是两个子集群，在写数据时，两个子集群都写。偶然在网上看到双机互为主从的实现，感到有点意思，于是体验一下，感觉还是不错的，特别是数据量较少时，不失为一种防止单点故障的方案。
第一步授权
主：192.168.237.134
create database abc;
create table cc(id int, name varchar(20),age int);
grant replication slave on *.* to ‘root’@’192.168.237.133’identified by ‘123456’;
flush privileges;

主：192.168.237.133
create database abc;
create table cc(id int, name varchar(20),age int);
grant replication slave on *.* to ‘root’@’192.168.237.134’identified by ‘123456’;
flush privileges;

第二步 my.conf文件配置[mysqld]段：
主：192.168.237.134
server-id= 1
binlog-do-db=abc #多个数据库，可重复添加，如果没有设置，则所有数据库。
binlog-do-db=abc
binlog-ignore-db = mysql
master-host=192.168.237.133
master-user=root
master-password=123456
master-port=3306
master-connect-retry=60
log-bin

主：192.168.237.133
server-id= 2
binlog-ignore-db = mysql
master-host=192.168.237.134
master-user=root
master-password=123456
master-port=3306
master-connect-retry=60
replicate-do-db=abc
binlog-do-db=abc
log-bin

重启阿里云服务器后，发现MySQL启动失败。原因如下：

Starting MySQL…The server quit without updating PID file /alidata/server/mysql/data/AY140620200054865f40Z.pid).[失败]

查找syslog日志，发现以下错误。

“Out of memory: Kill process 9682 (mysqld) score 9 or sacrifice child”

经查资料分析，是内核里的 Out of Memory (OOM) killer主动强制杀死mysql进程，以保护系统因不足内存而崩溃。

经多方资源查找分析，原来是mySQL版本升级为5.6版本后，其默认缓存配置被修改为较大值，故会造成这情况。于是把my.cnf文件增加如下：

performance_schema_max_table_instances 12500  =>修改1250
table_definition_cache 1400 =>修改为140
table_open_cache 2000 =>修改200

贴图如下，重启后问题解决。

最近在使用crontab定时执行一些计划，于是把过程记录下来。

配置crontab的方法有两种：

方法一：crontab –e进行配置，如图。

方法二: vim /etc/crontab进行配置。

 

这两种方法的区别是前者不需要配置执行的用户，即是user-name，而后者需要配置。原因是前者默认是以当前登录的用户权限执行，所以不用配置。后者的配置文件位置是/var/spool/cron/usrname

因为本人是root权限，故本人的配置路径是/var/spool/cron/root。这是CentsOS路径，而在ubuntu曾经搜索过，但仍是找不到明确位置存放个人cron配置，只知道每次使用crontab –e编辑都会新建一个临时文件进行编译，保存后就会消失。

* * * * * python ‘/data/apps/cloudbak_stat/client/net_postdatas_info_perform.py’ >/dev/null 2>&1表示每分钟执行一次。

为什么要使用”>dev/null 2 >&1″呢？因为确使其标准输出和错误输出都重定向到空设备。如果没有正确处理标准输出和错误输出，则命令程序所产生的错误和标准输出会被输出到某文件或某邮件里，默认crontab是输出到管理者邮件中，如果邮件没有被正确处理，会导致邮件文件数量太多，最终拖慢系统。

最后调用：/sbin/service crond restart重启计划

SPDY是谷歌努力推动的一项基于TCP的网页传输协议，目的是压缩、多路复用和优先级来缩短网页的加载时间。这点相对于HTML1.0和1.1协议来说是很具有诱惑力的。也是值得去尝试和体验的。以下是我的编译和测试过程。

1.编译准备

下载nginx1.6.0版：http://nginx.org/download/nginx-1.6.0.tar.gz，为什么是1.6.0呢？因为nginx当前所有版本只有某些版本是明确标识支持SPDY的，而标识的SPDY的版本有1.6.0、1.5.11、1.5.10、1.3.14，而本人也取1.6.2版来测试，确实是只有标识支持SPDY的版本才有SPDY功能。不建议使用1.3.14版本，因为1.3.14版本是使用补丁的方式支持，需要下载patch文件进行修改。

2.编译

可参考官网说明：http://nginx.org/en/docs/http/ngx_http_spdy_module.html

$ ./configure –with-http_ssl_module –with-http_spdy_module

$ make

3.配置文件conf文件。

需要准备server.key和server.crt证书，证书是很麻烦的，按照网上的openssl流程操作，会被搞得晕头转向。我也因为是被搞得晕头转向后，痛定思痛才想到是否有现成的工具可以生成证书。

答案是肯定的，但道路是迂回且曲折，国内没有相关现成工具介绍，也没有什么下载站可以提供下载。只有通过到国外网站去找才可能有，毕竟最大的网络资源在那道”墙”外。

经过谷歌搜索和各条搜索结果排查，找到一个网站：http://www.selfsignedcertificate.com/

Conf文件修改如下：

4.检验结果，

使用谷歌浏览器打开以下地址：chrome://net-internals/#spdy

最近对存储过程那一佗东西，总感到有点不踏实。总感觉容易导致脏数据出现，但又苦于自己是新手，刚开始学数据库，连一个insert语句都写不好，又怎么好去提解决方法呢？

幸好逮到一个机会，有较多时间去验证存储过程的数据安全性问题。

测试例子，随意写的，只说明情况。

CREATE FUNCTION `func_set_top_score`(t_appid INT,t_user_id INT, t_score DOUBLE) RETURNS INT(11)

BEGIN

    DECLARE m_exists_score DOUBLE DEFAULT 0;

    DECLARE m_id BIGINT DEFAULT 0;

    SELECT `score` ,`id` INTO m_exists_score,m_id FROM `user_score` WHERE `appid`=t_appid;

    SLEEP(10);//增加该值，以提升脏数据的几率

    IF m_exists_score <> 0 THEN

        IF m_exists_score < t_score THEN

            UPDATE `user_score` SET `score`=t_score,’id’=user_id WHERE `appid`=t_appid;

        END IF;

    ELSE

        INSERT IGNORE INTO `user_score` (`id`, `score`, `appid `) VALUES (t_user_id, t_score,t_appid);

    END IF;    

    RETURN @errno_success;

END$$

由于多进程的抢夺CPU，会导致某APP存放的分数，不一定是最高分。

解决办法是琐表：lock table和 unlock table;

为了更好的使用该琐表功能，进行以下测试，分别创建A终端和B终端，并连接上相同的数据。

1.A终端上，执行表的读琐，并依次执行insert和update动作。

2.B终端上执行select\insert\update动作。

3.A终端上再执行unlock动作。

4.B终端的数据更新成功。

5.A终端在琐表情况下，能否访问其它表？

读琐总结：

1.所有线程或进程都可以Select该琐定的数据表，但所有线程包括琐表的线程或进程，都不能够更新数据，直到琐表的线程调用unlock tables为止。

2.在lock tables和unlock tables之间，发生的更新操作，都会被挂起且进入阻塞队列，等待解琐和完成操作。

3.在lock tables和unlock tables之间，琐表的线程，不能访问其它表，包括select\update\insert操作。

 

1.表的写琐。

1.A终端发起写琐表，它的select/update/delete/insert操作均正常

2.B终端数据

3.A终端解琐

4.B终端返回数据。

写琐总结：

1.写琐触发后，只有琐表线程可以执行select/update/insert动作，其它线程或进程的所有动作都会被挂起，直到解琐为止。

2.在lock tables和unlock tables之间，琐表的线程，不能访问其它表，包括select\update\insert操作，这点与读琐一致。

 

如果我们要求某些表执行读操作，某些表执行写操作呢？答案是可以的，但写操作只能对写琐的表进行。

 

读写琐是否为递归琐？

答案：不是，连续两次调用lock table的效果是和lock table->unlock table->lock table的效果是一样的，如下。

 

琐表和解琐之间，为什么不能操作其它表？

个人猜测，主要是防止死琐问题，其次是避免操作其它表所造成的无谓性能浪费。

 

在ubuntu14.04版中，调试go程序，有如下出错。

解决办法，依网友操作如下：

查找出加载python的路径。

执行命令：info auto-load python

回到个人根目录：cd ~

在 ~/.gdbinit 加入add选项增加安全路径

把步骤1的runtime-gdb.py路径拷贝到以下，并保存。

或禁用auto-load安全选项，亲测这两项随便一项，都可以使解决上述decline加载问题。

再一次执行刚才的调试命令，那个declined问题，已经解决了，不过新问题也出现了。

步骤4出现的问题，可能是可能是本机装了python3.x，不兼容python2.x的代码。

Locate python3检查如下

Locate python2检查如下：

载 runtime-gdb.py.diff或runtime-gdb.py.diff，解压后patch即可

再重新调试程序，果然那个问题已经解决了。

最近搬迁个人网站，以前个人网站都是丢在国外，现因某同事使用阿里云，用很挺爽的，个人也试用了一下几天，感觉也不错，于是就决定把网站迁回国内。

以前是使用joomla平台架站，现在听人说wordpress很不错，且先天性支持office发博客。

抵挡不住可以用office发博客，这条的诱惑，于是作出了本星期最大的决策：放弃过去，从头架站。

（其实以前网站也维护得很糟糕）

WordPress里使用了谷歌的两个库，一个字体库，一个是ajax库，由于那扇墙的原因，国内打开wordpress站，会很慢的。

360在构建他的CDN时，还是很厚道的，它帮我们做了一个谷歌的代理，我们可以直接使用，但必须作适当的修改。

• 打开360的网站卫士。

http://libs.useso.com/

• 具体修改如下：

1. 在wordpress目录下，执行grep -r ‘googleapis’ ./ -l | xargs sed -i “s/ajax.googleapis.com/ajax.useso.com/g”

2.下载相关google fonts字体插件

3.依照Replace-Google-Fonts.zip内的readme，把插件上传到./wordpress/wp-content/plugins下。

4.在wordpress的插件项中，应该能看到如下图所示。

 

方法一：

find ./ |xargs grep ‘fonts.googleapis.com’

方法二：

grep -r ‘fonts.googleapis.com’ ./

替换搜索到的文件内容。

grep -rl ‘fonts.googleapis.com’ ./ | xargs sed -i “s/fonts.googleapis.com/fonts.useso.com/g”