10331人阅读
一、什么是MySQL集群
& &MySQL集群是一个无共享的(shared-nothing)、分布式节点架构的存储方案，其目的是提供容错性和高性能。
& &数据更新使用读已提交隔离级别（read-committedisolation)来保证所有节点数据的一致性，使用两阶段提交机制（two-phasedcommit)保证所有节点都有相同的数据(如果任何一个写操作失败，则更新失败）。
& &无共享的对等节点使得某台服务器上的更新操作在其他服务器上立即可见。传播更新使用一种复杂的通信机制，这一机制专用来提供跨网络的高吞吐量。
& &通过多个MySQL服务器分配负载，从而最大程序地达到高性能，通过在不同位置存储数据保证高可用性和冗余。
二、架构图
三、如何存储数据
1.Mysqlcluster数据节点组内主从同步采用的是同步复制，来保证组内节点数据的一致性。一般通过两阶段提交 协议来实现，一般工作过程如下：
a)Master执行提交语句时，事务被发送到slave，slave开始准备事务的提交。
b)每个slave都要准备事务，然后向master发送OK(或ABORT)消息，表明事务已经准备好（或者无法准备该事务）。
c)Master等待所有Slave发送OK或ABORT消息
&&&&& 如果Master收到所有 Slave的OK消息，它就会向所有Slave发送提交消息，告诉Slave提交该事务；
&&&&& 如果Master收到来自任何一个Slave的ABORT消息，它就向所有 Slave发送ABORT消息，告诉Slave去中止事务。
e)每个Slave等待来自Master的OK或ABORT消息。
&&&&&&&& 如果Slave收到提交请求，它们就会提交事务，并向Master发送事务已提交 的确认；
&&&&&&&& 如果Slave收到取消请求,它们就会撤销所有改变并释放所占有的资源，从而中止事务，然后向Masterv送事务已中止的确认。
f)&&&&& 当Master收到来自所有Slave的确认后，就会报告该事务被提交（或中止），然后继续进行下一个事务处理。
由于同步复制一共需要4次消息传递，故mysql& cluster的数据更新速度比单机mysql要慢。所以mysql cluster要求运行在千兆以上的局域网内，节点可以采用双网卡，节点组之间采用直连方式。
疑问： 对cluster进行扩容增加数据节点组时会不&&&&&& 会导致数据更新速度降低？
答：不会，数据更新速度会变快。因为数据是分别处理，每个节点组所保存的数据是不一样的，
也能减少锁定。
2.Mysqlcluster将所有的索引列都保存在主存中，其他非索引列可以存储在内存中或者通过建立表空间存储到磁盘上。如果数据发生改变(insert,update,delete等)，mysql 集群将发生改变的记录写入重做日志，然后通过检查点定期将数据定入磁盘。由于重做日志是异步提交的，所以故障期间可能有少量事务丢失。为了减少事务丢失，mysql集群实现延迟写入(默认延迟两秒，可配置)，这样就可以在故障发生时完成检查点写入，而不会丢失最后一个检查点。一般单个数据节点故障不会导致任何数据丢失，因为集群内部采用同步数据复制。
四、MySQL集群的横向扩展
1.添加数据节点组来扩展写操作，提高 cluster的存储能力。支持在线扩容，先将新的节点加入到clsuter里，启动后用
ALTER ONLINE TABLE table_name REORGANIZE PARTITION
& 命令进行数据迁移，把数据平均分配到数据节点上。
2.添加Slave仅仅扩展读，而不能做到写操作的横向扩展。
整个系统的平均负载可以描述为：
AverageLoad=∑readload+ ∑writeload / ∑capacity
假设每个服务器每秒有10000的事务量，而Master每秒的写负载为4000个事务，每秒的读负载为6000，结果就是:
AverageLoad=0/%
现在，添加3个slave,每秒的事务量增加到40000。因为写操作也会被复制，每个写操作执行4次，这样每个slave的写负载就是每秒4000个事务。那么现在的平均负载为：
AverageLoad=*00=55%
五、MySQL集群的优缺点
a)& 99.999%的高可用性
b)快速的自动失效切换
c)灵活的分布式体系结构，没有单点故障
d)高吞吐量和低延迟
e)可扩展性强，支持在线扩容
a)存在很多限制，比如：不支持外键
b)部署、管理、配置很复杂
c)占用磁盘空间大，内存大
d)备份和恢复不方便
e)重启的时候，数据节点将数据load到内存需要很长时间
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：261463次
积分：1929
积分：1929
排名：第16083名
原创：22篇
转载：44篇
评论：21条
(1)(4)(1)(1)(1)(1)(1)(2)(2)(5)(1)(2)(1)(1)(3)(1)(3)(1)(5)(1)(1)(2)(7)(4)(1)(10)(3)jxwpx 的BLOG
用户名：jxwpx
文章数：351
评论数：344
访问量：310699
注册日期：
阅读量：5863
阅读量：12276
阅读量：369606
阅读量：1064226
51CTO推荐博文
有些需要参照别人，一起研究啊，前几天跟一个大牛聊天，说是使用了200多台的多主MYSQL集群，羡慕，嘿嘿。
(多主一从，一主多从，多主多从，一主一从)
MYsqL集群想做个多主或多从的专题研究，总结在这里。
&二台Mysql服务器，他们的IP地址分别为：
A：192.168.0.97
B：192.168.0.98
数据库都是 test_3306
首先我给两台服务器的my.ini 贴出来
server-id=2
master-host=192.168.0.98
master-user=mydb
master-password=123
master-port=3306
master-connect-retry=1
replicate-do-db=tbqu
log-slave-updates
binlog-ignore-db=mysql
slave-skip-errors=all
server-id=1
master-host=192.168.0.97
master-user=mydb
master-password=123
master-port=3306
master-connect-retry=1
replicate-do-db=tbqu
log-slave-updates
binlog-ignore-db=mysql
slave-skip-errors=all
在这里，配置文件和主从配置方法基本上一样
log-slave-updates 这个参数一定要加上，否则不会给更新的记录些到二进制文件里
slave-skip-errors 是跳过错误，继续执行复制操作
多主互备和主从复制有一些区别，因为多主中 都可以对服务器有写权限，所以设计到自增长重复问题
出现的问题（多主自增长ID重复）
1:首先我们通过A,B的test表结构
2:掉A，在B上对数据表test(存在自增长ID)执行插入操作，返回插入ID为1
3:后停掉B，在A上对数据表test(存在自增长ID)执行插入操作，返回的插入ID也是1
4:然后 我们同时启动A,B，就会出现主键ID重复
解决方法：
我们只要保证两台服务器上插入的自增长数据不同就可以了
如：A查奇数ID，B插偶数ID，当然如果服务器多的话，你可以定义算法，只要不同就可以了
在这里我们在A,B上加入参数，以实现奇偶插入
A：my.ini上加入参数
auto_increment_offset = 1
auto_increment_increment = 2
这样A的auto_increment字段产生的数值是：1, 3, 5, 7, &等奇数ID了
B：my.ini上加入参数
auto_increment_offset = 2
auto_increment_increment = 2
这样B的auto_increment字段产生的数值是：2, 4, 6, 8, &等偶数ID了
可以看出，你的auto_increment字段在不同的服务器之间绝对不会重复，所以Master-Master结构就没有任何问题了。当然，你还可以使用3台，4台，或者N台服务器，只要保证auto_increment_increment = N 再设置一下auto_increment_offset为适当的初始值就可以了，那样，我们的MySQL可以同时有几十台主服务器，而不会出现自增长ID重复。
在这里我们说的是2台MYSQL服务器，你也可以扩展到多台，实现方法类似
A -& B -& C-& D -&A
这样一个环形的备份结构就形成了，最后可要记住 自增长ID（主键）要设计好哦，否则会出错的。
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
假定有三台Mysql服务器，他们的IP地址分别为：
192.168.1.8
192.168.1.88
192.168.1.188
在192.168.1.8的安装目录下找到my.ini文件，在该文件的最后加上：
server-id=1
#asyntest1是我用来试验的数据库名称，到时候要换成你的数据库名字
binlog-do-db=asyntest1
#下面这句话很重要，只有加上它，从前一台机器上同步过来的数据才能同步到下一台机器
log-slave-updates
master-host=192.168.1.188
master-user=root
#在此处填入192.168.1.188的root密码
master-password=XXXXX
#asyntest1是我用来试验的数据库名称，到时候要换成你的数据库名字
replicate-do-db=asyntest1
master-connect-retry=10
#出现错误后忽略，如果不加这个，出现任何错误，同步进程会终止
slave-skip-errors=all
在192.168.1.88的安装目录下找到my.ini文件，在该文件的最后加上：
server-id=2
#asyntest1是我用来试验的数据库名称，到时候要换成你的数据库名字
binlog-do-db=asyntest1
#下面这句话很重要，只有加上它，从前一台机器上同步过来的数据才能同步到下一台机器
log-slave-updates
master-host=192.168.1.8
master-user=root
#在此处填入192.168.1.8的root密码
master-password=XXXXX
#asyntest1是我用来试验的数据库名称，到时候要换成你的数据库名字
replicate-do-db=asyntest1
master-connect-retry=10
#出现错误后忽略，如果不加这个，出现任何错误，同步进程会终止
slave-skip-errors=all
在192.168.1.188的安装目录下找到my.ini文件，在该文件的最后加上：
server-id=3
#asyntest1是我用来试验的数据库名称，到时候要换成你的数据库名字
binlog-do-db=asyntest1
#下面这句话很重要，只有加上它，从前一台机器上同步过来的数据才能同步到下一台机器
log-slave-updates
master-host=192.168.1.88
master-user=root
#在此处填入192.168.1.88的root密码
master-password=XXXXX
#asyntest1是我用来试验的数据库名称，到时候要换成你的数据库名字
replicate-do-db=asyntest1
master-connect-retry=10
#出现错误后忽略，如果不加这个，出现任何错误，同步进程会终止
slave-skip-errors=all
在192.168.1.8, 192.168.1.88, 192.168.1.188上建立完全一样的数据库asyntest1,重启这三台数据库，然后在任何一台机器上进行的更新操作，都会同步到另外的两台机器上，这是一种环形同步，在192.168.1.8有任何修改，会首先同步到192.168.1.88的机器上，88的机器再将同步的数据同步到 192.168.1.188的机器上。同样，如果在192.168.1.88上有任何更新，首先会同步到192.168.1.188的机器上，然后再同步到192.168.1.8的机器上；而在192.168.1.188的机器上有任何更新，首先会同步到192.168.1.8的机器上，然后在同步到 192.168.1.88的机器上。利用这种原理，可以解决任意多台机器的互相同步问题。
如果出现问题，首先请在每一台服务器上用命令行通过telnet命令检查其他机器3306端口的连通情况。另外，请检查各机器的防火墙设置和杀毒软件的配置。可将这些软件暂停后进行试验。
&本文出自 “” 博客，请务必保留此出处
了这篇文章
类别：┆阅读(0)┆评论(0)
19:00:16 20:21:58 09:44:54 13:20:13 18:13:37 17:17:17 &&1&
&&页数 ( 1/2 ) &分布式 MySQL 集群方案，看看京东是怎么做的
开发者头条
中间代理方案开发难度上来说门槛会更高一点，需要考虑前后端的东西，尤其是与MySQL端交互时自己解析协议的情况下会更复杂一些。中间代理方案多走一段TCP，对性能理论上会有一些影响。上述两种方案有一个非常重要的因素没有提及，在实际生产环境中面临一个非常现实的问题是MySQL能支持的连接数是有限的。以MySQL5.5来说假设一个MySQL实例配置1000个连接，业务应用实例部署了100个，每个应用实例的数据库连接池配置20个，采用客户端方案这个MySQL实例都没法正常工作了。大多数情况下并不是每个应用实例的每条连接都是活跃的，中间代理的方案可以很好的解决这个问题，应用实例可以有很多连接打到代理上，代理只需要维护较少的与MySQL的连接即可满足需求，代理与MySQL之间的连接会被业务打过来的访问重复使用。另外关于多走一次TCP对性能的影响，从我们的实际经验来看其实可以忽略不计，业务实例一多优先遇到的是MySQL连接数的问题，从这个角度来说中间代理的方案会更优。我们采用的就是中间代理的方案，京东的分布式MySQL方案由很多部分组成，有JManager、 JProxy、 JTransfer、JMonitor、JConsole、MySQL，在实际部署的时候还涉及到LVS以及域名系统等。JManager是中心管理节点，这个节点负责统一管理系统的元信息，元信息包括路由信息、权限管理信息、资源相关的信息等。
Ctrl+D&将本页面保存为书签，全面了解最新资讯，方便快捷。> JavaOlder的博客详情
使用mysql-proxy 快速实现mysql 集群 读写分离
目前较为常见的mysql读写分离分为两种：
基于程序代码内部实现：在代码中对select操作分发到从库；其它操作由主库执行；这类方法也是目前生产环境应用最广泛，知名的如DISCUZ
X2。优点是性能较好，因为在程序代码中实现，不需要增加额外的设备作为硬件开支。缺点是需要开发人员来实现，运维人员无从下手。&
2、 基于中间代理层实现：我们都知道代理一般是位于客户端和服务器之间，代理服务器接到客户端请求后通过判断然后转发到后端数据库。在这有两个代表性程序
mysql-proxy：mysql-proxy为mysql开源项目，通过其自带的lua脚本进行sql判断，虽然是mysql官方产品，但是mysql官方并不建议将mysql-proxy用到生产环境。&
amoeba：由陈思儒开发，作者曾就职于阿里巴巴，现就职于盛大。该程序由java语言进行开发，目前只听说阿里巴巴将其用于生产环境。另外，此项目严重缺少维护和推广（作者有个官方博客，很多用户反馈的问题发现作者不理睬）
经过上述简单的比较，通过程序代码实现mysql读写分离自然是一个不错的选择。但是并不是所有的应用都适合在程序代码中实现读写分离，像大型SNS、B2C这类应用可以在代码中实现，因为这样对程序代码本身改动较小；像一些大型复杂的java应用，这种类型的应用在代码中实现对代码改动就较大了。所以，像这种应用一般就会考虑使用代理层来实现。
下面我们看一下如何搭建mysql-proxy来实现mysql读写分离
环境拓扑如下：
关于mysql、mysql主从的搭建，在此不再演示，如下的操作均在mysql-proxy（192.168.1.200）服务器进行
一、安装mysql-proxy
1、安装lua& (mysql-proxy需要使用lua脚本进行数据转发)
lua-5.1.4.tar.gz
#cd lua-5.1.4
#vi Makefile，修改INSTALL_TOP=
/usr/local/lua
#make posix
#make install
2、安装libevent
zxvf libevent-2.0.8-rc.tar.gz
#cd libevent-2.0.8-rc
#./configure
--prefix=/usr/local/libevent
#make && make install
3、安装check
#tar zxvf check-0.9.8.tar.gz
#cd check-0.9.8
#./configure && make && make install
4、安装mysql客户端
#tar zxvf mysql-5.0.92.tar.gz
#cd mysql-5.0.92
#./configure
--without-server && make && make install
5、设置环境变量
（安装mysql-proxy所需变量）
#vi /etc/profile
LUA_CFLAGS="-I/usr/local/lua/include" LUA_LIBS="-L/usr/local/lua/lib -llua -ldl"
LDFLAGS="-L/usr/local/libevent/lib -lm"
CPPFLAGS="-I/usr/local/libevent/include"
CFLAGS="-I/usr/local/libevent/include"
# source /etc/profile
6、安装mysql-proxy
#tar zxvf mysql-proxy-0.6.0.tar.gz
mysql-proxy-0.6.0
# ./configure --prefix=/usr/local/mysql-proxy --with-mysql
--with-lua
#make && make install
7、启动mysql-proxy
本次对两台数据库实现了读写分离；mysql-master为可读可写，mysql-slave为只读
#/usr/local/mysql-proxy/sbin/mysql-proxy
--proxy-backend-addresses=192.168.1.201:3306
--proxy-read-only-backend-addresses=192.168.1.202:3306
--proxy-lua-script=/usr/local/mysql-proxy/share/mysql-proxy/rw-splitting.lua
注：如果正常情况下启动后终端不会有任何提示信息，mysql-proxy启动后会启动两个端口，4040用于SQL转发，4041用于管理mysql-proxy。如有多个mysql-slave可以依次在后面添加
1、连接测试
因为默认情况下mysql数据库不允许用户在远程连接
mysql&grant
all privileges on *.* to identified by '123456';
客户端连接
#mysql -uroot -p123456 -h192.168.1.200 -P4040
2、读写分离测试
为了测试出mysql读写分离的真实性，在测试之前，需要开启两台mysql的log功能，然后在mysql-slave服务器停止复制
① 在两台mysql配置文件my.cnf中加入log=query.log，然后重启
②在mysql-slave上执行SQL语句stop slave
③在两台mysql上执行#tail -f /usr/local/mysql/var/query.log
④在客户端上连接mysql（三个连接以上），然后执行create、select等SQL语句，观察两台mysql的日志有何变化 注：生产环境中除了进行程序调试外，其它不要开启mysql查询日志，因为查询日志记录了客户端的所有语句，频繁的IO操作将会导致mysql整体性能下降
总结：在上述环境中，mysql-proxy和mysql-master、mysql-slave三台服务器均存在单点故障。如果在可用性要求较高的场合，单点隐患是绝对不允许的。为了避免mysql-proxy单点隐患有两种方法，一种方法是mysql-proxy配合keepalived做双机，另一种方法是将mysql-proxy和应用服务安装到同一台服务器上；为了避免mysql-master单点故障可以使用DRBD+heartbear做双机；避免mysql-slave单点故障增加多台mysql-slave即可，因为mysql-proxy会自动屏蔽后端发生故障的mysql-slave。
附: mysql-proxy LUA 读写分离脚本代码:
--[[ -- -- author : KDr2
-- version 0.01 -- SYNOPSIS: ---&
1.维护了一个连接池 ---& 2.读写分离，简单的将select开头的语句放到slave上执行 ---&
3.事务支持，所有事务放到master上执行，事务中不更改连接 ---& 4.简单日志 -- --]]
--- config vars local min_idle_connections = 4 local
max_idle_connections = 8 local log_level=1 local encoding="utf8" ---
end of config
-- 事务标识，在事务内不归还连接 local
transaction_flags={} setmetatable(transaction_flags,{__index=function()
return 0 end})
-- log system log={ && level={debug=1,info=2,warn=3,error=4}, &&
funcs={"debug","info","warn","error"}, } function log.log(level,m) &&
if level &= log_level then &&&&& local msg="[" .. os.date("%Y-%m-%d %X")
.."] ".. log.funcs[level] .. ": " .. tostring(m) &&&&& print(msg) -- TODO&
write msg into a log file. && end end for i,v in ipairs(log.funcs)
do && log[v]=function(m) log.log(log.level[v],m) end end
-- connect to server function connect_server()
&& (" starting
connect_server ... ") && local least_idle_conns_ndx = 0 && local
least_idle_conns = 0 &&
&& for i = 1, #proxy.backends do &&&&& local s
= proxy.backends[i] &&&&& local pool = s.pool
&&&&& local cur_idle =
pool.users[""].cur_idle_connections
&&&&& log.debug("[".. s.address .."].connected_clients = " ..
s.connected_clients) &&&&& log.debug("[".. s.address .."].idling_connections
= " .. cur_idle) &&&&& log.debug("[".. s.address .."].type = " ..
s.type) &&&&& log.debug("[".. s.address .."].state = " .. s.state)
&&&&& if s.state ~= proxy.BACKEND_STATE_DOWN then &&&&&&&& -- try to
connect to each backend once at least &&&&&&&& if cur_idle == 0
then &&&&&&&&&&& proxy.connection.backend_ndx = i &&&&&&&&&&&
("server [".. proxy.backends[i].address .."] open new
connection") &&&&&&&&&&& return &&&&&&&& end &&&&&&&& -- try to open at
least min_idle_connections &&&&&&&& if least_idle_conns_ndx == 0
or &&&&&&&&&&& ( cur_idle & min_idle_connections and
&&&&&&&&&&&&&
cur_idle & least_idle_conns ) then &&&&&&&&&&& least_idle_conns_ndx =
i &&&&&&&&&&& least_idle_conns = cur_idle &&&&&&&& end &&&&& end &&
&& if least_idle_conns_ndx & 0 then &&&&& proxy.connection.backend_ndx
= least_idle_conns_ndx && end &&
&& if proxy.connection.backend_ndx
&&&&& local s =
proxy.backends[proxy.connection.backend_ndx] &&&&& local pool = s.pool
&&&&& local cur_idle = pool.users[""].cur_idle_connections
&&&&& if cur_idle &= min_idle_connections then &&&&&&&& -- we have 4
idling connections in the pool, that's good enough &&&&&&&& log.debug("using
pooled connection from: " .. proxy.connection.backend_ndx) &&&&&&&& return
proxy.PROXY_IGNORE_RESULT &&&&& end && end && -- open a new connection
&& ("opening new connection on: " ..
proxy.backends[proxy.connection.backend_ndx].address) end
-- auth.packet is the packet function read_auth_result( auth ) && if
auth.packet:byte() == proxy.MYSQLD_PACKET_OK then &&&&& -- 连接正常 &&&&&
proxy.connection.backend_ndx = 0 && elseif auth.packet:byte() ==
proxy.MYSQLD_PACKET_EOF then &&&&& -- we received either a
&&&&& -- *
MYSQLD_PACKET_ERR and the auth failed or &&&&& -- * MYSQLD_PACKET_EOF which
means a OLD PASSWORD (4.0) was sent &&&&& log.error("(read_auth_result) ...
not ok yet"); && elseif auth.packet:byte() == proxy.MYSQLD_PACKET_ERR
then &&&&& log.error("auth failed!") && end end
-- read/write splitting function read_query( packet )
log.debug("[read_query]") && log.debug("authed backend = " ..
proxy.connection.backend_ndx) && log.debug("used db = " ..
proxy.connection.client.default_db)
&& if packet:byte() == _QUIT then &&&&& proxy.response =
{ &&&&&&&& type = proxy.MYSQLD_PACKET_OK, &&&&& } &&&&& return
proxy.PROXY_SEND_RESULT && end
&& if proxy.connection.backend_ndx == 0 then &&&&& local
is_read=(string.upper(packet:sub(2))):match("^SELECT") &&&&& local
target_type=proxy.BACKEND_TYPE_RW &&&&& if is_read then
target_type=proxy.BACKEND_TYPE_RO end &&&&& for i = 1, #proxy.backends
do &&&&&&&& local s = proxy.backends[i] &&&&&&&& local pool = s.pool
&&&&&&&& local cur_idle =
pool.users[proxy.connection.client.username].cur_idle_connections &&&&&&&&
&&&&&&&& if cur_idle & 0 and
&&&&&&&&&&& s.state ~=
proxy.BACKEND_STATE_DOWN and
&&&&&&&&&&& s.type == target_type
then &&&&&&&&&&& proxy.connection.backend_ndx = i &&&&&&&&&&&
break &&&&&&&& end &&&&& end && end && -- sync the client-side
default_db with the server-side default_db && if proxy.connection.server and
proxy.connection.client.default_db ~= proxy.connection.server.default_db
then &&&&& local server_db=proxy.connection.server.default_db &&&&& local
client_db=proxy.connection.client.default_db &&&&& local default_db=
(#client_db & 0) and client_db or server_db &&&&& if #default_db & 0
then &&&&&&&& proxy.queries:append(2, string._INIT_DB) ..
default_db) &&&&&&&& proxy.queries:append(2, string._QUERY) ..
"set names '" .. encoding .."'") &&&&&&&& ("change database to " ..
default_db); &&&&& end && end && if proxy.connection.backend_ndx & 0
then &&&&& log.debug("Query[" .. packet:sub(2) .. "] Target is [" ..
proxy.backends[proxy.connection.backend_ndx].address .."]") && end &&
proxy.queries:append(1, packet) && return proxy.PROXY_SEND_QUERY end
--- -- as long as we are in a transaction keep the connection --
otherwise release it so another client can use it function read_query_result(
&& local res&&&&& = assert(inj.resultset) && local flags&&& =
&& if inj.id ~= 1 then &&&&& -- ignore the result of the USE
&default_db& &&&&& return proxy.PROXY_IGNORE_RESULT && end &&
is_in_transaction = flags.in_trans
&& if flags.in_trans then &&&&&
transaction_flags[proxy.connection.server.thread_id] =
transaction_flags[proxy.connection.server.thread_id] + 1 && elseif
inj.query:sub(2):lower():match("^%s*commit%s*$") or
inj.query:sub(2):lower():match("^%s*rollback%s*$") then &&&&&
transaction_flags[proxy.connection.server.thread_id] =
transaction_flags[proxy.connection.server.thread_id] - 1 &&&&& if
transaction_flags[proxy.connection.server.thread_id] & 0 then
transaction_flags[proxy.connection.server.thread_id] = 0 end && end &&
&& log.debug("transaction res : " ..
tostring(transaction_flags[proxy.connection.server.thread_id])); && if
transaction_flags[proxy.connection.server.thread_id]==0 or
transaction_flags[proxy.connection.server.thread_id] == nil then
isnot in a transaction, need to release the backend &&&&&
proxy.connection.backend_ndx = 0 && end end
-- close the connections if we have enough connections in the
pool -- --
nil - close connection
-- IGNORE_RESULT - store
connection in the pool function disconnect_client() &&
log.debug("[disconnect_client]") && if proxy.connection.backend_ndx == 0
then &&&&& for i = 1, #proxy.backends do &&&&&&&& local s =
proxy.backends[i] &&&&&&&& local pool = s.pool
&&&&&&&& local cur_idle =
pool.users[proxy.connection.client.username].cur_idle_connections &&&&&&&&
&&&&&&&& if s.state ~= proxy.BACKEND_STATE_DOWN and &&&&&&&&&&& cur_idle
& max_idle_connections then &&&&&&&&&&& -- try to disconnect a
backend &&&&&&&&&&& proxy.connection.backend_ndx = i &&&&&&&&&&&
("[".. proxy.backends[i].address .."] closing connection, idling: " ..
cur_idle) &&&&&&&&&&& return &&&&&&&& end &&&&& end &&&&& return
proxy.PROXY_IGNORE_RESULT && end end
人打赏支持
码字总数 39398
你那边有具体的需求？
你那边有具体的需求？目前生产上用的是mmm_mysql，mysql proxy还没试过，不过看网上些资料，貌似mysql proxy还不成熟~~~~
你那边有具体的需求？mmm_mysql感觉也不咋靠谱，发现状态老变来变去~~~
你那边有具体的需求？目前生产上用的是mmm_mysql，mysql proxy还没试过，不过看网上些资料，貌似mysql proxy还不成熟~~~~你说的对，这个还不太成熟。mmm_mysql我有一篇博文介绍到了。你可以对比一下
支付宝支付
微信扫码支付
打赏金额: ￥
已支付成功
打赏金额: ￥
& 开源中国(OSChina.NET) |
开源中国社区(OSChina.net)是工信部
指定的官方社区