读写分离规划

2018-01-11 12:48:42来源:oschina作者:Mr_Qi人点击

分享
背景随着线上应用的使用越来越多&用户增加 db不可避免的将成为瓶颈
web应用除了session之外完全可以扩容【+机器】session在使用redis之后也可扩容
db做读写分离可以扩展读性能 但是无法扩展写性能
需要评估系统读写比例 读比例达到一定比例以上读写分离才有意义【通常读写要达到10:1】
需要评估系统不久的将来不会做sharding 否则完全没必要读写分离 数据

根据上述的一些指标来获取当前系统读写比例


show global status like 'Com_select';
show global status like 'Com_insert';
show global status like 'Com_update';
show global status like 'Com_delete';
select concat(1638351809 / (1638351809+25198785+26718467+1670670)* 100,'%');
show global status like 'Slow_queries';
select concat(989488 / (1638351809+26718467+1670670) * 100,'%');
show global status like 'Table_open_cache_misses';
show global status like 'Table_open_cache_hits';
show global status like 'Opened_tables';

系统中目前读占比达到96.8328% 换言之我们是读密集型的业务


慢sql比例0.0594%大概万五


现状

目前我们采用了主从架构 主要目的如下:

安全 防止主库发生问题 可以临时切换成从库【容灾】
OLAP 方便报表分析 防止报表在主库执行产生太多慢sql兼影响主业务

其实上述两点里第一点不太站得住脚


事实上 目前db连接采用的是ip连接【如果一旦主库挂了想要更换从库势必造成要修改代码或者配置】果然只是纸上谈兵啊~


事实上 大部分mysql服务器都会开启skipnameresolve选项用来防止域名解析造成的连接太慢===》因此许多实践会采用ip漂移技术


读写分离优点

减轻了主库(写)压力:达达的业务主要来源于读操作,做读写分离后,读压力转移到了从库,主库的压力减小了数十倍。


从库(读)可水平扩展(加从库机器):因系统压力主要是读请求,而从库又可水平扩展,当从库压力太时,可直接添加从库机器,缓解读请求压力。

思考如果在当前做OLAP的机器拿出来继续做读库 那么很容易出现老问题【在报表稽计过程中主业务查询发生慢sql】==》最好使用单独的读库
大量的业务如下会在db写之后然后会重新读当前数据【比如创建工单之后会要求查看该工单详情】==》主从延迟问题相当难解决,通常的方案都是只能减小延迟而无法完全避免 比如新建了某工单 然后立刻查看却发现无法检索到 通常要求业务开发方尽量采用小事务【这样才不会导致长事务在从库上执行仍然需要同样多时间】===》尽量采用比主库更好的机器 缩短时间差

那如何为避免或解决主从延迟?可以做了如下一些优化:



优化MySQL参数,比如增大innodb_buffer_pool_size,让更多操作在MySQL内存中完成,减少磁盘操作。


使用高性能CPU主机。


数据库使用物理主机,避免使用虚拟云主机,提升IO性能。


使用SSD磁盘,提升IO性能。SSD的随机IO性能约是SATA硬盘的10倍。


业务代码优化,将实时性要求高的某些操作,使用主库做读操作。

部分业务不关心数据及时性【比如提醒等等】,但是部分业务相当关心数据及时性【用户修改了密码】===》不能非得等到同步之后才能登录
大量的同步基本都是在3s之内【特别是内网中】可以在新建跳转之前增加中转页面【比如某些论坛都是2s后跳转到详情页】

由于需要读取从库那么必然要监控主从延迟 同时重中之重不能出现主从中断==》带来业务中断

mysql> show slave status/G
*************************** 1. 行 ***************************
Slave_IO_State : Waiting for master to send event
Master_Host: *
Master_User: repli
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000730
Read_Master_Log_Pos : 706409590
Relay_Log_File : mysql-relay.001206
Relay_Log_Pos: 706409803
Relay_Master_Log_File : mysql-bin.000730
Slave_IO_Running: Yes
Slave_SQL_Running : Yes
Replicate_Do_DB: *
Replicate_Ignore_DB :
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno : 0
Last_Error :
Skip_Counter : 0
Exec_Master_Log_Pos : 706409590
Relay_Log_Space: 706410053
Until_Condition: None
Until_Log_File :
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher :
Master_SSL_Key :
Seconds_Behind_Master : 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno : 0
Last_SQL_Error :
Replicate_Ignore_Server_Ids:
Master_Server_Id: 146
Master_UUID: d34843d3-428b-11e6-beee-00163e0e1ac5
Master_Info_File: /data/mysqldb/master.info
SQL_Delay: 0
SQL_Remaining_Delay : NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp :
Master_SSL_Crl :
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set :
Auto_Position: 0
Replicate_Rewrite_DB:
Channel_Name :
Master_TLS_Version:
1 行于数据集 (0.04 秒)

通常需要关注Slave_IO_RunningSlave_SQL_RunningSeconds_Behind_Master 可以看到该从库没有延迟


需求多从库
支持选择主库
当前写事务中的读必须读取主库
支持读重试

最新文章

123

最新摄影

微信扫一扫

第七城市微信公众平台