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



运维@风过 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
对