PSync

前言 在前面的两篇文章中，分别介绍了 Redis的内存模型 和 Redis的持久化 。 在Redis的持久化中曾提到，Redis高可用的方案包括持久化、主从复制（及读写分离）、哨兵和集群。其中持久化侧重解决的是Redis数据的单机备份问题（从内存到硬盘的备份）；而主从复制则侧重解决数据的多机热备。此外，主从复制还可以实现负载均衡和故障恢复。 这篇文章中，将详细介绍Redis主从复制的方方面面，包括：如何使用主从复制、主从复制的原理（重点是全量复制和部分复制、以及心跳机制）、实际应用中需要注意的问题（如数据不一致问题、复制超时问题、复制缓冲区溢出问题）、主从复制相关的配置（重点是repl-timeout、client-output-buffer-limit slave）等。 系列文章 深入学习Redis（1）：Redis内存模型 深入学习Redis（2）：持久化 深入学习Redis（3）：主从复制 深入学习Redis（4）：哨兵 深入学习Redis（5）：集群 目录 一、主从复制概述 二、如何使用主从复制 1. 建立复制 2. 实例 3. 断开复制 三、主从复制的实现原理 1. 连接建立阶段 2. 数据同步阶段 3. 命令传播阶段 四、【数据同步阶段】全量复制和部分复制 1. 全量复制 2. 部分复制 3. psync命令的执行 4. 部分复制演示 五、【命令传播阶段】心跳机制 1.

背景 　　最近在负责公司数据Oracle转PG；老平台数据库：Oracle11g；新平台数据库：PostgreSQL12。由于平台统计规则有变动；所以正在推广的游戏数据无法全部迁移过来；只能在老平台上运行。而支付数据接口升级；统一进入新平台数据PG。需要将部分支付数据由PostgreSQL同步到Oracle。 　　简而言之：PostgreSQL增量同步表到Oracle。首先声明我不是反“去IOE”潮流。我想到两种方案 采用OGG 可以参考 OGG For Oracle To PostgreSQL 采用外部表+脚本/存储过程 一、安装Oracle客户端 1、下载地址 http: //www.oracle.com/technetwork/database/database-technologies/instant-client/overview/ index.html 2 、 安装步骤 2.1 创建安装目录 [root @Postgres201 ~] # mkdir -p /u01/app/ [root@Postgres201 ~] # cd /u01/app/ 2.2 上传软件包并解压 [root @Postgres201 app] # unzip instantclient-basic-linux.x64-11.2.0.4.0.zip [root@Postgres201 app]

原文出处： Java 技术驿站 『 chenssy 』 在前面持久化文章中（ 【死磕 Redis】--- 持久化 ）阐述了，单台服务器是如何保证数据安全性的，它保证了即使 Redis 服务器因为宕机而重启也不会丢失数据，因为他将内存中的数据持久化到硬盘中了，在重启的时候只需要重新加载即可，但是如果硬盘坏了呢？是不是就没救了，就算硬盘没坏，你去重启 Redis 应用，服务不可用得产生多发的负面影响？所以我们应该尽量避免这种因为单点故障而导致 Redis 服务不可用的情况。 Redis 单机部署一般存在如下几个问题： 机器故障，导致 Redis 不可用，数据丢失 容量瓶颈：容量不能水平扩展 QPS 瓶颈：一台机器的处理能力、网络宽带总是有限的，如果能够划分一些流量到其他机器，可以有效解决 QPS 问题 Redis 提供的主从复制功能，实现了一份数据存在多个相同的副本，它是实现 Redis 高可用的基础，作用有如下几个： 数据冗余：主从复制实现了数据的热备份，是 Redis 持久化之外的一种数据冗余方式 故障恢复：当主节点出现故障时，可以将从节点晋升为主节点继续提供服务，实现快速的故障恢复 读写分离：主从复制可以实现读写分离，主节点写，从节点读，读写分离提高了服务器的负载能力 高可用的基石：主从复制是哨兵和集群能够实施的基础，因此说主从复制是 Redis 高可用的基础 配置主从复制

Key（键） DEL DUMP EXISTS EXPIRE EXPIREAT KEYS MIGRATE MOVE OBJECT PERSIST PEXPIRE PEXPIREAT PTTL RANDOMKEY RENAME RENAMENX RESTORE SORT TTL TYPE SCAN String（字符串） APPEND BITCOUNT BITOP DECR DECRBY GET GETBIT GETRANGE GETSET INCR INCRBY INCRBYFLOAT MGET MSET MSETNX PSETEX SET SETBIT SETEX SETNX SETRANGE STRLEN Hash（哈希表） HDEL HEXISTS HGET HGETALL HINCRBY HINCRBYFLOAT HKEYS HLEN HMGET HMSET HSET HSETNX HVALS HSCAN List（列表） BLPOP BRPOP BRPOPLPUSH LINDEX LINSERT LLEN LPOP LPUSH LPUSHX LRANGE LREM LSET LTRIM RPOP RPOPLPUSH RPUSH RPUSHX Set（集合） SADD SCARD SDIFF SDIFFSTORE SINTER SINTERSTORE SISMEMBER

 这节介绍Redis的主从复制过程,包括建立和复制。 1.复制的建立 1.1 SLAVEOF命令  Redis支持主从模式以提供读写分离，可以通过在从服务器的客户端上执行如下命令以连接主服务器： SLAVEOF IP PORT 或者在配置文件中配置SLAVEOF选项。 1.2 建立过程  SLAVEOF命令包括以下几个步骤： 从服务设置主服务器的地址和端口，从服务器会保存客户端上送的地址和端口。 从服务器同主服务器建立套接字连接。 从服务器向主服务器发送PING命令，通过判断响应是否为PONG或者有没超时，以检查套接字连接是否正常和主服务器能否正常处理命令请求。 身份验证。主服务器的requirepass选项和从服务器的masterauth选项用于身份验证，必须同时设置或者同时去除，才能让身份验证通过（或者不进行身份证验证）。 发送端口信息。  从服务器通过 REPLCONF listening-port 从服务器端口 命令向主服务器发送自己的监听端口号。主服务器收到命令后会将信息进行存储，用于后续INFO replication命令的输出。 执行同步。  从服务器向主服务器发送同步命令，复制主服务器上的数据使之保持一致。 命令传播。  同步完成后，主服务器会一直将自己执行的写命令发送给从服务器以保持同步。在这个过程，从节点会以每秒一次的频率，向主节点发起心跳检测，以保证连接的正常

Redis Cluster 集群 redis集群有以下几种方式 普通一主多从 普通一主多从+哨兵 cluster分片模式 一主多从 搭建方式网上很多，就不多描述了。 这种集群方式，一般master用作写，slave用做读，用来做读写分离，slave的数据从master同步。 这种情况下，由于master只有一个，所有容灾性不新，如果master挂掉之后，slave不能自动升级成master对外提供服务。而且master还是否挂掉， 这个问题也不好得知。 这个时候我们可能就需要获取master的状态，并且在master挂掉的情况下能够自动将其中一个slave自动升级成master，继续对外提供服务，因此哨兵就来了。 一主多从+哨兵（Sentinel） 哨兵是在一主多从的基础上，增加对redis服务器的监控，并在down机时自动将其中一个slave升级成master，这也就是哨兵的作用。 哨兵本质上只是一个运行在特殊模式下的Redis服务器。哨兵的启动 redis-sentinel /path/sentinel.conf 或者 redis-server /path/sentinel.conf --sentinel 初始化服务器 使用sentinel专用代码 初始化sentinel状态 初始化sentinel状态的masters属性 创建连向主服务器的网络连接

前言 只有光头才能变强 好的，今天我们要上铂金段位了，如果还没经历过青铜和白银和黄金阶段的，可以先去蹭蹭经验再回来： 从零单排学Redis【青铜】 从零单排学Redis【白银】 从零单排学Redis【黄金】 这篇文章主要讲的是 Redis主从复制 。因为Redis集群的知识点有点多，所以铂金上分得要好几篇~ 文本 力求简单讲清每个知识点 ，希望大家看完能有所收获 一、主从架构 1.1为什么要主从架构 Redis也跟关系型数据(MySQL)一样，如果有过多请求还是撑不住的。 因为Redis如果只有一台服务器的话，那随着请求越来越多： Redis的内存是有限的 ，可能放不下那么多的数据 单台Redis 支持的并发量也是有限的 。 万一这台Redis挂了 ，所有的请求全走关系数据库了，那就更炸了。 显然，出现的上述问题是因为一台Redis服务器不够，所以多搞几台Redis服务器就可以了 为了实现我们服务的 高可用性 ，可以将这几台Redis服务器做成是 主从 来进行管理 tip:Redis作者已将Master/Slave架构改名为Master/Replica 1.2主从架构的特点 下面我们来看看Redis的主从架构特点： 主 服务器负责接收 写 请求 从 服务器负责接收 读 请求 从服务器的数据由主服务器 复制 过去。主从服务器的数据是 一致 的 主从架构的 好处 ： 读写分离

1、主从架构的核心原理 当启动一个slave node的时候，它会发送一个PSYNC命令给master node 如果这是slave node重新连接master node，那么master node仅仅会复制给slave部分缺少的数据; 否则如果是slave node第一次连接master node，那么会触发一次full resynchronization 开始full resynchronization的时候，master会启动一个后台线程，开始生成一份RDB快照文件，同时还会将从客户端收到的所有写命令缓存在内存中。RDB文件生成完毕之后，master会将这个RDB发送给slave，slave会先写入本地磁盘，然后再从本地磁盘加载到内存中。然后master会将内存中缓存的写命令发送给slave，slave也会同步这些数据。 slave node如果跟master node有网络故障，断开了连接，会自动重连。master如果发现有多个slave node都来重新连接，仅仅会启动一个rdb save操作，用一份数据服务所有slave node。 2、主从复制的断点续传 从redis 2.8开始，就支持主从复制的断点续传，如果主从复制过程中，网络连接断掉了，那么可以接着上次复制的地方，继续复制下去，而不是从头开始复制一份 master node会在内存中常见一个backlog