mysql读写分离

主从同步，将主服务器（master）上的数据复制到从服务器（slave）。 应用场景 读写分离，提高查询访问性能，有效减少主数据库访问压力。 实时灾备，主数据库出现故障时，可快速切换到从数据库。 数据汇总，可将多个主数据库同步汇总到一个从数据库中，方便数据统计分析。 部署环境 ​ 注：使用docker部署mysql实例，方便快速搭建演示环境。但本文重点是讲解主从配置，因此简略描述docker环境构建mysql容器实例。 数据库：MySQL 5.7.x （相比5.5，5.6而言，5.7同步性能更好，支持多源复制，可实现多主一从，主从库版本应保证一致） 操作系统：CentOS 7.x 容器：Docker 17.09.0-ce 镜像：mysql:5.7 主库：IP=192.168.10.212; PORT=3506; server-id=100; database=test; table=user 从库：IP=192.168.10.212; PORT=3606; server-id=110; database=test; table=user 配置约束 主从库必须保证网络畅通可访问 主库必须开启binlog日志 主从库的server-id必须不同 事前准备 关闭selinux setenforce 0 vim /etc/sysconfig/selinux SELINUX=disabled

主从从，也称为级联主从，数据流向：A(主)->B(从)->C(从从)，主从从级联复制。 应用场景 在主从配置的基础上，再增加一个从库，进一步提高数据安全，容灾备份。 读写分离，从库只用于查询，提高数据库整体性能。 从从库，用于备份，等同在线实时增量备份。 部署环境 ​ 注：使用docker部署mysql实例，方便快速搭建演示环境。但本文重点是讲解主从配置，因此简略描述docker环境构建mysql容器实例。 数据库：MySQL 5.7.x （相比5.5，5.6而言，5.7同步性能更好，支持多源复制，可实现多主一从，主从库版本应保证一致） 操作系统：CentOS 7.x 容器：Docker 17.09.0-ce 镜像：mysql:5.7 主库：IP=192.168.10.212; PORT=4200; server-id=200; database=test; table=user 从库：IP=192.168.10.212; PORT=4211; server-id=210; database=test; table=user 从从库：IP=192.168.10.212; PORT=4211; server-id=211; database=test; table=userk 配置约束 主从库必须保证网络畅通可访问 主库必须开启binlog日志 主从库的server-id必须不同

一个社交 App需实现的功能 用户关注的常规社交功能、活动、地理位置、探索功能、新鲜事、视频照片分享等等，需要提供的功能不胜枚举，所以从技术角度来说，开发者需要解决的问题也是异常复杂的。 当一款社交 App发布之初，用户访问量比较小，使用一台服务器就能够支撑全部的访问压力和数据存储需求，但是互联网应用具有病毒式的传播特点。一款App很可能会面临一夜爆红的现象，访问量和数据量在短时间内呈现爆发式增长，这时候会面临的局面是每天上亿PV、数百万新增用户和活跃用户、流量飙升至每秒数百兆。这些对于一个只部署了简单后端架构的应用来讲是无法支撑的，会直接导致服务器响应缓慢甚至超时，以及在高峰期时服务呈现瘫痪状态，使得后端的服务完全无法使用，用户体验急剧下降。本文将会通过一个真实的案例来分享一个社交应用如何构建一个具备高伸缩性的后端系统。 社交 App最初部署的后端架构解析 社交 App在最初的时候，后端架构相对比较简单，最初是部署在基础网络之上。最前面放置一台绑定了公网IP的nginx服务器作负载均衡，后面放置3台应用服务器来负责处理所有业务上的请求，最后面搭建一台MySQL Database数据库。 构建私有网络 随着产品的不断迭代、用户数的持续增长、数据量的积累， App就需要改进自己的后端架构，即开始构建私有网络。用户可以使用私有网络构建自己的网络拓扑——创建路由器和私有网络

写在前面的话 不管是作为运维还是作为 DBA，我们的工作都不是写 SQL，搞业务。更多的还是如何实现又好又快的给开发提供一个数据库环境和保障数据的安全性。前面的文章中读写分离，高可用，建立索引，分库分表等都是类似改变业务的架构来提升数据库的性能和稳定性。本章节介绍如何通过修改 my.cnf 配置文件直接以最低的成本提升服务器的性能。 关于 MySQL 优化 优化的标准： 1. 优化有风险，配置需谨慎。 2. 优化永远不是一个人的问题，需要开发，运维，DBA 共同介入。 3. 稳定比性能重要，没有明显提升的优化是失败的。 4. 一个问题的解决往往伴随着另外一个问题的产生，优化不一定都是好的。 优化的方向：安全和性能 优化的范围： 1. 硬件和系统：例如机器配置，网络，系统优化等。 2. 业务程序优化：例如索引，锁，SQL 性能等。 3. 数据库优化：例如数据库架构，数据库配置参数等。 操作系统级别的优化 1. CPU 使用情况：top 命令 --> 按 1 我这里选的 4 核，所以可以看到 4 个 CPU。 主要指标： us ：use，用户程序运行中 CPU 占比，理想中是能达到 70% 最好，这样才能说明设备性能充分利用。 sy ：sys，系统资源，一般内核调用，这个偏高可能是 BUG，中毒或者数据库锁住了。 id ：idle，空闲时间占比。 wa ：wait，等待时间

部署环境： 系统环境CentOS release 6.5_x64 主mysql服务器ip：172.18.49.10 从mysql服务器ip：172.18.49.2 开始部署安装： Mysql服务器都已经搭建完成。 l 主mysql上 ： # cp /etc/my.cnf /etc/my.cnf.bak # vi /etc/my.cnf log_bin=mysql-bin //开启二进制日志 server_id=1 //server_id 的值主从必须不同 # service mysqld restart 登录mysql后进行授权： mysql> grant all on *.* to 'replication'@'%' identified by 'replication'; mysql> flush privileges; 解释：在master的数据库服务器中建立一个复制的账户，每个slave使用该账户链接master来进行复制，设置所有权限（根据具体情况自定）。上面创建了一个replication用户，密码是replication。只允许在所有段的ip地址的登录。 查看master的状态： # mysql -uroot -p mysql> show master status; 记住file和position的值，配置slave的时候需要用。 l 从mysql上配置 ：

MySQL面试 - 读写分离 面试题 你们有没有做 MySQL 读写分离？如何实现 MySQL 的读写分离？MySQL 主从复制原理的是啥？如何解决 MySQL 主从同步的延时问题？ 面试官心理分析 高并发这个阶段，肯定是需要做读写分离的，啥意思？因为实际上大部分的互联网公司，一些网站，或者是 app，其实都是读多写少。所以针对这个情况，就是写一个主库，但是主库挂多个从库，然后从多个从库来读，那不就可以支撑更高的读并发压力了吗？ 面试题剖析 如何实现 MySQL 的读写分离？ 其实很简单，就是基于主从复制架构，简单来说，就搞一个主库，挂多个从库，然后我们就单单只是写主库，然后主库会自动把数据给同步到从库上去。 MySQL 主从复制原理的是啥？ 主库将变更写入 binlog 日志，然后从库连接到主库之后，从库有一个 IO 线程，将主库的 binlog 日志拷贝到自己本地，写入一个 relay 中继日志中。接着从库中有一个 SQL 线程会从中继日志读取 binlog，然后执行 binlog 日志中的内容，也就是在自己本地再次执行一遍 SQL，这样就可以保证自己跟主库的数据是一样的。 这里有一个非常重要的一点，就是从库同步主库数据的过程是串行化的，也就是说主库上并行的操作，在从库上会串行执行。所以这就是一个非常重要的点了，由于从库从主库拷贝日志以及串行执行 SQL 的特点，在高并发场景下

MySQL Proxy最强大的一项功能是实现“读写分离(Read/Write Splitting)”。基本的原理是让主数据库处理事务性查询，而从数据库处理SELECT查询。数据库复制被用来把事务性查询导致的变更同步到集群中的从数据库。 　　Jan Kneschke在《MySQL Proxy learns R/W Splitting》中详细的介绍了这种技巧以及连接池问题： 　　为了实现读写分离我们需要连接池。我们仅在已打开了到一个后端的一条经过认证的连接的情况下，才切换到该后端。MySQL协议首先进行握手。当进入到查询/返回结果的阶段再认证新连接就太晚了。我们必须保证拥有足够的打开的连接才能保持运作正常。 　　实现读写分离的LUA脚本： 　　 复制代码 代码如下: -- 读写分离 　　-- 　　-- 发送所有的非事务性Select到一个从数据库 　　if is_in_transaction == 0 and 　　packet:byte() == proxy.COM_QUERY and 　　packet:sub(2, 7) == "SELECT" then 　　local max_conns = -1 　　local max_conns_ndx = 0 　　for i = 1, #proxy.servers do 　　local s = proxy.servers[i] 　　--

简单来说，读写分离(图10.3) 就是只在主服务器上写，只在从服务器上读。基本的原理是让 主数据库处理事务性查询，而从数据库处理select 查询。数据库复制被用来把事务性查询导致的变更同步到群集中的从数据库。 目前较为常见的MySQL读写分离分为两种。 1)基于程序代码内部实现 在代码中根据select. insert 进行路由分类，这类方法也是目前生产环境应用最广泛的。优点是性能较好，因为在程序代码中实现，不需要增加额外的设备作为硬件开支:缺点是需要开发人员来实现，运维人员无从下手。 2)基于中间代理层实现 代理一般位于客户端和服务器之间，代理服务器接到客户端的请求后通过判断后转发到后端数据库，有两个代表性程序。 (1) MySQL-Proxy。MySQL- -Proxy为MySQL开源项目，通过其自带的lua脚本进行SQL判断,虽然是MySQL官方产品，但是MySQL官方并不建议将MySQL- -Proxy 用到生产环境。 (2) Amoeba (变形虫)。由陈思儒开发，其曾就职于阿里巴巴。该程序用Java语言进行开发, 阿里巴巴将其用于生产环境。它不支持事务和存储过程。 经过上述简单的比较,通过程序代码实现MySQL读写分离自然是一个不错的选择, 但是并不是 所有的应用都适合在程序代码中实现读写分离，例如一些大型复杂的Java应用

本文主要分析网站后台架构中的负载均衡器，企业常用的硬件负载均衡器软件负载均衡器、数据库代理服务器和数据库。 1.1 负载均衡 在大型网站部署中，负载均衡至少有三层部署。第一层为web server或者缓存代理之上的负载均衡，第二层为数据库之上的负载均衡，第三层为存储设备之上的负载均衡。 在第一层部署中，最常使用的是硬件负载均衡器有F5 BIG-IP、Citrix NetScaler、Radware、Cisco CSS、Foundry等产品。这些产品价格不菲，高达几十万人民币。在中国大陆，采用F5Network公司的BIG-IP负载均衡交换机的网站有新浪网、雅虎、百度、搜狐、凤凰网、央视国际、中华英才网、猫扑、畅游等。之前淘宝采用 NetScaler作为其硬件负载均衡器。后来用软件负载均衡器LVS和HAproxy混合使用来代替硬件负载均衡器。硬件负载均衡器可以提供OSI参考模型的第四/七层进行负载均衡。在第七层实现负载均衡的原理是，通过检查流经的HTTP报头，根据报头内的信息来执行负载均衡任务。在第四层(网络层)实现负载均衡的DR模式的原理是，通过更改请求包的目的MAC地址来进行负载均衡。 在第一层部署中，最常用的软件负载均衡器为LVS(LinuxVirtual Server)和HAproxy。其中LVS采用基于IP负载均衡技术和基于内容请求分发技术

准备工作 本文档是在ubuntu14.04下安装 2.2版本的atlas 。 官方文档很重要，请熟读。 wiki地址： https://github.com/Qihoo360/Atlas/wiki QQ 群：326544838(可以加此群进行咨询) 1. 所用软件： Ubuntu14.04 LTS版 2. 使用服务器地址：192.168.1.244 3. ubuntu14.04 对应的 安装 文件选择 Atlas-2.2-debian7.0-x86_64.deb 4. 主库为192.168.1.160，从库为192.168.1.116,192.168.1.149,192.168.236 2 Atlas 的整体架构 Atlas是由 Qihoo 360, Web平台部基础架构团队开发维护的一个基于MySQL协议的数据中间层项目。它是在mysql-proxy 0.8.2版本的基础上，对其进行了优化，增加了一些新的功能特性。360内部使用Atlas运行的mysql业务，每天承载的读写请求数达几十亿条。 Atlas 是一个位于应用程序与MySQL之间中间件。在后端DB看来，Atlas相当于连接它的客户端，在前端应用看来，Atlas相当于一个DB。Atlas作为服务端与应用程序通讯，它实现了MySQL的客户端和服务端协议，同时作为客户端与MySQL通讯。它对应用程序屏蔽了DB的细节