运用MySQL头条 - 千亿集团

运用MySQL头条

2019-02-11 07:50:20 | 作者: 夜南 | 标签: 运用,问题,效劳 | 浏览: 2327

在着手操作前最好先装置好MySQL-Proxy,并装备好MySQL主从效劳器。弥补:新版MySQL现已内建支撑

推迟问题

读写别离不能逃避的问题之一就是推迟,能够考虑Google供给的SemiSyncReplicationDesign补丁。

端口问题

MySQL-Proxy缺省运用的是4040端口,假如你想通明的把3306端口的恳求转发给4040的话,那么能够:

iptables -t nat -I PREROUTING -s ! 127.0.0.1 -p tcp dport 3306 -j REDIRECT to-ports 4040

假如想删去这条规矩,能够把上面比方中的-I换成-D。

参阅链接

暗码加密办法

MySQL-Proxy不支撑老的暗码加密办法,所以假如你运用的是老版别的MySQL,或许启用了old_passwords选项的话,则或许会呈现过错:

ERROR 2013: Lost connection to MySQL server

此刻最好的修正办法就是运用新的暗码加密办法,假如你的用户表是旧式的,或许需求先运转MySQL源代码里scripts目录下的mysql_fix_privilege_tables脚本晋级表结构。有时分客观状况或许不允许马上进行晋级操作,此刻能够为MySQL-Proxy专门树立一个暗码为空的用户(经过主机约束拜访,或许起一个很杂乱的用户名),由于不管是新的暗码加密办法仍是旧的暗码加密办法,空暗码都同样是一个空字符串,这样就规避了暗码加密的问题。

查询乱码

衔接上MySQL-Proxy后,履行查询时,随机呈现乱码。呈现此问题的原因是当咱们运用MySQL-Proxy读写别离时,一般会有多个后端效劳器,客户端宣布查询恳求时,一般会先宣布一条相似"SET NAME gbk"的句子来声明客户端编码,然后再宣布实践查询的SQL句子,但MySQL-Proxy或许会把这两条句子分发给不同的后端效劳器,于是就呈现了乱码。

解决办法是强行指定后端效劳器的字符编码:

init-connect=SET NAME gbk

default-character-set=gbk
skip-character-set-client-handshake

假如运用init-connect,则需求留意操作用户不能有SUPER权限,否则此选项无效。

即便做好了以上的设置后,还有或许会呈现乱码,比方说数据库是gbk的,当咱们用PHPMyAdmin衔接MySQL-Proxy时,查询仍是会呈现乱码,不过这是正常的!由于PHPMyAdmin运用的是utf8编码,它宣布的“SET NAMES utf8”句子被skip-character-set-client-handshake屏蔽了,所以呈现乱码。

进程溃散

MySQL-Proxy偶然会呈现进程溃散的状况,详细原因不明。

新版的MySQL-Proxy为了敷衍这个问题参加了一个keepalive选项(try to restart the proxy if it crashed),当运用这个选项时,会先后发动两个mysql-proxy进程,先发动的mysql-proxy进程用来监控后发动的mysql-proxy进程,实践供给效劳的是后发动的mysql-proxy进程,一旦后发动的mysql-proxy进程挂掉(你能够自己kill试试),先发动的mysql-proxy进程会从头发动一个mysql-proxy供给效劳。

不过现在许多人用的仍是旧版的MySQL-Proxy,此刻能够运用init来完成相似keepalive的作用:

编写脚本/usr/local/sbin/mysql-proxy.sh,参加以下内容(详细写法视装置状况而定):

LUA_PATH="/usr/local/mysql-proxy/share/mysql-proxy/?.lua" \
/usr/local/mysql-proxy/sbin/mysql-proxy \
proxy-backend-addresses=192.168.0.1:3306 \
proxy-read-only-backend-addresses=192.168.0.2:3306 \
proxy-lua-script=/usr/local/mysql-proxy/share/mysql-proxy/rw-splitting.lua

别忘了加上可履行特点:

chmod a+x /usr/local/sbin/mysql-proxy.sh

0.7.0版别有一个新的选项:defaults-file,能够把相关信息都写到装备文件里:

# MySQL Proxys configuration file (mysql-proxy.cnf)

[mysql-proxy]
daemon = true
keepalive = true
proxy-backend-addresses = 192.168.0.1:3306
proxy-read-only-backend-addresses = 192.168.0.2:3306
proxy-lua-script = /usr/local/mysql-proxy/share/mysql-proxy/rw-splitting.lua

发动时能够运用:mysql-proxy defaults-file=mysql-proxy.cnf

修正inittab:

vi /etc/inittab

参加以下内容:

mp:12345:respawn:/usr/local/sbin/mysql-proxy.sh

然后让init从头读取inittab内容:

kill -HUP 1

体系会主动检测/usr/local/sbin/mysql-proxy.sh是否正在运转,假如没有就主动运转。

需求留意的是在编写mysql-proxy.sh脚本的时分,不要参加daemon选项,否则/usr/local/sbin/mysql-proxy.sh一运转就完毕了,体系会不断的测验运转脚本,从而在/var/log/message里留下许多的过错信息(init: Id "mp" respawning too fast: disabled for 5 minutes)。

init的办法或许显得有点特别了,能够运用其他的东西,比方svscan。

有状况的查询

一些有状况的特别的查询或许失效,比方说:

SELECT SQL_CALC_FOUND_ROWS ..
SELECT FOUND_ROWS()

这种查询是有状况的,应该确保在同一个后端处理,检查rw-splitting.lua脚本能够看到MySQL-Proxy实践上现已对这样的查询进行了 判别,但在实践运用中发现仍是存在问题。估量是脚本写得不咋地,实践运用中,主张我们不要运用这样的查询,一来没有可移植性,而来功率也不见得好。

另一个或许会发生问题的查询是:

INSERT ... (AUTO_INCREMENT)
SELECT LAST_INSERT_ID()

当体系履行完INSERT后,再履行SELECT时,或许现已被分发到了不同的后端效劳器,假如你运用的编程言语是PHP的话,此刻应该经过 mysql_insert_id()来得到最新刺进的id,每次INSERT完毕后,其实对应的autoincrement值就现已计算好回来给PHP 了,你无需再宣布一次独立的查询,直接用mysql_insert_id()就能够了。不过许多PHP程序运用的都是SELECT LAST_INSERT_ID()的办法,如AdbDB,CakePHP等等,假如你正在运用它们的话需多加当心。(当运用bigint 时,mysql_insert_id()存在问题,概况见手册,不过关于大多数人而言,bigint根本不会遇到,所以你能够无视这个问题)

注:关于这两个问题,官方BUG库里有人给出了相应的补丁。

脚本问题

MySQL-Proxy读写别离的功用是经过lua脚本(rw-splitting.lua)完成的,可是这个脚本年久失修,问题多多,比方说运用时或许会呈现:

ERROR 1105: cant change DB to on slave

呈现这个问题的原因在于当客户端宣布查询时,MySQL-Proxy会比较当时客户端所在数据库和效劳器所在数据库是否共同,假如不共同则会在效劳端测验履行一个"USE 数据库"的操作,一个或许性是主从效劳器的数据库结构不同,在USE一个不存在的数据库的时分自然会犯错,还有一个原因有些查询操作并没有所在数据库这个上下文,比方说SHOW DATABASES这个查询,并不需求事前“USE 数据库”,只需连上效劳器就能够履行,这时分假如还测验同步客户端和效劳端所在的数据库,犯错就是无法防止的事了。

rw-splitting.lua恰恰没有屏蔽后者所描绘的状况,修正办法如下,在适宜的方位参加粗体代码,

276  if cmd.type ~= proxy.COM_INIT_DB and
277  c.default_db and c.default_db ~= "" and c.default_db ~= s.default_db then
if is_debug
278  print("  server default db: " .. s.default_db)
279  print("  client default db: " .. c.default_db)
280  print("  syncronizing")
end
281  proxy.queries:prepend(2, string.char(proxy.COM_INIT_DB) .. c.default_db)
282  end

在lua中,~=是不等于的意思,别的,lua里空字符串""用在if里被认为是true,所以单靠c.default_db不行。

随手加上is_debug的判别,否则即便不是debug状况,效劳器的命令行里也会偶然冒出一些调试信息。

此外,新版MySQL-Proxy里,尽管源代码包里有rw-splitting.lua脚本,但缺省并没有装置,你需求手动复制,并且数据结构发生了改变,脚本需求依照数据结构的改变做出恰当的修正,能够参阅作者的描绘操作,或许参阅官方Bug办理或许直接下载。值得等待的是现在有了专门的MySQL-Proxy-Lua-Scripts项目,期望开发进度能跟上来。
版权声明
本文来源于网络,版权归原作者所有,其内容与观点不代表千亿集团立场。转载文章仅为传播更有价值的信息,如采编人员采编有误或者版权原因,请与我们联系,我们核实后立即修改或删除。

猜您喜欢的文章

阅读排行

  • 1

    按要求写sql句子itjob

    句子,学员,课程
  • 2

    检查数据库的SQL快报

    检查,数据库,检查表
  • 3

    DB2 备份和康复huabian

    康复,备份,数据库
  • 4

    运用MySQL头条

    运用,问题,效劳
  • 5
  • 6

    DATA PUMPfenghuang

    简略,指令,数据
  • 7

    Oracle Dimension 下alibaba

    邮编,区域,月度
  • 8

    Oracle失望锁和达观锁ITeyecsdn

    数据,时分,数据库
  • 9

    start with 用法ITeyeitjob

    子句,末梢,树形
  • 10

    mysql 根本指令ITeye头条

    用户,权限,体系