redis主从复制-从机上缺少数据

Question

问题

主Redis DB设置信息

我有一个在10.1.1.1上运行的主程序。配置设置为“保存”到磁盘。下面是配置文件的一个片段：

save 900 1
save 300 10
save 60 10000

当我对所讨论的散列运行扫描命令时，以下是结果（正确）：

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

下面是我在slave 1中的数据：（缺少一条记录）

127.0.0.1:6379> scan 0 match dep:*
1) "15"
2) 1) "dep:[phone]_00:00_00:00"
   2) "dep:[phone]_19:00_25: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: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设置

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

127.0.0.1:6379> scan 0 match dep:*
1) "3"
2) 1) "dep:[phone]_00:00_00:00"
   2) "dep:[phone]_08:00_12:00"
127.0.0.1:6379> 

# 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

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

编辑2

这是另一个非常有趣的发现（至少对我来说）。我刚加了一个新项目的主人，就像这样：

127.0.0.1:6379> HMSET dep:[phone]_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:[phone]_00:00_00:00"
   2) "dep:[phone]_19:00_25:00"
   3) "dep:[phone]_15:00_18:45:00"
   4) "dep:[phone]_08:00_12:00"
127.0.0.1:6379> 

现在，当我再次检查slave one时，它仍然只有2条记录，但它删除了一条以前存在的记录，并用我刚才添加的新记录替换了它：

127.0.0.1:6379> scan 0 match dep:*
1) "7"
2) 1) "dep:[phone]_00:00_00:00"
   2) "dep:[phone]_15:00_18:45:00"
127.0.0.1:6379> 

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

127.0.0.1:6379> scan 0 match dep:* count 3
1) "10"
2) 1) "dep:[phone]_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:[phone]_15:00_18:45:00"
127.0.0.1:6379> scan 7 match dep:* count 3
1) "0"
2) 1) "dep:[phone]_19:00_25:00"
   2) "dep:[phone]_08:00_12:00"
127.0.0.1:6379> 

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

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

Answer 1

您还没有迭代Redis实例中的所有键。

为了进行完整的迭代，您应该继续将SCAN命令与返回的游标一起发送给Redis，直到返回的游标为0。

在上一个示例中：

127.0.0.1:6379> scan 0 match dep:*
1) "7"    <---- returned cursor
2) 1) "dep:[phone]_00:00_00:00"
   2) "dep:[phone]_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"

从您的问题描述来看，我认为您应该将您的数据存储在Redis的哈希结构中，并使用hkeys、hgetall或hscan来获取数据：

hset dep:[phone]:00_00:00:00 value
hset dep:[phone]:00_18:45:00 value
hkeys dep:[phone]    <----- get all fields in this hash
hgetall dep:[phone]  <----- get all fields and values in this hash
hscan dep:[phone]  <----- scan the hash to key fields

这应该比遍历整个密钥空间效率高得多。特别是，如果散列中没有太多字段，hkeys和hgetall可以在一次拍摄中获得所有键/数据，而且非常快。但是，如果哈希中的字段太多，则仍然需要使用hscan进行迭代。