Auth: Jin
1.session问题
Date: 20140328
问题描述：
基于openx 的广告系统，将数据从单点，迁移到mmm集群，前端无法访问
报错信息如下：
MDB2 Error: Array
_doQuery: [Error message: Could not execute statement]
[Last executed query: EXECUTE MDB2_STATEMENT_mysql_231aaea2d6a8cace7c73797d81dc6ea8 USING @0]
[Native code: 1243]
[Native message: Unknown prepared statement handler (MDB2_STATEMENT_mysql_231aaea2d6a8cace7c73797d81dc6ea8) given to EXECUTE]
: Could not execute statement]
/data/httpd/htdocs/ad/var/debug.log:[Last executed query: EXECUTE MDB2_STATEMENT_mysql_a0846690c52c0e64d42b7421fcd3e983 USING @0]
/data/httpd/htdocs/ad/var/debug.log:[Native message: Unknown prepared statement handler (MDB2_STATEMENT_mysql_a0846690c52c0e64d42b7421fcd3e983) given to EXECUTE]
/data/httpd/htdocs/ad/var/debug.log:Mar 28 04:29:16 +0000 OX [ error] PEAR :: MDB2 Error: Array : _doQuery: [Error message: Could not execute statement]
解决步骤
1、配置指向原来的单点正常
2、配置指向mmm的master正常
3、判断为通过proxy产生问题
最开始根据报错提示以为是权限问题，全部权限添加确认一次，还一样
根据报错里面那么串字符，感觉是session
/data/httpd/htdocs/ad/lib/pear/MDB2.php
原因：session之能保持到一个ip,无法在多台MYSQL实例之间切换
解决方案：
数据库配置指向mmm的writer vip
2.charset问题
Date: 20140402
问题描述：
线上有一个废弃的mysql实例，昨天停掉了，后开发说虽然前端停掉了，程序中有部分代码用到这个实例中的数据。
dump导出，然后导入mmm,后前端发现是乱码，查看php.conf字符集是latin1，检查mmm中创建表的也是latin1。
原来实例的环境是utf8,表结构CHARSET=latin1，数据是latin1,dump默认是utf8.原来以为没有修改数据，创建表的字符集是latin1，插入的数据就是latin1.
解决步骤：
dump --default-character-set
操作
# mysqldump --default-character-set=latin1 -h 192.168.201.102 -P3308 -udbproxy -ppasswd vcity > ./vcity.sql
# head -n 10 vcity-mmm_20140402.sql |tail -1
/*!40101 SET NAMES latin1 */;
mysql -h127.0.0.1 -P3307 -uroot
SET NAMES latin1
mysql> create vcity;
mysql> use vcity;
mysql> source ./vcity.sql
还是乱码
换个方法导入,导出没问题了
默认为--opt,包含--set-charset=default-character-set,即有/*!40101 SET NAMES latin1 */;
mysql -h127.0.0.1 -P3307 -uroot -ppasswd --default-character-set=latin1 -f vcity <./vcity.sql
-f, --force Continue even if we get an SQL error.
依然是乱码
检查连接方式将mysql-proxy换成连接vip,发现正常了
原因:
proxy字符集问题
proxy-lua-script=/usr/local/mysql-proxy/share/doc/mysql-proxy/rw-splitting-utf8-sync.lua
解决方案：
数据库配置指向mmm的writer vip
总结：
使用mysql-proxy的架构（M-S/NDB）中要注意session，charset的影响。
出现问题的时候按一下步骤排除
1.注意报错信息，最好可以根据报错信息知道问题所在
2.直接将数据库配置指向master（单台）,观察情况
3.将数据库配置指向write vip (单台)
4.对比
5.在单台的情况再去具体mysql属性