MYSQL管理之主从同步管理

MYSQL主从同步架构是目前使用最多的数据库架构之一,尤其是负载比较大的网站,因此对于主从同步的管理也就显得非常重要,新手往往在出现主从同步错误的时候不知道如何入手,这篇文章就是根据自己的经验来详细叙述mysql主从的管理。 MYSQL主从同步的作用 (1) 数据分布 (2) 负载平衡(load balancing) (3) 备份 (4) 高可用性(high availability)和容错

MySQL主从复制性能优化

MySQL的主从复制的基本原理是从库连接到主库,主库生成一个主库DUMP线程,该DUMP线程的主要任务是 一直挖掘binlog日志,然后发送到从库的IO线程,IO线程接收到日志流后,写入relay log,另一个线 程SQL线程,会读取该relay log内容,然后对sql语句进行重放. 主库DUMP线程会根据从库传来的文件位置信息去读取binlog文件中的内容,DUMP线程并不是每隔一段时间去 读取的,而且在主库上当有写binlog日志时,会产生同步,那么DUMP线程根据同步机制会立即去读取binlog 文件.当主库去写binlog时,DUMP线程去读,问题很快来了,这样的情形可能会产生读写冲突,有时候我们 也把这种情况称为”IO抖动”,如果我们的服务器配置了RAID的cache,或是使用文件系统的cache,当一个写操 作的时候,可能并不会真正的写到磁盘上去,而是写到cache中去了,这样再次去读的话,直接从cache中 读取就可以了. 如果主库有多个从库,DUMP线程和服务器的写binlog线程,DUMP线程和DUMP线程之间读写争用会更加频 繁,如果使用了SSD存储,这种情况可以得到好的的缓解. 当DUMP线程接收到同步事件后,开始执行DUMP操作,这时候在主库上不应该存在CPU负载过高,而使DUMP线程在 运行队列中等待时间过长. 对于需要binlog复制的库,我们在主库使用binlog_do_db,而避免对所有的库操作都生成binlog。不过我 在使用这个参数的时候需要小心测试,因为有些应用写库的方式可能会导致binlog数据丢失. 主库DUMP线程通过网络发送给从库的IO线程,DUMP线程本身不提供压缩功能,所以这时候足够的带宽变得很重 要,特别是对于跨公网的传输,另外可以通过在网络层面上使用网络设备自带的压缩的功能来弥补这方面的不足. 当IO线程接收到binlog后,往relay log里面写数据,存储本身的速度和在每次接收后是否立即同步到磁盘上 的相关参数对IO线程处理的速度变得极为重要.比如sync_relay_log,sync_master_info 和sync_relay_log_info三个参数, 具体的值可能要视环境而做出调整。比如sync_relay_log设置为0,每次接收到数据后不直接写磁盘,而依赖OS去刷新到磁盘上. SQL线程的原理和DUMP线程的原理很类似,当有relay log日志写入时会产生同步,那么SQL线程就会去读取其中的数据进行 重放。在MySQL 5.6中很重要的一个提升就是可以多个SQL线程可以同时工作,这样增加了吞吐量.可以设置slave_parallel_workers 来达到这样目的.从库上的其他参数比如innodb_flush_log_at_trx等,虽会加快sql线程的吞吐量,但是可能需要缩合考虑 而不仅仅是针对SQL线程.

addslashes与mysql_real_escape_string的区别

addslashes和mysql_real_escape_string.都是为了使数据安全的插入到数据库中而进行过滤.那么这两个函数到底是有什么区别呢?? 我们今天来简单的看下.. 首先.我们还是从PHP手册入手.. 手册上addslashes转义的字符是单引号(’)、双引号(”)、反斜线(\)与NUL(NULL 字符)。 mysql_real_escape_string转义的字符并没有被提到.只是说了一句 注意: mysql_real_escape_string() 并不转义% 和_。 为什么PHP手册没有说呢?因为其实这是个MySql的C的API.所以我们需要查下MySql手册..上面是这么说的. 编 码的字符为NUL (ASCII 0)、’\n’、’\r’、’\’、”’、’”‘、以及Control-Z(请参见9.1节,“文字值”)。(严格地讲,MySQL仅需要反斜杠和引号 字符,用于引用转义查询中的字符串。该函数能引用其他字符,从而使得它们在日志文件中具有更好的可读性)。 不得不说一句.MySql手册上面的话总是令人费解的.. 我们为了更深层次的探究这两个函数的不同..还是去看一看PHP的源码吧.. 这是PHP的addslashes函数.. PHP_FUNCTION(addslashes) { zval **str; if (ZEND_NUM_ARGS() != 1 || zend_get_parameters_ex(1, &str) == FAILURE) { WRONG_PARAM_COUNT; } convert_to_string_ex(str); if (Z_STRLEN_PP(str) == 0) { RETURN_EMPTY_STRING(); } RETURN_STRING(php_addslashes(Z_STRVAL_PP(str), Z_STRLEN_PP(str), &Z_STRLEN_P(return_value), 0 TSRMLS_CC), 0); } 很显然.它调用了php_addslashes.我们继续看这个函数

你想建设一个能承受500万PV/每天的网站吗?

你想建设一个能承受500万PV/每天的网站吗? 500万PV是什么概念?我的服务器每秒要处理多少个请求也能应对?如果计算呢? PV是什么: PV是page view的简写。PV是指页面的访问次数,每打开或刷新一次页面,就算做一个pv。 计算模型: 每台服务器每秒处理请求的数量=((80%*总PV量)/(24小时*60分*60秒*40%))/服务器数量 其中关键的参数是80%、40%。表示一天中有80%的请求发生在一天的40%的时间内。24小时的40%是9.6小时,有80%的请求发生一天的9.6个小时当中(很适合互联网的应用,天的请求多,晚上请求少)。   简单计算结果: ((80%*500万)/(24小时*60分*60秒*40%))/1 = 115.7个请求/秒 ((80%*100万)/(24小时*60分*60秒*40%))/1 = 23.1个请求/秒 初步结论: 现在我们在做压力测试时,就有了标准,如果你的服务器一秒能处理115.7个请求,就可以承受500万PV/每天。如果你的服务器一秒能处理23.1个请求,就可以承受100万PV/每天。(这里不关心是请求的是静态的html,还是动态的jsp,一般认为会执行业务逻辑)   留足余量: 以上请求数量是均匀的分布在白天的9.6个小时中,但实际情况并不会这么均匀的分布,会有高峰有低谷。为了应对高峰时段最少也要x2倍,x3倍也不为过,应该留一些余地。 115.7个请求/秒 *2倍=231.4个请求/秒 115.7个请求/秒 *3倍=347.1个请求/秒 23.1个请求/秒 *2倍=46.2个请求/秒 23.1个请求/秒 *3倍=69.3个请求/秒   最终结论: 如果你的服务器一秒能处理231.4–347.1个请求/秒,就可以承受500万PV/每天。 如果你的服务器一秒能处理46.2–69.3个请求,就可以承受100万PV/每天。

关于php的libevent扩展的应用

php有个libevent扩展,在一年前我曾经拿它实现了一个thrift socket server,虽然我没有把它放在正式的场合来使用,但是我觉得这个扩展应该可以有更广泛的用途,比如: phpDaemon — 一个异步的服务器端开发框架. tail – 用php实现类似unix下的tail命令行 ZeroMQ + libevent in PHP – 用php和ZeroMQ实现的一个事件驱动服务器端 我所想到的一个比较实用的使用场景是,在页面中利用libevent请求多个http接口来获得数据。若是在从前,一个可行的办法是利用 curl_multi_exec来同时请求好几个接口,但是这个办法需要用一个do … while循环来完成请求,很是坑爹。那么看看采用libevent的例子: