FAQ - 常见问题

发布于 2016-10-18 12:45:13 | 346 次阅读 | 评论: 0 | 来源: PHPERZ

• 问: 这里没有我想问的问题和答案, 我应该怎么办?

答: 我推荐所有人通过学习文档和使用自己大脑思考来回答自己的问题.

如果你经过学习文档, 并且进行充分思考后, 仍然无法得到答案, 你可以到 Github 上提 issue.

注意, 作为一个技术产品的用户, 一个互联网工作者, 甚至是一个程序员, 你应该学会基本的提问技能. 如果你的提问没有得到回答, 那么责任不在被问者, 而在于你自己, 你自己没有像个正常的技术人那样正确地提问.

运维

• 问: 我在进行压测(或者导数据), 起了1000个线程(或进程)来写数据, 为什么隔一会就会阻塞?

答: 如果你在短时间大量写数据(例如压测, 导几十G的数据), 就会如此. 设计如此, 你无法改变, 只能规避. 规避的方法是自己减慢导数据的速度, 同时在连接时, 设置更大的超时时间. 另外, 你还可以更换成性能更快的硬盘.

• 问: 为什么我在本机可以访问 SSDB 服务器, 在其它机器却不能呢? 提示 Connection refused.

答: 默认的配置文件基于安全考虑, 只开放给本机访问. 如果你想开放给网络上的其它 IP 访问, 请按文档 配置 修改配置.

• 问: 为什么并发数上不去? 服务器报错 Too many open files, 客户端报错 Connection reset by peer.

答: 请参考文档 配置 进行配置.

• 问: 我把一个, 两个, 或者所有的 key 都删除了, 为什么 SSDB 占用的内存和磁盘空间并没有释放?

答: SSDB 有自己策略来决定何时释放或者是否释放内存和硬盘占用, 你不能要求 SSDB 立即或者在未来某个时间, 或者基于某个条件 释放这些空间. 而且, 即使数据库清空了, SSDB 仍然会保留一些信息, 因此仍然占用部分硬盘空间. 你不应该关心这个问题.

• 问: 为什么 SSDB 偶尔会使用 100% CPU?

答: SSDB 偶尔使用 100% CPU 是完全正常的, 请不要大惊小怪. 这是因为 SSDB/LevelDB 在进行数据库整理(Compaction)操作, 持续的时间一般随着数据变大而变长, 一般只持续数秒.

• 问: 为什么 SSDB 偶尔会使用较多磁盘 IO?

答: SSDB 偶尔使用较多磁盘 IO 是完全正常的, 请不要大惊小怪. 这是因为 SSDB/LevelDB 在进行数据库整理(Compaction)操作, 持续的时间一般随着数据变大而变长, 一般只持续数秒.

• 问: 为什么 SSDB 偶尔会使用较多内存空间, 然后又降下来?

答: SSDB 使用的内存空间是变动的, 可能忽高忽低. 使用的内存空间的上限在文档 配置 中有描述.

• 问: Compaction 时服务会有稍微变慢, 我能设定 Compaction 执行的时间吗?

答: 很遗憾, 你不能设定 Compaction 在何时执行, SSDB/LevelDB 有自己策略和机制, 决定何时应该进行 Compaction. 根据大多数用户的使用反馈, Compaction 对服务没有任何影响.

• 问: 我原来的配置文件中没有打开压缩选项(compression: no), 我能中途把 compression 改为 yes 吗?

答: 是的, 你可以在任何时候修改 compression 选项, 只要你重启 ssdb-server, 新的修改就能生效. 更改后, 原来的数据依然兼容, 不会有任何问题.

• 问: 我开启了压缩选项, 但 SSDB 的硬盘占用并没有变小, 这是怎么回事?

答: 无论你开启或者关闭压缩选项, 只要重启后, 新的选项就已经生效了. 但是, 新的选项不一定立即影响原来的旧数据, SSDB 会在合适的时候将新选项应用于旧数据, 你无法控制这一点.

• 问: 我的 SSDB 实例莫名其妙就退出了, 请问是什么原因?

答: 进程莫名退出, 一般是如下原因:

1. max open files配置
2. 硬件内存不足, 操作系统内核kill掉进程, cat /var/log/messages | grep 'Out of'
3. 程序bug
4. 其它的

命令和用法

• 问: 有命令可以知道 SSDB 中存储的 key 总数吗?

答: 如果你想统计的是 KV 的数量, 那么, 在一开始时, 你就要把所有 KV 都放在同一个 HASH 中, 然后通过 hsize 命令就可以得到 key 的数量了. 如果一开始你没有这么做, 或者你想统计 KV 以外的数量, 那么答案很简单 - 没有这样的单个命令(除非你自己写脚本遍历统计).

• 问: SSDB 支持 key 查找吗? 支持通配符 * 模糊查找吗?

答: SSDB 支持, 且仅支持前缀查找, 也就是类似a*这样的查找, 而不支持 *a, *a* 或者其它的模糊查找. 具体用法请参见命令: scan, hlist, keys, hkeys, hscan, zlist, zkeys, zscan, qlist 的文档.

注意, 这些命令都要求你省略 * 号!

• 问: SSDB 不支持 sets 集合吗? Redis 的 sadd, sdiff 等求交集, 并集命令我都用不了了?

答: SSDB 不支持 sets, 以后也不太可能支持, 因为有替代方案. 你可以用 hash 来替代 sets, 因为一个 hash 的 key 是唯一的, 可以实现集合的特性. 至于交集, 并集等操作, 你只能自己实现. 例如, 求交集, 你可以遍历第一个 hash 的 key, 然后和第二个 hash 对比, 把结果存入第三个 hash.

• 问: 我的 key 是数字, 为什么在 SSDB 里不是按数字大小排序的?

答: 非常多的人在这里遇到不解, 这主要是没有深刻意识到, SSDB 是按 key 的字节顺序排序(字符串比较顺序), 我们平常认为 2 小于 100, 但是, 如果是字符串, 2 是大于 100 的, 因为字符串比较顺序是从左到左逐个字节进行比较.

为了达到你想要的效果, 你可以给数字加上 0 作为前缀, 补齐为固定长度的字符串, 例如把 2 变为 002, 那么 002 就小于 100, 符合你的预期. 一般来说, 要根据你的具体情况选择要补齐的最终长度.

配置

• 问: 我用 Twemproxy 配置 SSDB 做负载均衡和集群, 但是当我用 ssdb-cli 连接 Twemproxy 时, 会报错, 为什么?

答: 因为 Twemproxy 不支持 SSDB 网络协议, 所以, 你只能使用 redis-cli 连接 Twemproxy. 注意, 你可以用 ssdb-cli 或者 redis-cli 连接 SSDB, 那是因为 SSDB 支持两种协议, 而 Twemproxy 只支持一种.

• 问: 如何在一台机器上部署多个 SSDB 实例?

答: 每一个实例使用不同的配置文件进行启动, 而且, 配置文件里的 work_dir server.port 不能相同, 也就是每个实例的数据库存储路径, 以及监听端口. 如果 pidfile logger.output 使用的是绝对路径, 也要保证不能相同, 如果是相对路径, 由不需要, 因为默认跟随 work_dir 而不同了.

主从同步

• 问: 对于多主, 或者主从集群, 如何恢复数据?

答: 对于多主, 或者主从集群, 恢复数据时以及集群的维度来恢复. 具体步骤是:

1. 部署一个空数据的集群(也就是说, 所有节点必须不包含任何数据)
2. 把备份的数据导入集群中的一台master(如有多master, 也只一台)

• 问: 我想给主从集群新加入一台新的从节点(slave), 应该如何操作?

答: 方法有两种, 根据你的情况选择:

1. 启动一台空的节点, 在启动前, 配置其指向 master 即可. 这种方案最简单.
2. 这种方案比较复杂, 你需要非常小心进行, 不要操作的时候和你的理解出现偏差! 这种方案是, 选择原来的一个 slave 节点, 停止它. 然后将这个节点的 meta data 两个目录连同配置文件复制到新机器, 然后启动新节点.

• 问: 我的 master 占用的硬盘空间是 100G, 但 slave 只占用 30G, 是不是有问题?

答: 主和从占用的硬盘空间不一致, 甚至相差很多, 不能得出有问题的结论. 如果你认为有问题, 你需要通过硬盘占用之外的其它信息来发现问题.

• 问: 我 Bla bla bla 说了一堆废话, 为什么主从没有同步?

答: 确定主从是否同步的唯一方法是:

同步和复制的配置与监控  执行 info 命令, 判断 binlogs.max_seq 和 replication.client.last_seq 是否相等.

• 问: 我有双主: A 和 B, 如果我同时往 A 和 B 上更新同一个 key...

答: 停! SSDB 禁止你这么做! 你不能往多个节点写同一个 key, 你必须自己将 key 哈希到唯一的一个节点上, 保证对这个 key 的操作只会永远落在这个节点上.