atlas聊天记录记载

文洪 10:56:20

亲,咱们这个是不是主写也会读?

朱超@360 10:56:43

事务内和锁内的读会打向主库

文洪 10:57:27

select 也指向了主。

朱超@360 10:57:51

1.min-idle-connections

(1)Atlas为每台DB建立一个连接池。

(2)当有客户端连接Atlas时,Atlas会先在第一台DB上建立连接,直到主库连接池内的

空闲连接数达到min-idle-connections,再在下一台DB上建立连接,直到所有DB连接池内的空闲连接数都达到min-idle-connections,便不再建立新连接,而开始复用连接池内的连接。

(3)Atlas启动时,配置里的所有DB会按照主库在前从库在后的顺序在内存里排好次序,所以初始阶段会先在主库上建立连接。

(4)Atlas在运行过程中,某连接如果触发了DB的wait_timeout,Atlas会把该连接销毁,如果因此而导致连接池内的空闲连接数低于min-idle-connections,Atlas将在客户端下一次连接时重新在该DB上建立连接。

(5)以上策略是因为在客户端与MySQL的交互过程中,connect和query是两个独立的阶段,在connect阶段Atlas需要决定在哪台DB上建立连接(或从哪台DB的连接里取出连接复用),而到了query阶段Atlas才能知道客户端发来的SQL语句是读还是写,这就决定了必须在主库上预留一定数量的连接供写语句使用。

朱超@360 10:58:36

你把min-idle-connections设低点就看到效果了,因为你连接次数太少,主库还没达到min-idle值,就不会去从库上建连接

朱超@360 10:59:13

先在主库上建一定数量的连接,再去从库建连接,如果从库上没有连接,就不会打向从库

朱超@360 11:00:32

群里的“风过后”昨天就问我一样的问题,你也可以跟他谈下

文洪 11:03:55

(2)当有客户端连接Atlas时,Atlas会先在第一台DB上建立连接,直到主库连接池内的

空闲连接数达到min-idle-connections,再在下一台DB上建立连接,直到所有DB连接池内的空闲连接数都达到min-idle-connections,便不再建立新连接,而开始复用连接池内的连接。


开始复用连接池内的连接,这句怎么解读?都到达了min-idle-connections后,后面的第一个连接就指向第一台db也就是写的库,而在空闲连接数外建立连接。如果照这么说都达到了min-idle-connections死的第一台是写DB?

文洪 11:04:04

恩,我跟他在聊呢。

朱超@360 11:05:15

开始阶段,主库连接池还没达到min-idle,从库上就还没有建连接,这时要执行读写分离,但从库没有连接,所以必须打向主库

朱超@360 11:05:43

连接一定次数后,主库达到min-idle,从库开始建连接,这时读写分离就会把读打向从库

朱超@360 11:06:07

建连接或复用连接指的是connect阶段

朱超@360 11:06:13

读写分离指的是query阶段

文洪 11:12:12

好的,多谢解惑。


文洪 10:40:43
风过同学。
文洪 10:41:25
altas应该是基于mysql-proxy0.8.1开发的吧,写数据库也可读。我不喜欢这点。
风过后…… 10:42:39
全对 公司因为这一天也放弃使用了,但是你回头想想
风过后…… 10:43:05
一台合格的DB服务器 SAS 1.5K转速 双路CPU需要2w快
风过后…… 10:43:39
一般web应用  读写比例是10:1 样子 ,2W块只写,很浪费的
文洪 10:44:42
没明白你的意思啊,你是想要写数据不读吗?
文洪 10:45:24
但你的聊天看来应该是要可写可读才对啊。
风过后…… 10:47:41
==
文洪 10:49:03
找机会问问360内部是如何使用这个的,在架构中怎么体现与实际价值相等。
文洪 10:50:30
你们公司的架构是不是前端负载分发连接。后端处理主从复制么?
文洪 10:52:28
你不会是360的员工吧,亲。
10:53:03风过后……已经接受你的加好友请求
运维@风过 10:53:16
他这个其实加入架构很简单的  client服务器连接的是Atlas,Atlas后端是主从,一主多从
运维@风过 10:54:52
主的高可用可以使用mysql官网推荐的heartbeat+drbd保证主的高可用,从的高可用是多从 Atlas会自行检测从的可用程度
文洪 10:55:30
恩,他的架构我明白,我问的是你们公司的架构。你们公司不弃atlas了嘛,看看你们的实施经验。
运维@风过 10:57:49
atlas不能完全读写分离,这个和开发者确认过了,老大决定改代码去了,就这么简单
运维@风过 10:58:01
品茶哪个公司的
运维@风过 10:58:07
我不是360的
文洪 11:04:20
我小公司啊。
运维@风过 11:04:35
me too  呵呵
文洪 11:04:35
刚和他聊了机制,他叫我和你聊聊,说和你昨天问过同样的问题了。
运维@风过 11:04:50
可以的  你想问啥
文洪 11:05:03
(2)当有客户端连接Atlas时,Atlas会先在第一台DB上建立连接,直到主库连接池内的
空闲连接数达到min-idle-connections,再在下一台DB上建立连接,直到所有DB连接池内的空闲连接数都达到min-idle-connections,便不再建立新连接,而开始复用连接池内的连接。

开始复用连接池内的连接,这句怎么解读?都到达了min-idle-connections后,后面的第一个连接就指向第一台db也就是写的库,而在空闲连接数外建立连接。如果照这么说都达到了min-idle-connections死的第一台是写DB?

文洪 11:05:10
哈哈,我刚发他也问了。
运维@风过 11:06:13
连接池的概念这个你知道吧
文洪 11:06:39
不太明白,你可以简单说说嘛。
运维@风过 11:08:58
min-idle-connections假设为10,db假设2台。

client发起11个连接给Atlas,(同时假设11个都在query状态),那么第11个就会打向2db
这时候前10个都不query了成sleep了
第12个会继续请求2db
运维@风过 11:09:35
一直到满足2db的min-idle-connections 10    共计20个connect建立起来了
文洪 11:09:56
第二台db的min-idle也满了,以后的连接会打向哪里?
运维@风过 11:10:21
这个时候20个未必都在用,Atlas会把20个做成一个池,sleep的就会复用
运维@风过 11:10:51
如果20个都在query 你需要调大min-idle
文洪 11:11:04
恩,我的意思是前20都在用。后面的会打向哪儿。
运维@风过 11:11:04
如果20个都在query Atlas日志会报警的
运维@风过 11:11:13
那就lost
运维@风过 11:11:22
和DB一样  
运维@风过 11:12:15
还有啥要问的
文洪 11:13:39
我问个傻比问题,mysql的机制如果min-idle-connections满了以后的连接都丢弃?还是排队?那么最大连接起什么作用?
运维@风过 11:15:24
mysql关于连接的参数是max_connections,不加入中间层情况下 高过max_connections数值就会lost  同Atlas
运维@风过 11:15:41
报错 丢去
文洪 11:17:43
所以如果db1,db2的min-idle满了那么db1,db2上面应该还会有max_connections控制,所以下一连接应该要打到db1上去,直到max_connection的值,然后再打db2,再到db2的max_con..值也满了,下面才丢弃吧?
运维@风过 11:18:00
no
文洪 11:18:43
我和你聊完写个小python去测测。
运维@风过 11:18:50
max_connections是mysql控制参数,这是两道水闸
运维@风过 11:19:00
一个在上游  一个在下游
运维@风过 11:20:00
Atlas的策略是先在主库上建连接,待主库连接池中的空闲连接达到min-idle-connections后,再去从库建连接,当每台DB连接池中的空闲连接都达到min-idle后,将开始复用连接,不再新建。

运维@风过 11:20:08
开发者回复的很具体
文洪 11:20:29
有这样的FAQ吗?
运维@风过 11:20:31
当然 如果你min-idle-connections》max_connections   依旧会lost
运维@风过 11:20:39
额,,他回我邮件的
文洪 11:21:37
恩,明白了。还有一点
运维@风过 11:23:00
你可以测一下,我是比较懒的,呵呵
文洪 11:23:52
因为读写是由mysql_proxy 控制,而且存在于上游,那么等于说控制的是min-idle数,如果min-idle里面有10条读占着,那么下一条写是指向哪里?我这里假设max_connections设的是20,按照机制这一条写应该是lost吗?
运维@风过 11:25:59
1.10条读未必会全在master上
2.10条读在master上应该会lost才对
文洪 11:44:07

运维@风过 11:45:31
解释错了 看群
运维@风过 11:45:33
sorry
文洪 11:45:58
spacer.gif
运维@风过 11:47:21
只是为了满足达到建立min-idle数这个需求是吧?  满足master上min-idle后就完全的读写分离了,(撇开例外)

文洪 11:51:03
明白了

运维@风过(**********) 11:22:32

@朱超@360   delete from xx 确实给Atlas屏蔽了,我想继续加入其他危险语句这个可以配置吗?

朱超@360(**********) 11:23:47

呃,在早期版本是可以配置的,后来我们把这个功能去掉了……

朱超@360(**********) 11:24:10

现在DBA主要通过在DB端配置限制

运维@风过(**********) 11:28:02

@朱超@360 Atlas不是完全的读写分离,Atlas会对主 写入的connect有优化措施吗?(比如master上读太多)

朱超@360(**********) 11:29:06

正常工作后,master上除了lock内、事务内、加/*master*/以外的读,没有其他的读

朱超@360(**********) 11:29:29

这个写错了,去掉“以外”

朱超@360(**********) 11:29:32

病句了

运维@风过(**********) 11:31:44

@朱超@360 我测试的结果是,假设min-idle-connections=10(测试需要),那么前10个connect都是读写在Master上的,后期正常运行读请求还会打向master吗?

朱超@360(**********) 11:32:03

不会

朱超@360(**********) 11:32:29

DB的wait_timeout不要设得太短,只会白白消耗效率

朱超@360(**********) 11:32:38

因为Atlas不会一直新建连接

运维@风过(**********) 11:33:17

min-idle-connections=10  只有一开始的前10个connect是打向master?  后续基本不会在读master(lock内、事务内、加/*master*/除外)?

这是为啥?

朱超@360(**********) 11:33:33

锁和事务都是打向主库的

朱超@360(**********) 11:33:47

加/*master*/是程序员指定要读主库

运维@风过(**********) 11:34:02

撇开lock内、事务内、加/*master*/ 我们继续聊

朱超@360(**********) 11:34:14

其他的读都去从库

朱超@360(**********) 11:34:29

最简单的,你这么压一下

运维@风过(**********) 11:34:35

为啥一开始前10个connect的读是打向master?   稳定了就不打向master了?

朱超@360(**********) 11:34:44

while [ 1 ]; do mysql -e 'select 1'; done

运维@风过(**********) 11:34:54

嗯 功能测完  压力测试一下

朱超@360(**********) 11:34:56

当然mysql后面需要跟上-h -u -p之类

运维@风过(**********) 11:35:19

只是没搞懂为啥一开始前10个connect的读是打向master?   稳定了读就不打向master了?

朱超@360(**********) 11:35:28

一开始是在主库上建连接,达到min-idle后才去从库建连接

朱超@360(**********) 11:35:35

从库没有连接时,自然没法执行操作

朱超@360(**********) 11:35:50

这个阶段很短就会达到了,然后就正常读写分离了

朱超@360(**********) 11:36:01

我正在写这方面的一个解释文档

朱超@360(**********) 11:36:31

主要原因就是connect和query是独立的阶段,connect阶段Atlas没法知道在query时到来的是读还是写

朱超@360(**********) 11:36:43

所以主库上必须预备一定量的连接

运维@风过(**********) 11:36:50

只是为了满足达到建立min-idle数这个需求是吧?  满足master上min-idle后就完全的读写分离了,(撇开例外)

朱超@360(**********) 11:36:57



相关推荐
<p> 欢迎参加英特尔® OpenVINO™工具套件初级课程 !本课程面向零基础学员,将从AI的基本概念开始,介绍人工智能与视觉应用的相关知识,并且帮助您快速理解英特尔® OpenVINO™工具套件的基本概念以及应用场景。整个课程包含了视频的处理,深度学习的相关知识,人工智能应用的推理加速,以及英特尔® OpenVINO™工具套件的Demo演示。通过本课程的学习,将帮助您快速上手计算机视觉的基本知识和英特尔® OpenVINO™ 工具套件的相关概念。 </p> <p> 为保证您顺利收听课程参与测试获取证书,还请您于<strong>电脑端</strong>进行课程收听学习! </p> <p> 为了便于您更好的学习本次课程,推荐您免费<strong>下载英特尔® OpenVINO™工具套件</strong>,下载地址:https://t.csdnimg.cn/yOf5 </p> <p> 收听课程并完成章节测试,可获得本课程<strong>专属定制证书</strong>,还可参与<strong>福利抽奖</strong>,活动详情:https://bss.csdn.net/m/topic/intel_openvino </p> <p> 8月1日-9月30日,学习完成【初级课程】的小伙伴,可以<span style="color:#FF0000;"><strong>免费学习【中级课程】</strong></span>,中级课程免费学习优惠券将在学完初级课程后的7个工作日内发送至您的账户,您可以在:<a href="https://i.csdn.net/#/wallet/coupon">https://i.csdn.net/#/wallet/coupon</a>查询优惠券情况,请大家报名初级课程后尽快学习哦~ </p> <p> <span style="font-size:12px;">请注意:点击报名即表示您确认您已年满18周岁,并且同意CSDN基于商务需求收集并使用您的个人信息,用于注册OpenVINO™工具套件及其课程。CSDN和英特尔会为您定制最新的科学技术和行业信息,将通过邮件或者短信的形式推送给您,您也可以随时取消订阅不再从CSDN或Intel接收此类信息。 查看更多详细信息请点击CSDN“<a href="https://passport.csdn.net/service">用户服务协议</a>”,英特尔“<a href="https://www.intel.cn/content/www/cn/zh/privacy/intel-privacy-notice.html?_ga=2.83783126.1562103805.1560759984-1414337906.1552367839&elq_cid=1761146&erpm_id=7141654/privacy/us/en/">隐私声明</a>”和“<a href="https://www.intel.cn/content/www/cn/zh/legal/terms-of-use.html?_ga=2.84823001.1188745750.1560759986-1414337906.1552367839&elq_cid=1761146&erpm_id=7141654/privacy/us/en/">使用条款</a>”。</span> </p> <p> <br /> </p>
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页