mysql读写分离

主从复制 常用命令: service mysqld start 数据库启动 service iptables stop 数据库停止 mysql –u root 数据库登录 概念 影响MySQL-A数据库的操作，在数据库执行后，都会写入本地的日志系统A中。 假设，实时的将变化了的日志系统中的数据库事件操作，在MYSQL-A的3306端口，通过网络发给MYSQL-B。 MYSQL-B收到后，写入本地日志系统B，然后一条条的将数据库事件在数据库中完成。 那么，MYSQL-A的变化，MYSQL-B也会变化，这样就是所谓的MYSQL的复制，即MYSQL replication。 在上面的模型中，MYSQL-A就是主服务器，即master，MYSQL-B就是从服务器，即slave。 日志系统A，其实它是MYSQL的日志类型中的二进制日志，也就是专门用来保存修改数据库表的所有动作，即bin log。【注意MYSQL会在执行语句之后，释放锁之前，写入二进制日志，确保事务安全】 日志系统B，并不是二进制日志，由于它是从MYSQL-A的二进制日志复制过来的，并不是自己的数据库变化产生的，有点接力的感觉，称为中继日志，即relay log。 可以发现，通过上面的机制，可以保证MYSQL-A和MYSQL-B的数据库数据一致，但是时间上肯定有延迟，即MYSQL-B的数据是滞后的。 【即便不考虑什么网络的因素

文章目录 前言 一、MySQL主从复制配置 1.1、概述 1.2、主从复制的过程 1.3、实验环境 1.4、主服务器配置 1.5、从服务器配置 二、MySQL主从复制验证 三、MySQL读写分离配置 3.1、概述 3.2、实验环境 3.3、amoeba服务器配置 四、验证读写分离 4.1、验证写入功能 4.2、验证读取功能 前言 MySQL主从复制与读写分离需要配置三个用户 用户1：在主服务器上设置，允许从服务器使用该用户访问 用户2：在主服务器和从服务器上设置，允许amoeba服务器使用该用户访问 用户3：在amoeba服务器的amoeba.xml中设置，允许客户端使用该用户访问 一、MySQL主从复制配置 1.1、概述 在企业网站中，为了保证数据的安全和稳定，后端的mysql数据库需要进行备份，形成主备，通过主从复制的方式使主服务器和从服务器数据同步。 1.2、主从复制的过程 1.3、实验环境 在vmware虚拟机中开2台linux虚拟机，一台master（主），一台slave（从）。 主机IP：192.168.5.135 从机IP：192.168.5.153 1.4、主服务器配置 手工编译安装mysql5.7 前面博客有详细过程，点此跳 安装ntp时间服务器，同步主从服务器的时间 [root@master ~]# yum install ntp -y ##安装ntp时间源

Mysql mycat读写分离： 下载网址： http://dl.mycat.io Mycat官方网址： http://mycat.org.cn 说明： 10.0.1.2为mycat服务器，10.0.1.3、10.0.1.4为mysql服务器 yum install java-1.8.0-openjdk tar zxfv Mycat-server-1.6.7.5-test-20200109231555-linux.tar.gz -C /space/ 配置读写分离： vi /space/mycat/conf/schema.xml <?xml version="1.0"?> <!DOCTYPE mycat:schema SYSTEM "schema.dtd"> <mycat:schema xmlns:mycat=" http://io.mycat/"&gt ; <schema name="TESTDB" checkSQLschema="true" sqlMaxLimit="100" randomDataNode="dn1"> <table name="travelrecord,address" dataNode="dn1" rule="auto-sharding-long" splitTableNames ="true"/> </schema> <dataNode name="dn1"

高并发这个阶段，肯定是需要做读写分离的，啥意思？因为实际上大部分的互联网公司，一些网站，或者是 app，其实都是读多写少。所以针对这个情况，就是写一个主库，但是主库挂多个从库，然后从多个从库来读，那不就可以支撑更高的读并发压力了吗？ 1、如何实现mysql的读写分离 其实很简单，就是基于主从复制架构，简单来说，就搞一个主库，挂多个从库，然后我们就单单只是写主库，然后主库会自动把数据给同步到从库上去。 2、mysql主从复制原理 主库将变更写入 binlog 日志，然后从库连接到主库之后，从库有一个 IO 线程，将主库的 binlog 日志拷贝到自己本地，写入一个 relay 中继日志中。接着从库中有一个 SQL 线程会从中继日志读取 binlog，然后执行 binlog 日志中的内容，也就是在自己本地再次执行一遍 SQL，这样就可以保证自己跟主库的数据是一样的。 这里有一个非常重要的一点，就是从库同步主库数据的过程是串行化的，也就是说主库上并行的操作，在从库上会串行执行。所以这就是一个非常重要的点了，由于从库从主库拷贝日志以及串行执行 SQL 的特点，在高并发场景下，从库的数据一定会比主库慢一些，是 有延时 的。所以经常出现，刚写入主库的数据可能是读不到的，要过几十毫秒，甚至几百毫秒才能读取到。 而且这里还有另外一个问题，就是如果主库突然宕机，然后恰好数据还没同步到从库

文章来源： https://www.cnblogs.com/php826291930/p/11242436.html 因为看了觉得通俗易懂，就转载了次文章，以做备份，如果侵犯原作者相应权利，请第一时间联系我进行删帖 1、what 什么是读写分离？ 读写分离，基本的原理是让主数据库处理事务性增、改、删操作（INSERT、UPDATE、DELETE），而从数据库处理SELECT查询操作。数据库复制被用来把事务性操作导致的变更同步到集群中的从数据库。 2、why 为什么要读写分离呢？ 因为数据库的“写”（写10000条数据到oracle可能要3分钟）操作是比较耗时的。 但是数据库的“读”（从oracle读10000条数据可能只要5秒钟）。 所以读写分离，解决的是，数据库的写入，影响了查询的效率。 3、when 什么时候要读写分离？ 数据库不一定要读写分离，如果程序使用数据库较多时，而更新少，查询多的情况下会考虑使用，利用数据库主从同步 。可以减少数据库压力，提高性能。当然，数据库也有其它优化方案。memcache 或是 表折分，或是搜索引擎。都是解决方法。 4、主从复制与读写分离 在实际的生产环境中，对数据库的读和写都在同一个数据库服务器中，是不能满足实际需求的。无论是在安全性、高可用性还是高并发等各个方面都是完全不能满足实际需求的。因此，通过主从复制的方式来同步数据

1:资料参考 https://blog.csdn.net/coldljy/article/details/3168906 https://www.cnblogs.com/jwentest/p/8552075.html https://www.cnblogs.com/ExMan/p/10396298.html 一：原理 Mysql-Proxy是一个处于你的client端和Mysql Server端之间的一个简单程序，它可以监测、分析和改变他们的通信。它使用灵活没有限制，常见的用途包括：负载平衡，故障、查询分析，查询过滤和修改等等。 Mysql -Proxy就是这么一个中间层代理，简单的说，Mysql-Proxy就是一个连接池，负责将前台应用的请求转发给后台数据库，并且通过使用lua脚本，可以实现复杂的连接控制和过滤，从而实现读写分离和负载平衡。对于应用来说，MySQL Proxy是完全透明的，应用则只需要连接到MySQL Proxy的监听端口即可。当然，这样proxy机器可能成为单点失效，但完全可以使用多个proxy机器做为 冗余 ，在 应用服务器 的连接池配置中配置到多个proxy的连接参数即可。 mysql-proxy最基本的用法，就是作为一个请求拦截，请求中转的中间层： 根本上，mysql-proxy是一个官方提供的框架，具备良好的扩展性，可以用来完成： sql拦截与修改

特点 原子性(Atomicity),一致性(Consistency),隔离型(Isolation)以及持久性(Durability) 一、事务的目的 1、可靠性和并发处理 可靠性：数据库要保证当insert或update操作时抛异常或者数据库crash的时候需要保障数据的操作前后的一致，想要做到这个，我需要知道我修改之前和修改之后的状态，所以就有了undo log和redo log。 并发处理：也就是说当多个并发请求过来，并且其中有一个请求是对数据修改操作的时候会有影响，为了避免读到脏数据，所以需要对事务之间的读写进行隔离，至于隔离到啥程度得看业务系统的场景了，实现这个就得用MySQL 的隔离级别。 二、实现事务功能的三个技术 1、日志文件(redo log 和 undo log) 2、锁技术 3、MVCC 1.1 redo log 与 undo log介绍 1.1.1redo log 什么是redo log ? redo log叫做重做日志，是用来实现事务的持久性。该日志文件由两部分组成：重做日志缓冲（redo log buffer）以及重做日志文件（redo log）,前者是在内存中，后者在磁盘中。 当事务提交之后会把所有修改信息都会存到该日志中。假设有个表叫做tb1(id,username) 现在要插入数据（3，ceshi） start transaction; select

当 MySQL 单表记录数过大时，增删改查性能都会急剧下降，可以参考以下步骤来优化： 单表优化 除非单表数据未来会一直不断上涨，否则不要一开始就考虑拆分，拆分会带来逻辑、部署、运维的各种复杂度，一般以整型值为主的表在千万级以下，字符串为主的表在五百万以下是没有太大问题的。而事实上很多时候MySQL单表的性能依然有不少优化空间，甚至能正常支撑千万级以上的数据量： 字段 尽量使用TINYINT、SMALLINT、MEDIUM_INT作为整数类型而非INT，如果非负则加上UNSIGNED VARCHAR的长度只分配真正需要的空间 使用枚举或整数代替字符串类型 尽量使用TIMESTAMP而非DATETIME， 单表不要有太多字段，建议在20以内 避免使用NULL字段，很难查询优化且占用额外索引空间 用整型来存IP 索引 索引并不是越多越好，要根据查询有针对性的创建，考虑在WHERE和ORDER BY命令上涉及的列建立索引，可根据EXPLAIN来查看是否用了索引还是全表扫描 应尽量避免在WHERE子句中对字段进行NULL值判断，否则将导致引擎放弃使用索引而进行全表扫描 值分布很稀少的字段不适合建索引，例如"性别"这种只有两三个值的字段 字符字段只建前缀索引 字符字段最好不要做主键 不用外键，由程序保证约束 尽量不用UNIQUE，由程序保证约束 使用多列索引时主意顺序和查询条件保持一致

对于一个以数据为中心的应用，数据库的好坏直接影响到程序的性能，因此数据库性能至关重要。一般来说，要保证数据库的效率，要做好以下四个方面的工作：数 据库设计、sql语句优化、数据库参数配置、恰当的硬件资源和操作系统，这个顺序也表现了这四个工作对性能影响的大小。下面我们逐个阐明： 一、数据库设计 　　适度的反范式,注意是适度的 　　我们都知道三范式，基于三范式建立的模型是最有效保存数 据的方式，也是最容易扩展的模式。我们在开发应用程序时，设计的数据库要最大程度的遵守三范式，特别是对于OLTP型的系统，三范式是必须遵守的规则。当 然，三范式最大的问题在于查询时通常需要join很多表，导致查询效率很低。所以有时候基于性能考虑，我们需要有意的违反三范式，适度的做冗余，以达到提 高查询效率的目的。注意这里的反范式是适度的，必须为这种做法提供充分的理由。下面就是一个糟糕的实例：　　 　 　在这里，为了提高学生活动记录的检索效率，把单位名称冗余到学生活动记录表里。单位信息有500条记录，而学生活动记录在一年内大概有200万数据量。 如果学生活动记录表不冗余这个单位名称字段，只包含三个int字段和一个timestamp字段，只占用了16字节，是一个很小的表。而冗余了一个 varchar(32)的字段后则是原来的3倍，检索起来相应也多了这么多的I/O。而且记录数相差悬殊，500 VS 2000000

MySQL ---- 读写分离 一：原理 读写分离就是只在主服务器上写，只在从服务器上读 主数据库处理事务性查询，而 从数据库处理select查询 数据库复制被用来把事务性查询导致的变更同步到集群中的从数据库 二：Amoeba的定义 Amoeba是一个以MySQL为底层数据存储，并对应用提供MySQL协议接口的proxy。它集中地响应应用的请求，依据用户事先设置的规则，将SQL请求发送到特定的数据库上执行。基于此可以实现负载均衡、读写分离、高可用性等需求。 Amoeba相当于一个SQL请求的路由器，目的是为负载均衡、读写分离、高可用性提供机制，而不是完全实现它们。需要结合使用MySQL的 Replication等机制来实现副本同步等功能。 安装包自行下载 ： 复制这段内容后打开百度网盘手机App，操作更方便哦 链接:https://pan.baidu.com/s/1kRkbem91iPxeQ-bZUObTxg 提取码:bg88 三：实验配置 1、环境说明 准备三台Mysql服务器 （一台主服务器 ，一台从服务器） 一台Amoeba ，用来实现读写分离 一台客户机作为验证 Mysql 主从复制与读写功能是密切相关的，通过主从复制来实现数据同步，再通过读写分离来提升数据库的并发负载能力。 2、实验步骤 配置Amoeba 服务器 [root@localhost ~]#