问题
我有一种情况，我在主服务器上创建的数据似乎没有正确复制到我的从服务器。
掌握 Redis 数据库设置信息
我有一个运行在 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:+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 设置
Slave 1 已设置为仅在内存中运行。所以在配置文件中，所有的“保存”选项都被注释掉了。
这是我在 slave 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>
当我在这个从站上运行“信息”命令时，这是我得到的结果:(只选择了我认为可能与这个问题有关的特定项目)
# 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
这是我在 slave 2 上的数据(注意它缺少数据，但与 slave 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
在检查 slave 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 slaves连接master超时怎么恢复？我也想知道这个错误是什么意思“部分重新同步不可能(没有缓存的主)”。
目前正在谷歌搜索...但如果您有任何意见，请随时
编辑 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>
现在，当我再次检查 slave one 时，它仍然只有 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 中使用扫描命令？想象一下，用户将请求小部件信息......我需要查询此哈希以找到 key 。 感觉这种类型的迭代效率很低。 KEYS 命令也可以使用，但根据文档，我不应该在生产中使用它，因为它会影响性能。 任何意见/见解将不胜感激。
最佳答案
您还没有迭代 Redis 实例中的所有键。
为了进行完整的迭代，您应该继续发送 SCAN使用返回的游标向 Redis 命令，直到返回的游标为 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 命令的计数 只是一个提示。无法保证 Redis 应该准确返回 count number 结果(有关详细信息，请参阅 the doc)。
为了一次获得所有 key ，您可以使用KEYS 命令。但是，正如您提到的，这不是一个好主意(它可能会长时间阻塞 Redis)，这就是为什么 Redis 有这个 SCAN 命令来获取迭代中的所有键。
SCAN 和KEYS 命令都会遍历整个 key 空间以找到匹配项。因此，如果数据集非常大，它们都需要很长时间才能获取/迭代所有键。
根据您的问题描述，我认为您应该将数据存储在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 进行迭代。
关于redis master slave replication - 从站上丢失数据，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/39794849/