mysql读写分离

MySQL主主同步方案

不羁的心 提交于 2019-12-01 19:52:19
MySQL 主主同步方案 l MySQL 主主 +Keepalived l MySQL+DRBD+Heartbeat 在企业中,数据库高可用一直是企业的重中之重,中小企业很多都是使用 mysql 主 主 方案,一主多从,读写分离等,但是单主存在单点故障,从库切换成主库需要作改动。因此,如果是双主或者多主,就会增加 mysql 入口,增加高可用。 不过多主需要考虑自增长 ID 问题,这个需要特别设置配置文件,比如双主,可以使用奇偶 ,总之,主之间设置自增长 ID 相互不冲突就能完美解决自增长 ID 冲突问题。 主主方案实现思路 1、 两台 mysql 都可读写,互为主备 。 默认只使用一台 masterA 负责数据的写入,另一台 masterB 备用 处于备用状态 ; 2、 masterA 是 masterB 的主库, masterB 又是 masterA 的主库,它们互为主从; 3、 两台主库之间做高可用 , 可以采用 keepalived 等方案 , 使用 VIP 对外提供服务; 4、 所有提供服务的从服务器与 masterB 进行主从同步(双主多从) ; 5、 建议采用高可用策略的时候, masterA 或 masterB 均不因宕机恢复后而抢占 VIP (非抢占模式); 这样做可以在一定程度上保证主库的高可用 , 在一台主库 down 掉之后 ,

Mycat读写分离(一主一从)

耗尽温柔 提交于 2019-12-01 19:33:22
Mycat读写分离(一主一从) 我们一共使用2个虚拟机,每个机器的作用如下: 主机名 IP 地址 任务角色 数据库 node1 192.168.1.121 Mycat, master MySQL node2 192.168.1.122 slave MySQL Mysql主服务器配置 第一步:修改/etc/my.cnf文件: 在[mysqld]段下添加: datadir=/var/lib/mysql 默认数据存储目录 server-id=1 主机唯一id log-bin=/var/lib/mysql/mysqlbin 启用二进制日志 log-error=/var/log/mysqld.log pid-file=/var/run/mysqld/mysqld.pid binlog-do-db=boot_security 设置需要复制的数据库 binlog-ignore-db=mysql 设置不要复制的数据库 binlog_format=STATEMENT 设置logbin格式 第二步:重启mysql服务 systemctl mysqld restart 第三步:建立帐户并授权slave mysql> GRANT REPLICATION SLAVE ON *.* TO 'sendcode'@'%' IDENTIFIED BY '123456'; #一般不用root帐号,“%

mycat分库分表

て烟熏妆下的殇ゞ 提交于 2019-12-01 18:42:51
系统开发中,数据库是非常重要的一个点。除了程序的本身的优化,如:SQL语句优化、代码优化,数据库的处理本身优化也是非常重要的。主从、热备、分表分库等都是系统发展迟早会遇到的技术问题问题。Mycat是一个广受好评的数据库中间件,已经在很多产品上进行使用了。希望通过这篇文章的介绍,能学会Mycat的使用。 安装 Mycat官网: http://www.mycat.io/ 可以了解下Mycat的背景和应用情况,这样使用起来比较有信心。 Mycat下载地址: http://dl.mycat.io/ 官网有个文档,属于详细的介绍,初次入门,看起来比较花时间。 下载: 建议大家选择 1.6-RELEASE 版本,毕竟是比较稳定的版本。 安装: 根据不同的系统选择不同的版本。包括linux、windows、mac,作者考虑还是非常周全的,当然,也有源码版的。(ps:源码版的下载后,只要配置正确,就可以正常运行调试,这个赞一下。) Mycat的安装其实只要解压下载的目录就可以了,非常简单。 安装完成后,目录如下: 目录 说明 bin mycat命令,启动、重启、停止等 catlet catlet为Mycat的一个扩展功能 conf Mycat 配置信息,重点关注 lib Mycat引用的jar包,Mycat是java开发的 logs 日志文件,包括Mycat启动的日志和运行的日志。 配置

mysql集群(二)

吃可爱长大的小学妹 提交于 2019-12-01 17:36:47
4、mysql-proxy完成负载均衡与读写分离 1、基于程序代码内部实现 在代码中对select操作分发到从库;其它操作由主库执行;这类方法也是目前生产环境应用最广泛,知名的如DISCUZ X2。优点是性能较好,因为在程序代码中实现,不需要增加额外的设备作为硬件开支。缺点是需要开发人员来实现,运维人员无从下手。 2、基于中间代理层实现 代理一般是位于客户端和服务器之间,代理服务器接到客户端请求后通过判断然后转发到后端数据库。在这有两个代表性程序 mysql-proxy:mysql-proxy为mysql开源项目,通过其自带的lua脚本进行sql判断,虽然是mysql官方产品,但是mysql官方并不建议将mysql-proxy用到生产环境。 amoeba:由陈思儒开发,作者曾就职于阿里巴巴,现就职于盛大。该程序由java语言进行开发,目前只听说阿里巴巴将其用于生产环境。另外,此项目严重缺少维护和推广(作者有个官方博客,很多用户反馈的问题发现作者不理睬) 经过上述简单的比较,通过程序代码实现mysql读写分离自然是一个不错的选择。但是并不是所有的应用都适合在程序代码中实现读写分离,像大型SNS、 B2C这类应用可以在代码中实现,因为这样对程序代码本身改动较小;像一些大型复杂的java应用,这种类型的应用在代码中实现对代码改动就较大了。所 以,像这种应用一般就会考虑使用代理层来实现。

MYSQL 读写分离

帅比萌擦擦* 提交于 2019-12-01 17:04:36
基于mysql社区版5.7,使用软件:maxScale代理软件。 ​ 读写分流的好处在于当公司业务量达到一定量的时候,单机数据库实例负荷变得很大,如果在主从结构同步的结构基础上使用读写分离。将写操作分流到master节点实例,slave节点通过主从同步的设置也可以进行数据同步,将大量的查询操作转到slave从节点实例上。这样大大降低了主节点的负载,这样也提升了数据性能。 ​ 读写分离一般都有两种情况,第一种情况是来自软件开发的时候软件自己设计了读写分离的模式。第二种就是依靠软件来实现读写分离。maxScale就是通过解析SQL语句,实现了读写分离,应用程序不需要二次软件开发,大大降低了成本。 环境准备:maxScale:192.168.4.50 master1 192.168.4.53 slave1:192.168.4.54 slave2:192.168.4.55 首先检查备份环境是否主从是否正常 for i in 54 55 ;do ssh root@192.168.4.$i 'mysql -uroot -p1234 -e "show slave status \G" | grep IO_Running && mysql -uroot -p1234 -e "show slave status \G" | grep SQL_Running | head -1';done 看看应答

MySQL数据库分库分表策略

不打扰是莪最后的温柔 提交于 2019-12-01 16:40:18
第1章 引言 随着互联网应用的广泛普及,海量数据的存储和访问成为了系统设计的瓶颈问题。对于一个大型的互联网应用,每天几十亿的PV无疑对数据库造成了相当高的负载。对于系统的稳定性和扩展性造成了极大的问题。通过数据切分来提高网站性能,横向扩展数据层已经成为架构研发人员首选的方式。 水平切分数据库:可以降低单台机器的负载,同时最大限度的降低了宕机造成的损失; 负载均衡策略:可以降低单台机器的访问负载,降低宕机的可能性; 集群方案:解决了数据库宕机带来的单点数据库不能访问的问题; 读写分离策略:最大限度了提高了应用中读取数据的速度和并发量; 第2章 基本原理和概念 什么是数据切分 "Shard" 这个词英文的意思是"碎片",而作为数据库相关的技术用语,似乎最早见于大型多人在线角色扮演游戏中。"Sharding" 姑且称之为"分片"。Sharding 不是一个某个特定数据库软件附属的功能,而是在具体技术细节之上的抽象处理,是水平扩展(Scale Out,亦或横向扩展、向外扩展)的解决方案, 其主要目的是为突破单节点数据库服务器的 I/O 能力限制,解决数据库扩展性问题。 通过一系列的切分规则将数据水平分布到不同的DB或table中,在通过相应的DB路由或者table路由规则找到需要查询的具体的DB或者table,以进行Query操作。“sharding”通常是指“水平切分”

mysql中间件研究(Atlas,cobar,TDDL)

孤街醉人 提交于 2019-12-01 16:17:27
mysql-proxy是官方提供的mysql中间件产品可以实现负载平衡,读写分离,failover等,但其不支持大数据量的分库分表且性能较差。下面介绍几款能代替其的mysql开源中间件产品,Atlas,cobar,tddl,让我们看看它们各自有些什么优点和新特性吧。 Atlas Atlas是由 Qihoo 360, Web平台部基础架构团队开发维护的一个基于MySQL协议的数据中间层项目。它是在mysql-proxy 0.8.2版本的基础上,对其进行了优化,增加了一些新的功能特性。360内部使用Atlas运行的mysql业务,每天承载的读写请求数达几十亿条。 Altas架构: Atlas是一个位于应用程序与MySQL之间,它实现了MySQL的客户端与服务端协议,作为服务端与应用程序通讯,同时作为客户端与MySQL通讯。它对应用程序屏蔽了DB的细节,同时为了降低MySQL负担,它还维护了连接池。 以下是一个可以参考的整体架构,LVS前端做负载均衡,两个Altas做HA,防止单点故障。 Altas的一些新特性: 1.主库宕机不影响读 主库宕机,Atlas自动将宕机的主库摘除,写操作会失败,读操作不受影响。从库宕机,Atlas自动将宕机的从库摘除,对应用没有影响。在mysql官方的proxy中主库宕机,从库亦不可用。 2.通过管理接口,简化管理工作,DB的上下线对应用完全透明

mysql中间件研究(Atlas,cobar,TDDL)【转】

﹥>﹥吖頭↗ 提交于 2019-12-01 16:17:08
mysql-proxy是官方提供的mysql中间件产品可以实现负载平衡,读写分离,failover等,但其不支持大数据量的分库分表且性能较差。下面介绍几款能代替其的mysql开源中间件产品,Atlas,cobar,tddl,让我们看看它们各自有些什么优点和新特性吧。 Atlas Atlas是由 Qihoo 360, Web平台部基础架构团队开发维护的一个基于MySQL协议的数据中间层项目。它是在mysql-proxy 0.8.2版本的基础上,对其进行了优化,增加了一些新的功能特性。360内部使用Atlas运行的mysql业务,每天承载的读写请求数达几十亿条。 Altas架构: Atlas是一个位于应用程序与MySQL之间,它实现了MySQL的客户端与服务端协议,作为服务端与应用程序通讯,同时作为客户端与MySQL通讯。它对应用程序屏蔽了DB的细节,同时为了降低MySQL负担,它还维护了连接池。 以下是一个可以参考的整体架构,LVS前端做负载均衡,两个Altas做HA,防止单点故障。 Altas的一些新特性: 1.主库宕机不影响读 主库宕机,Atlas自动将宕机的主库摘除,写操作会失败,读操作不受影响。从库宕机,Atlas自动将宕机的从库摘除,对应用没有影响。在mysql官方的proxy中主库宕机,从库亦不可用。 2.通过管理接口,简化管理工作,DB的上下线对应用完全透明

NoSQL开篇——为什么要使用NoSQL

风格不统一 提交于 2019-12-01 15:52:44
http://nosql-database.org/ NoSQL在2010年风生水起,大大小小的Web站点在追求高性能高可靠性方面,不由自主都选择了NoSQL技术作为优先考虑的方面。今年伊始,InfoQ中文站有幸邀请到凤凰网的孙立先生,为大家分享他之于NoSQL方面的经验和体会。 非常荣幸能受邀在InfoQ开辟这样一个关于NoSQL的专栏,InfoQ是我非常尊重的一家技术媒体,同时我也希望借助InfoQ,在国内推动NoSQL的发展,希望跟我一样有兴趣的朋友加入进来。这次的NoSQL专栏系列将先整体介绍NoSQL,然后介绍如何把NoSQL运用到自己的项目中合适的场景中,还会适当地分析一些成功案例,希望有成功使用NoSQL经验的朋友给我提供一些线索和信息。 NoSQL 的分类 NoSQL仅仅是一个概念,NoSQL数据库根据数据的存储模型和特点分为很多种类。 类型 部分代表 特点 列存储 Hbase Cassandra Hypertable 顾名思义,是按列存储数据的。最大的特点是方便存储结构化和半结构化数据,方便做数据压缩,对针对某一列或者某几列的查询有非常大的IO优势。 文档存储 MongoDB CouchDB 文档存储一般用类似json的格式存储,存储的内容是文档型的。这样也就有有机会对某些字段建立索引,实现关系数据库的某些功能。 key-value存储 Tokyo Cabinet

MySQL主主+Keepalived实现高可用

[亡魂溺海] 提交于 2019-12-01 15:32:47
在企业中,数据库高可用一直是企业的重中之重,中小企业很多都是使用 mysql 主 主 方案,一主多从,读写分离等,但是单主存在单点故障,从库切换成主库需要作改动。因此,如果是双主或者多主,就会增加 mysql 入口,增加高可用。 不过多主需要考虑自增长 ID 问题,这个需要特别设置配置文件,比如双主,可以使用奇偶 , 总之,主之间设置自增长 ID 相互不冲突就能完美解决自增长 ID 冲突问题 主主方案实现思路 1、 两台 mysql 都可读写,互为主备 。 默认只使用一台 masterA 负责数据的写入,另一台 masterB 备用 处于备用状态 ; 2、 masterA 是 masterB 的主库, masterB 又是 masterA 的主库,它们互为主从; 3、 两台主库之间做高可用 , 可以采用 keepalived 等方案 , 使用 VIP 对外提供服务; 4 、 所有提供服务的从服务器与 masterB 进行主从同步(双主多从) ; 5 、 建议采用高可用策略的时候, masterA 或 masterB 均不因宕机恢复后而抢占 VIP (非抢占模式); 这样做可以在一定程度上保证主库的高可用 , 在一台主库 down 掉之后 , 可以在极短的时间内切换到另一台主库上 , 尽可能减少主库宕机对业务造成的影响,减少了主从同步给 生产 主库带来的压力; 实验步骤: