怎么配置读写分离

Ⅰ 一台服务器，怎么实现数据库的读写分离

方法1 ：里面建立两个数据库实例，一个作写，一个作读
方法2:服务器上建两个虚拟机，一个虚拟机放写数据库，一个放读数据库
方法3:服务器上放写数据库，再建一个虚拟机放写数据库
----------------------
实现方法:
数据库之间同步，然后修改代码读写分别指向相应的数据库，就可以了。

Ⅱ 怎么实现读写分离

为了确保数据库产品的稳定性，很多数据库拥有双机热备功能。也就是，第一台数据库服务器，是对外提供增删改业务的生产服务器；第二台数据库服务器，主要进行读的操作。·
读写分离（Read/Write Splitting）。
1.原理：让主数据库（master）处理事务性增、改、删操作（INSERT、UPDATE、DELETE），而从数据库（slave）处理SELECT查询操作。
2.诞生原因：
2.1 为了确保数据库产品的稳定性，很多数据库拥有双机热备功能。也就是，第一台数据库服务器，是对外提供增删改查业务的生产服务器；第二台数据库服务器，仅仅接收来自第一台服务器的备份数据（注意，不同数据库产品，第一台数据库服务器，向第二台数据库服务器发送备份数据的方式不同）。当第一台数据库崩溃后，第二台数据库服务器，可以立即上线来代替第一台数据库服务器，并且，在第一台数据库服务器崩溃后，宝贵的数据，依然会存在于第二台数据库服务器里（根据目前业界的备份数据发送方式来看，当第一台数据库崩溃后，第一台数据库里的仍然会有少量的新数据，没能来得及被发送到第二台数据库服务器，所以，这部分数据就丢失了）。
2.2 一般来说，为了配置方便，以及稳定性，这两台数据库服务器，都用的是相同的配置（思考一下，如果两台服务器的配置不同，会导致什么结果）。
2.3 从上文的描述中，大家能看到，在实际运行中，第一台数据库服务器的压力，远远大于第二台数据库服务器。因此，很多人希望合理利用第二台数据库服务器的空闲资源。那么，第二台数据库服务器能做些什么事情呢？
2.4 从数据库的基本业务来看，数据库的操作无非就是增删改查这4个操作。但对于“增删改”这三个操作，如果是双机热备的环境中做，一台机器做了这三个操作的某一个之后，需要立即将这个操作，同步到另一台服务器上。单向的同步，不复杂。但如果两台机器都需要向对方进行同步，那逻辑就非常复杂，而且还会大大降低性能。（从保证ACID特性的角度，思考一下为什么双向同步会非常复杂且低性能？而单向同步却不会？）出于这个原因，第二台备用的服务器，就只做了查询操作。进一步，为了降低第一台服务器的压力，干脆就把查询操作全部丢给第二台数据库服务器去做，第一台数据库服务器就只做增删改了。
2.4 到这一步，就实现了所谓的读写分离。这样做，缺点也非常明显了。本来第二台数据库服务器，是用来做热备的，它就应该在一个压力非常小的环境下，保证运行的稳定性。而读写分离，却增加了它的压力，也就增加了不稳定性。因此，读写分离，实质上是一个在资金比较缺乏，但又需要保证数据安全的需求下，在双机热备方案上，做出的一种折中的扩展方案。
简单实现
通过RAID技术，RAID是英文Rendant Array of Independent Disks的缩写，翻译成中文意思是“独立磁盘冗余阵列”，有时也简称磁盘阵列（Disk Array）。
简单的说，RAID是一种把多块独立的硬盘（物理硬盘）按不同的方式组合起来形成一个硬盘组（逻辑硬盘），从而提供比单个硬盘更高的存储性能和提供数据备份技术。

Ⅲ Redis早期的主从架构原理分析，早期如何实现读写分离的

基于主从复制架构，实现读写分离，redis slave node节点只读，默认开启配置：slave-read-only yes。开启了只读的节点redis slave node，会拒绝所有写操作，这样可以强制搭建成读写分离的架构。

（1）redis采用异步方式复制数据到slave节点。

（2）一个master node是可以配置多个slave node的。

（3）slave node也可以连接其他的slave node。

（4）slave node做复制的时候，是不会block master node的正常工作的。

（5）slave node在做复制的时候，也不会block对自己的查询操作，它会用旧的数据集来提供服务; 但是复制完成的时候，需要删除旧数据集，加载新数据集，这个时候就会暂停对外服务了。

（6）slave node主要用来进行横向扩容，做读写分离，扩容的slave node可以提高读的吞吐量。

如果采用了主从架构，那么建议必须开启master node的持久化！不建议用slave node作为master node的数据热备，因为那样的话，如果你关掉master的持久化，可能在master宕机重启的时候数据是空的，然后可能一经过复制，salve node数据也丢了。

（1）当启动一个slave node的时候，它会发送一个 PSYNC 命令给master node。

（2）如果这是slave node 重新连接 master node，那么master node仅仅会 复制给slave部分缺少的数据 ，否则如果是slave node 第一次连接 master node，那么会触发一次 full resynchronization ，master会启动一个后台线程，开始生成一份RDB快照文件，同时还会将从客户端收到的所有写命令 缓存在内存中 。RDB文件生成完毕之后，master会先将这个RDB发送给slave，slave会先写入本地磁盘，然后再从本地磁盘加载到内存中。然后master会将内存中 缓存的写命令 发送给slave，slave也会同步这些数据。

（3）slave node如果跟master node有网络故障，断开了连接，会自动重连。master如果发现有多个slave node都来重新连接，仅仅会启动一个rdb save操作，用一份数据服务所有slave node。

从redis 2.8开始，就支持主从复制的断点续传，如果主从复制过程中，网络连接断掉了，那么可以接着上次复制的地方，继续复制下去，而不是从头开始复制。master node会在内存中建一个 backlog ，master和slave都会保存一个 replica offset 还有一个 master id（run id） ，offset就是保存在backlog中的。如果master和slave网络连接断掉了，slave会让master从上次的replica offset开始继续复制，但是如果没有找到对应的offset，那么就会执行一次full resynchronization全量同步。

master在内存中直接创建rdb，然后发送给slave，不会在自己本地落地磁盘了。

repl-diskless-sync no 改为开启就可以了

repl-diskless-sync-delay，等待一定时长再开始复制，因为要等更多slave重新连接过来，用一分数据提供服务。

slave node不会过期key，只会等待master过期key。如果master过期了一个key，或者通过LRU淘汰了一个key，那么会模拟一条del命令发送给slave。

（1）slave node启动，仅仅保存master node的信息，包括master node的host和ip，但是复制流程没开始。master host和ip是从哪儿来的？redis.conf里面的slaveof配置的。

（2）slave node内部有个定时任务，每秒检查是否有新的master node要连接和复制，如果发现，就跟master node建立socket网络连接。

（3）slave node发送ping命令给master node。

（4）口令认证，如果master设置了requirepass（master上启用安全认证配置，requirepass 自己取名 ），那么salve node必须发送masterauth的口令过去进行认证（masterauth 自己取名 ）

（5）master node第一次执行全量复制，将所有数据发给slave node。

（6）master node后续持续将写命令，增量异步复制给slave node。

指的就是第一次slave连接msater的时候，执行的全量复制，这个过程里面的一些细节的机制

（1）master和slave都会维护一个offset

master会在自身不断累加offset，slave也会在自身不断累加offset。slave每秒都会上报自己的offset给master，同时master也会保存每个slave的offset。这个倒不是说特定就用在全量复制的，主要是master和slave都要知道各自的数据的offset，才能知道互相之间的数据不一致的情况。

（2）backlog

master node有一个backlog，默认是1MB大小，master node给slave node复制数据时，也会将数据在backlog中同步写一份。backlog主要是用来做全量复制中断后的增量复制的。

（3）master run id

info server命令，可以看到master run id。如果根据host+ip定位master node，是不靠谱的，如果master node重启或者数据出现了变化，那么slave node应该根据不同的run id区分，run id不同就做全量复制。如果需要不更改run id重启redis，可以使用redis-cli debug reload命令。

（4）psync

从节点使用psync从master node进行复制psync runid offset。master node会根据自身的情况返回响应信息，可能是FULLRESYNC runid offset触发全量复制，可能是继续触发增量复制。

（1）master执行bgsave，在本地生成一份rdb快照文件。

（2）master node将rdb快照文件发送给salve node，如果rdb复制时间超过60秒（repl-timeout），那么slave node就会认为复制失败，可以适当调节大这个参数。

（3）对于千兆网卡的机器，一般每秒传输100MB，6G文件，很可能超过60s。

（4）master node在生成rdb时，会将所有新的写命令缓存在内存中，在salve node保存了rdb之后，再将新的写命令复制给salve node。

（5）client-output-buffer-limit slave 256MB 64MB 60，如果在复制期间，内存缓冲区持续消耗超过64MB，或者一次性超过256MB，或复制时间超过60秒，那么停止复制，复制失败。

（6）slave node接收到rdb之后，然后重新加载rdb到自己的内存中，同时基于旧的数据版本对外提供服务，写入后，清空自己的旧数据，用新的对外提供读服务。

（7）如果slave node开启了AOF，那么会立即执行BGREWRITEAOF，重写AOF。在这个过程中，rdb生成、rdb通过网络拷贝、slave旧数据的清理、slave node aof rewrite，很耗费时间的。

（1）如果全量复制过程中，master-slave网络连接断掉，那么salve重新连接master时，会触发增量复制。

（2）master直接从自己的backlog中获取部分丢失的数据，发送给slave node，默认backlog就是1MB。

（3）master就是根据slave发送的psync中的offset来从backlog中获取数据的。

下节讲解哨兵架构，在讲之前，你能否处理下面两个问题呢？

1、异步复制导致的数据丢失

哨兵可以解决主从架构下，因master宕机后不能接收写请求而进行选举salve为新的master，达到高可用的效果。

因为master -> slave的复制是异步的，所以可能有部分数据还没复制到slave，master就宕机了，此时这些部分数据就丢失了，此时应该怎么处理？

2、脑裂导致的数据丢失

脑裂，也就是说，某个master所在机器突然脱离了正常的网络，跟其他slave机器不能连接，但是实际上master还运行着。

此时哨兵可能就会认为master宕机了，然后开启选举，将其他slave切换成了master这个时候，集群里就会有两个master，也就是所谓的脑裂。

此时虽然某个slave被切换成了master，但是可能client还没来得及切换到新的master，还继续写向旧master的数据可能也丢失了，因此旧master再次恢复的时候，会被作为一个slave挂到新的master上去，自己的数据会清空，重新从新的master复制数据，导致数据丢失，怎么处理脑裂导致的数据丢失呢？

先考虑一下，我们下节进行讲解。

Ⅳ mysql 如何实现读写分离，用mysql-proxy 或者直接用php连接两个数据库

Mysql主从配置，实现读写分离
原理：主服务器（Master）负责网站NonQuery操作，从服务器负责Query操作，用户可以根据网站功能模特性块固定访问Slave服务器，或者自己写个池或队列，自由为请求分配从服务器连接。主从服务器利用MySQL的二进制日志文件，实现数据同步。二进制日志由主服务器产生，从服务器响应获取同步数据库。
具体实现：
1、在主从服务器上都装上MySQL数据库，windows系统鄙人安装的是mysql_5.5.25.msi版本，Ubuntu安装的是mysql-5.6.22-linux-glibc2.5-i686.tar
windows安装mysql就不谈了，一般地球人都应该会。鄙人稍微说一下Ubuntu的MySQL安装，我建议不要在线下载安装，还是离线安装的好。大家可以参考 http://www.linuxidc.com/Linux/2013-01/78716.htm 这位不知道大哥还是姐妹，写的挺好按照这个就能装上。在安装的时候可能会出现几种现象，大家可以参考解决一下：
（1）如果您不是使用root用户登录，建议 su - root 切换到Root用户安装，那就不用老是 sudo 了。
（2）存放解压的mysql 文件夹，文件夹名字最好改成mysql
（3）在./support-files/mysql.server start 启动MySQL的时候，可能会出现一个警告，中文意思是启动服务运行读文件时，忽略了my.cnf文件，那是因为my.cnf的文件权限有问题，mysql会认为该文件有危险不会执行。但是mysql还会启动成功，但如果下面配置从服务器参数修改my.cnf文件的时候，你会发现文件改过了，但是重启服务时，修改过后的配置没有执行，而且您 list一下mysql的文件夹下会发现很多.my.cnf.swp等中间文件。这都是因为MySQL启动时没有读取my.cnf的原因。这时只要将my.cnf的文件权限改成my_new.cnf的权限一样就Ok，命令：chmod 644 my.cnf就Ok
（4）Ubuntu中修改文档内容没有Vim，最好把Vim 装上，apt-get install vim,不然估计会抓狂。
这时候我相信MySQL应该安装上去了。
2、配置Master主服务器
（1）在Master MySQL上创建一个用户‘repl’，并允许其他Slave服务器可以通过远程访问Master，通过该用户读取二进制日志，实现数据同步。

Ⅳ Redis启用主从模式做读写分离

可以通过部署2台Redis服务器， 一台主，一台从。然后写的操作在主库，读的操作可以在从库。进行主从同步即可。

这样就可以，一台写，多台从，所有读的请求全部在从库那边操作。增强Redis的并发能力。

主从配置，比较简单。

直接去 从服务器 那边，修改配置文件redis.conf。

修改salveof 指向 主服务器

如果主服务器有配置访问密码，则还需要配置masterauth 属性。

主服务器不用做什么修改。

主从都启动好后， 可以使用redis客户端来查看redis的主从情况。

进行读写分离的话， 还需要使用哨兵来管理Redis的集群。 让哨兵来判断读写是从哪台服务器。

对哨兵配置文件进行配置，参考配置解释如下

以下是比较常用的配置信息，使用这些配置可以启动起来， 再根据实际的情况，去增加配置。

3台哨兵，使用同样的配置就可以了，哨兵们就会自动互相发现哨兵和slave了。 基本上就是配置了master的信息。 哨兵可以同时监控多个master，那是另外的Redis集群的架构了。

配置完成后，启动各个哨兵后， 可以使用redis的客户端链接哨兵来查看各个结点和哨兵的信息。

下面是多个哨兵的信息，但是不包含自己当前操作的哨兵信息。

在项目配置里面，配置连接去哨兵集群即可。

Ⅵ mysql如何做读写分离啊

我刚给公司做完mysql的主从读写分离
先给你个思路
第一步：先做mysql的主从（Master/Slave Replication），实现数据同步
第二部：通过Amoeba来实现读写分离，也可以通过mysql proxy（比较麻烦）。
ps：
我的环境是两台装windows server 2008，一台做主，一台做从。
如果你需要的话，留下邮箱，我发给你一个我自己刚做好的文档。照着做就可以了

Ⅶ spring怎么实现读写分离

1. 配置两个连接池，一个读，一个写

2. 写个Service层或者（DAO层也行）的aop，读操作使用读的连接，写用写的连接实现分离

希望可以帮到你

Ⅷ 数据库主从配置，怎么弄，读写分离那些

读写分离为了确保数据库产品的稳定性，很多数据库拥有双机热备功能。
也就是，第一台数据库服务器，是对外提供增删改业务的生产服务器；
第二台数据库服务器，主要进行读的操作。·
原理：
让主数据库（master）处理事务性增、改、删操作（INSERT、UPDATE、DELETE），而从数据库（slave）处理SELECT查询操作。
实现方式：
通过RAID技术，RAID是英文Rendant Array of Independent Disks的缩写，翻译成中文意思是“独立磁盘冗余阵列”，有时也简称磁盘阵列（Disk Array）。
简单的说，RAID是一种把多块独立的硬盘（物理硬盘）按不同的方式组合起来形成一个硬盘组（逻辑硬盘），从而提供比单个硬盘更高的存储性能和提供数据备份技术。

Ⅸ c#mongo 怎么设置读写分离

mongodb的读写分离使用Replica Sets来实现 对于replica set 中的secondary 节点默认是不可读的。在写多读少的应用中，使用Replica Sets来实现读写分离。通过在连接时指定或者在主库指定slaveOk，由Secondary来分担读的压力，Primary只承担写操作...

Ⅹ mysql读写分离,我怎么设置让那一台读哪一台写,还是说设置好主从默认就是主是读

根据要求配置MySQL主从备份、读写分离，结合网上的文档，对搭建的步骤和出现的问题以及解决的过程做了如下笔记;
现在使用的两台服务器已经安装了MySQL,全是rpm包装的，能正常使用。
为了避免不必要的麻烦，主从服务器MySQL版本尽量保持一致;
环境:192.168.0.1 (Master)
192.168.0.2 (Slave)
MySQL Version:Ver 14.14 Distrib 5.1.48, for pc-linux-gnu (i686) using readline 5.1
server-id = 1 //数据库ID号， 为1时表示为Master,其中master_id必须为1到232–1之间的一个正整数值;
log-bin=mysql-bin //启用二进制日志;
binlog-do-db=data //需要同步的二进制数据库名;
binlog-ignore-db=mysql //不同步的二进制数据库名;这个同步后听说很麻烦，我没有同步;
log-bin=/var/log/mysql/updatelog //设定生成的log文件名;
log-slave-updates //把更新的记录写到二进制文件中;
slave-skip-errors //跳过错误，继续执行复制;
2、建立复制所要使用的用户;
mysql>grant replication slave on *.* to identified by '********'
3、重启mysql;
/usr/bin/mysqladmin -uroot shutdown;
/usr/bin/mysql_safe &
4、现在备份Master上的数据;
锁定后我直接tar.gz data这个库文件;
mysql>FLUSH TABLES WITH READ LOCK;
cd /var/lib/mysql
tar data.tar.gz data
接着直接执行了远程scp;
scp ./data.tar.gz
5、登录Slave数据库服务器，修改my.cnf;
server-id = 3 //2已经被用在另一个服务器上了，如果以后要再加Slave号接着往后数就OK了;