mysql读写分离

MySQL是当下互联网最流行的开源数据库。在当前的后台开发中，MySQL应用非常普遍，企业在选拔Java人才时也会考察求职者诸如性能优化、高可用性、备份、集群、负载均衡、读写分离等问题。想要成为Java工程师，一定要熟练掌握MySQL，接下来我就给大家分享MySQL数据库应用场景知识。 1、单Master 单Master的情况是普遍存在的，对于很多个人站点、初创公司、小型内部系统，考虑到成本、更新频率、系统重要性等问题，系统只依赖一个单例数据库提供服务，基本上已经满足需求。单Master场景下应该关注四点：数据备份(冷备、热备、温备)、数据还原、备份监控、数据文件远程存储。 2、一主一从 考虑一主一从的多数初衷是系统性能和系统高可用性问题，除了单Master场景中的备份工作需要做好以外，还有性能优化、读写分离、负载均衡三项重点工作需要考虑。 3、一主n从 一旦开始考虑一主多从的服务器架构，则证明你的系统对可用性、一致性、性能中一种或者多种的要求比较高。好多系统在开始搭建的时候都会往这个方向看齐，这样“看起来”系统会健壮很多。一主n从关注的重点是：数据一致性、脑裂、雪崩、连接池管理。 4、横向集群 横向集群主要是从业务特性的角度对系统进行切分，最彻底就是切分成了各个子系统，子系统之间通过一些数据同步的方案来把一些核心数据进行共享，以避免跨库调用Join。然后是各种系统接口调用

4，在master，slave1，slave2上分别安装MySQL [root@master1 ~]# mkdir /abc ##创建挂载点 [root@master1 ~]# mount.cifs //192.168.100.1/LNMP-C7 /abc/ ##远程挂载 Password for root@//192.168.100.1/LNMP-C7: [root@master1 ~]# cd /abc/ [root@master1 abc]# ls mysql-5.5.24 [root@master1 abc]# tar zxvf mysql-5.5.24.tar.gz -C /opt/ ##解压 [root@master1 opt]# yum install -y \ > gcc gcc-c++ \ > ncurses \ > ncurese-devel \ ##控制终端屏幕显示的库 > bison \ ##语法分析 > make > cmake ##cmake工具 > libaio-devel ##系统调用来实现异步IO [root@slave1 opt]# useradd -s /sbin/nologin mysql ##添加不可登录的mysql用户 [root@slave1 opt]# cd /opt/mysql-5.5.24/ [root@slave1 mysql

主从复制原理： 从库生成两个线程，一个I/O线程，一个SQL线程； i/o线程去请求主库 的binlog，并将得到的binlog日志写到relay log（中继日志） 文件中； 主库会生成一个 log dump 线程，用来给从库 i/o线程传binlog； SQL 线程，会读取relay log文件中的日志，并解析成具体操作，来实现主从的操作一致，而最终数据一致； mysql的日志类型： Error log 错误日志 General query log普通查询日志 Slow query log 慢查询日志（记录哪些查询比较慢 ） Binary log二进制日志文件（1、用于增量备份。2、主从） 要实现MySQL的主从复制，首先必须打开Master端的Binlog记录功能，否则就无法实现。因为整个复制过程实际上就是Slave从Master端获取BInlog日志，然后再在Slave上以相同顺序执行获取的binlog日志中记录的各种SQL操作。 1.传统的实现数据库主从复制 单向复制，只能slave复制master的，即slave对master库只读 base2 172.25.78.12 master base3 172.25.78.13 slaver # 在master上 [root@base2 ~]# tar xf mysql-5.7.24-1.el7.x86_64.rpm

mysql-proxy简介 MySQL读写分离是指让master处理写操作，让slave处理读操作，非常适用于读操作量比较大的场景，可减轻master的压力。 使用mysql-proxy实现mysql的读写分离，mysql-proxy实际上是作为后端mysql主从服务器的代理，它直接接受客户端的请求，对SQL语句进行分析，判断出是读操作还是写操作，然后分发至对应的mysql服务器上。 　mysql-proxy是官方提供的mysql中间件产品可以实现负载平衡，读写分离，failover等 　MySQL Proxy就是这么一个中间层代理，简单的说，MySQL Proxy就是一个连接池，负责将前台应用的连接请求转发给后台的数据库，并且通过使用lua脚本，可以实现复杂的连接控制和过滤， 　　从而实现读写分离和负载平衡。对于应用来说，MySQL Proxy是完全透明的，应用则只需要连接到MySQL Proxy的监听端口即可。 　　当然，这样proxy机器可能成为单点失效，但完全可以使用多个proxy机器做为冗余，在应用服务器的连接池配置中配置到多 个proxy的连接参数即可。 从图中可以看到，SQL语句并不直接进入到master数据库或者slave数据库，而是进入到 proxy，然后proxy判断这条语句是有关写的语句（包括insert、update、delete）还 是读语句（select

MySQL主从的作用：MySQL主从（MySQL replication），主要用于MySQL的实时备份或者读写分离。 MySQL主从的原理，总结一下： （1）每个主从仅可以设置一个主。 （2）主在执行SQL之后，记录二进制log文件（bin-log） （3）从连接主，并获取主的bin-log，存于本地relay-log，并从上次执行的位置起执行SQL，一旦遇到错误则停止同步。 mysql主从配置replication，又叫A,B复制，保证主从数据同步 A --> change data --> bin_log -transfer --> B --> repl_log -->change data 从这几条replication原理来看，可以有这些推论： （1）主从间的数据库不是实时同步，就算网络连接正常，也存在瞬间，主从数据不一致。 （2）如果主从的网络断开，从会在网络正常后，批量同步。 （3）如果对从进行修改数据，那么很可能从在执行主的bin-log时出现错误而停止同步，这是个很危险的操作。所以一般情况下，非常小心的修改从上的数据。 （4）一个衍生的配置是双主，即互为主从配置，只要双方的修改不冲突，可以工作良好。 （5）如果需要多主的话，可以用环形配置，这样任何一个节点的修改都可以同步到所有节点。 （6）可以应用在读写分离的场景，用以降低单台MySQL的I/O （7

当单台 MYSQL 服务器无法满足当前网站流量时的优化方案。需要搭建 mysql 集群技术。 一、功能： 当向主服务器插入 | 修改 | 删除数据时，数据会自动同步到从服务器。 注意：主从复制是单向的，只能主 -> 从 分为两种类型：发射型（一主多从）：一般使用在：备份、读写分离。 环形（多主多从）：一般使用：当主服务器压力大时、跨地区的网站实现数据同步 在环形结构中，如果同时向三台服务器的同一表插入记录会出现 “ ID 冲突的问题”。 解决办法：让三台服务器生成不同的 ID ； 第一台： 1,4,7... 第二台： 2,5,8.. 第三台： 3,6,9... 这个可以 MYSQL 的配置文件中设置： 二、主从的 原理（利用了 bin 日志） Mysql 中有一种日志叫做 bin 日志（二进制日志）。这个日志会记录下 所有修改了数据库 的 SQL 语句（ insert,update,delete,ALTER TABLE,grant 等等）。主从复制的原理其实就是把主服务器上的ＢＩＮ日志复制到从服务器上执行一遍，这样从服务器上的数据就和主服务器上的数据相同了。 扩展： mysql 中的日志： 查询日志 错误日志 Bin 日志 慢日志：你可以设置一个时间阀值，如 0.5 秒，那么将来所以执行时间超过这个值的 SQL 语句就会被 记录下来。这样我们就可以把慢的 SQL 语句记录下来

阅读目录 一 数据库管理软件的由来 二 数据库概述 三 mysql介绍 四 下载安装 五 mysql软件基本管理 六 初识sql语句 一 数据库管理软件的由来 基于我们之前所学，数据要想永久保存，都是保存于文件中，毫无疑问，一个 文件仅仅只能存在于某一台机器上 。 如果我们暂且忽略直接基于文件来存取数据的效率问题，并且假设程序所有的组件都运行在一台机器上，那么用文件存取数据，并没有问题。 很不幸，这些假设都是你自己意淫出来的，上述假设存在以下几个问题。。。。。。 1、程序所有的组件就不可能运行在一台机器上 #因为这台机器一旦挂掉则意味着整个软件的崩溃，并且程序的执行效率依赖于承载它的硬件，而一台机器机器的性能总归是有限的，受限于目前的硬件水平，就一台机器的性能垂直进行扩展是有极限的。#于是我们只能通过水平扩展来增强我们系统的整体性能，这就需要我们将程序的各个组件分布于多台机器去执行。 2、数据安全问题 #根据1的描述，我们将程序的各个组件分布到各台机器，但需知各组件仍然是一个整体，言外之意，所有组件的数据还是要共享的。但每台机器上的组件都只能操作本机的文件，这就导致了数据必然不一致。 #于是我们想到了将数据与应用程序分离：把文件存放于一台机器，然后将多台机器通过网络去访问这台机器上的文件（用socket实现），即共享这台机器上的文件,共享则意味着竞争，会发生数据不安全，需要加锁处理

为什么要优化? 系统的吞吐量瓶颈往往出现在数据库的访问速度上 随着应用程序的运行，数据库的中的数据会越来越多，处理时间会相应变慢 数据是存放在磁盘上的，读写速度无法和内存相比 Memcached/Redis（缓存）+Mysql+垂直拆分 这种做法可以将你的数据库的数据从开始的一个数据库分成了3个，比如第一个数据库复制保存用户信息，第二个保存商品信息，第三个保存 缺点： 当你的 数据库1 炸了，整合项目就运行不起来了（不安全） Mysql主从复制+读写分离 1、什么是主从复制 多搞几个数据库来存储数据，假设有三台服务器，一主二仆，即以太主服务器，二台从服务器 把你的主服务器的数据复制在你的二个从服务器里，复制是为了容错备份，缓存备份，保证数据的完整性，也为读写分离创建条件 2、什么是读写分离 增删改是写，查是读 写去主服务器去写 读取二个从服务器通过负载均衡去读 分工明确，结合缓存实现性能的一大提升 分库分表＋＋Mysql集群 承接主从复制，读写分离，以及Memcached的使用，这时MySQL主库的写压力开始出现瓶颈 而数据量的持续猛增，由于数据量的指数级增长，单单表表上上的的记记录录条条数数增增长长到到千千万万 级，只能继续对架构进行演变。 这个演变，就是使用分库分表来缓解写压力和数据记录条数增长的问题。 3、什么是分库分表 从字面上简单理解

单库单表 单库单表是最常见的数据库设计，例如，有一张用户(user)表放在数据库db中，所有的用户都可以在db库中的user表中查到。 单库多表 随着用户数量的增加，user表的数据量会越来越大，当数据量达到一定程度的时候对user表的查询会渐渐的变慢，从而影响整个DB的性能。如果使用mysql, 还有一个更严重的问题是，当需要添加一列的时候，mysql会锁表，期间所有的读写操作只能等待。 可以通过某种方式将user进行水平的切分，产生两个表结构完全一样的user_0000,user_0001等表，user_0000 + user_0001 + …的数据刚好是一份完整的数据。 多库多表 随着数据量增加也许单台DB的存储空间不够，随着查询量的增加单台数据库服务器已经没办法支撑。这个时候可以再对数据库进行水平区分。 分库分表规则 设计表的时候需要确定此表按照什么样的规则进行分库分表。例如，当有新用户时，程序得确定将此用户信息添加到哪个表中；同理，当登录的时候我们得通过用户的账号找到数据库中对应的记录，所有的这些都需要按照某一规则进行。 路由 通过分库分表规则查找到对应的表和库的过程。如分库分表的规则是user_id mod 4的方式，当用户新注册了一个账号，账号id的123,我们可以通过id mod 4的方式确定此账号应该保存到User_0003表中。当用户123登录的时候

一、前言：为什么MySQL要做主从复制（读写分离）？ 通俗来讲，如果对数据库的读和写都在同一个数据库服务器中操作，业务系统性能会降低。 为了提升业务系统性能，优化用户体验，可以通过做主从复制（读写分离）来减轻主数据库的负载。 而且如果主数据库宕机，可快速将业务系统切换到从数据库上，可避免数据丢失。 二、MySQL主从复制（读写分离）和集群的区别： 我对MySQL也是刚开始研究，不是很专业。我的理解是： 1、主从复制（读写分离）：一般需要两台及以上数据库服务器即可（一台用于写入数据，一台用于同步主的数据并用于数据查询操作）。 局限性： （1）配置好主从复制之后，同一张表，只能对一个服务器写操作。如果在从上执行了写操作，而之后主也操作了这张表，或导致主从不同步；据说可以配置成主主方式，但我还没有研究到。 （2）主数据库服务器宕机，需要手动将业务系统切换到从数据库服务器。无法做到高可用性（除非再通过部署keepalive做成高可用方案）。 2、集群是由N台数据库服务器组成，数据的写入和查询是随机到任意一台数据库服务器的，其他数据库服务器会自动同步数据库的操作。 任何一台数据库宕机，不会对整个集群造成大的影响。 局限性：我经过测试才知道目前mysql集群版本（MySQL Cluster）只能对NDB存储引擎的数据进行集群同步，如果是INNODB或其他的MySQL存储引擎是不行的