redis主从复制 - 从属上缺少数据答案

【问题标题】：redis master slave replication - missing data on the slaveredis主从复制 - 从属上缺少数据
【发布时间】：2016-10-01 15:17:51
【问题描述】：

问题

我有一种情况，我在主服务器上创建的数据似乎没有正确地复制到我的从服务器。

主 Redis 数据库设置信息

我有一个在 10.1.1.1 上运行的主服务器。配置设置为“保存”到磁盘。这是配置文件中的一个 sn-p：

save 900 1
save 300 10
save 60 10000

当我对有问题的哈希运行扫描命令时，结果如下（正确）：

127.0.0.1:6379> scan 0 match dep:*
1) "13"
2) 1) "dep:+19999999999_00:00_00:00"
   2) "dep:+19999999999_19:00_25:00"
   3) "dep:+19999999999_08:00_12:00"
127.0.0.1:6379>

从站 1 设置

从站 1 已设置为仅在内存中运行。所以在配置文件中，所有的“保存”选项都被注释掉了。

这是我在从站 1 中的数据：（缺少一条记录）

127.0.0.1:6379> scan 0 match dep:*
1) "15"
2) 1) "dep:+19999999999_00:00_00:00"
   2) "dep:+19999999999_19:00_25:00"
127.0.0.1:6379>

当我在这个slave上运行“info”命令时，我得到的结果是：（只选择了我认为可能与这个问题有关的特定项目）

# Replication
role:slave
master_host:10.1.1.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:5
master_sync_in_progress:0
slave_repl_offset:346292
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

#Stats
expired_keys:0

#Persistence
aof_enabled:0

从属 2 设置

Slave 2 也应该只是一个内存数据存储。所以配置文件中的所有保存选项也都被注释掉了：

#save 900 1
#save 300 10
#save 60 10000

这是我在从站 2 上的数据（请注意，它缺少数据，但与从站 1 的记录不同）

127.0.0.1:6379> scan 0 match dep:*
1) "3"
2) 1) "dep:+19999999999_00:00_00:00"
   2) "dep:+19999999999_08:00_12:00"
127.0.0.1:6379>

info 命令的一些结果：

# Replication
role:slave
master_host:10.1.1.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:3
master_sync_in_progress:0
slave_repl_offset:346754
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

#Stats
expired_keys:0

#Persistence
aof_enabled:0

这是我第一次尝试使用 REDIS，所以我确信这是我错过的一些简单的东西。我还没有尝试在从属服务器上重新启动 REDIS，因为我不想丢失任何可能帮助我排除故障/了解我最初是如何到达这里的工件。

任何建议将不胜感激。

编辑 1

在检查从站 2 上的日志时，我发现：

4651:S 27 Sep 18:39:27.197 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
4651:S 27 Sep 18:39:27.197 # Server started, Redis version 3.0.5
4651:S 27 Sep 18:39:27.197 * The server is now ready to accept connections on port 6379
4651:S 27 Sep 18:39:27.198 * Connecting to MASTER 10.1.1.1:6379
4651:S 27 Sep 18:39:27.198 * MASTER <-> SLAVE sync started
4651:S 27 Sep 18:40:28.284 # Timeout connecting to the MASTER...
4651:S 27 Sep 18:40:28.284 * Connecting to MASTER 10.1.1.1:6379
4651:S 27 Sep 18:40:28.284 * MASTER <-> SLAVE sync started
4651:S 27 Sep 18:41:29.369 # Timeout connecting to the MASTER...
4651:S 27 Sep 18:41:29.369 * Connecting to MASTER 10.1.1.1:6379
4651:S 27 Sep 18:41:29.369 * MASTER <-> SLAVE sync started
4651:S 27 Sep 18:42:00.452 * Non blocking connect for SYNC fired the event.
4651:S 27 Sep 18:42:00.453 * Master replied to PING, replication can continue...
4651:S 27 Sep 18:42:00.453 * Partial resynchronization not possible (no cached master)
4651:S 27 Sep 18:42:00.463 * Full resync from master: b46c3622e4ef4c5586ebd2ec23eabcb04c3fcf32:1
4651:S 27 Sep 18:42:00.592 * MASTER <-> SLAVE sync: receiving 173 bytes from master
4651:S 27 Sep 18:42:00.592 * MASTER <-> SLAVE sync: Flushing old data
4651:S 27 Sep 18:42:00.592 * MASTER <-> SLAVE sync: Loading DB in memory
4651:S 27 Sep 18:42:00.592 * MASTER <-> SLAVE sync: Finished with success

redis slave连接master超时时如何恢复？我也想知道这个错误是什么意思“部分重新同步不可能（没有缓存的主）”。

目前正在谷歌搜索...但如果您有任何 cmets，请随意

编辑 2

这是另一个非常有趣的发现（至少对我而言）。我刚刚添加了一个新的项目master，像这样：

127.0.0.1:6379> HMSET dep:+19999999999_15:00_18:45:00 ext 2222 dd me.net days "fri"
OK
127.0.0.1:6379> scan 0 match dep:*
1) "13"
2) 1) "dep:+19999999999_00:00_00:00"
   2) "dep:+19999999999_19:00_25:00"
   3) "dep:+19999999999_15:00_18:45:00"
   4) "dep:+19999999999_08:00_12:00"
127.0.0.1:6379>

现在，当我再次检查从机时，它仍然只有 2 条记录，但它删除了一条曾经存在的记录，并用我刚刚添加的新记录替换它：

127.0.0.1:6379> scan 0 match dep:*
1) "7"
2) 1) "dep:+19999999999_00:00_00:00"
   2) "dep:+19999999999_15:00_18:45:00"
127.0.0.1:6379>

编辑 3

从下面的答案来看，SCAN 命令返回的第一个数字似乎是光标中的一个位置......在阅读文档时，我可以指定一个计数来指示要返回的记录数。但这仍然给我提出了一些问题。例如，根据下面的答案，我在从机上尝试了以下 SCAN 命令：

127.0.0.1:6379> scan 0 match dep:*
1) "7"
2) 1) "dep:+19999999999_00:00_00:00"
   2) "dep:+19999999999_15:00_18:45:00"
127.0.0.1:6379> scan 7 match dep:*
1) "0"
2) 1) "dep:+19999999999_19:00_25:00"
   2) "dep:+19999999999_08:00_12:00"
127.0.0.1:6379>

这对我来说很有意义......它似乎一次返回 2 条记录（仍然需要弄清楚如何更改此默认值）

根据这篇帖子 - Redis scan count: How to force SCAN to return all keys matching a pattern? - ，我可以使用“count”关键字来表示要返回多少条记录。

但为了获得我拥有的所有 4 条记录，我必须在光标值返回为零之前运行几个查询......我不知道为什么。例如：

127.0.0.1:6379> scan 0 match dep:* count 3
1) "10"
2) 1) "dep:+19999999999_00:00_00:00"
127.0.0.1:6379> scan 10 match dep:* count 3
1) "3"
2) (empty list or set)
127.0.0.1:6379> scan 3 match dep:* count 3
1) "7"
2) 1) "dep:+19999999999_15:00_18:45:00"
127.0.0.1:6379> scan 7 match dep:* count 3
1) "0"
2) 1) "dep:+19999999999_19:00_25:00"
   2) "dep:+19999999999_08:00_12:00"
127.0.0.1:6379>

为什么第一个请求没有返回 3 条记录？在我看来，我最多应该运行这个扫描命令 2 次。你能解释一下这里发生了什么吗？

另外，也许我不应该在我的节点 js REST API 中使用扫描命令？想象一下，一个用户将请求小部件信息......我需要查询这个哈希来找到密钥。感觉这种类型的迭代效率很低。 KEYS 命令也可以工作，但根据文档，我不应该在生产中使用它，因为它会影响性能。任何 cmets / 见解将不胜感激。

【问题讨论】：

标签： redis replication database-replication master-slave node-redis

【解决方案1】：

您尚未从 Redis 实例中迭代所有键。

为了进行一次完整的迭代，你应该继续向 Redis 发送 SCAN 命令和返回的游标，直到返回的游标为 0。

在你的最后一个例子中：

127.0.0.1:6379> scan 0 match dep:*
1) "7"    <---- returned cursor
2) 1) "dep:+19999999999_00:00_00:00"
   2) "dep:+19999999999_15:00_18:45:00"
127.0.0.1:6379> 
// here, you need continue sending scan command with the returned cursor, i.e. 7
127.0.0.1:6379> scan 7 match dep:*
// then you can get more results from Redis
// If the full iteration is finished, it should return something like this:
1) "0"    <----- this means the full iteration is finished
2) 1) "dep:more result"
   2) "dep:last result"

编辑

SCAN 命令的count number 只是一个提示。无法保证 Redis 应该准确返回 count number 结果（有关详细信息，请参阅 the doc）。

为了一次性获取所有键，您可以使用KEYS 命令。但是，正如您所提到的，这不是一个好主意（它可能会阻塞 Redis 很长时间），这就是 Redis 有这个 SCAN 命令来获取迭代中的所有键的原因。

SCAN 和 KEYS 命令都会遍历整个键空间以找到匹配项。因此，如果数据集非常大，它们都需要很长时间才能获取/迭代所有键。

根据您的问题描述，我认为您应该将数据存储在 Redis 的HASH 结构中，并使用HKEYS、HGETALL 或HSCAN 来获取数据：

hset dep:+19999999999 00:00_00:00:00 value
hset dep:+19999999999 15:00_18:45:00 value
hkeys dep:+19999999999    <----- get all fields in this hash
hgetall dep:+19999999999  <----- get all fields and values in this hash
hscan dep:+19999999999 0  <----- scan the hash to key fields

这应该比遍历整个键空间更有效。特别是，如果散列中没有太多字段，HKEYS 和HGETALL 可以一次性获取所有键/数据，而且速度非常快。但是，如果哈希中的字段过多，您仍然需要使用HSCAN进行迭代。

【讨论】：

哇。谢谢！我没有意识到这一点。那么有没有办法一举搞定一切呢？还是控制每次迭代返回的记录数？
stackoverflow.com/questions/33166812/…
@Happydevdays 我更新了答案。也许你应该使用HASH 来提高性能。