-
Notifications
You must be signed in to change notification settings - Fork 508
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
云厂商支持情况确认 #659
Comments
首先几个基础的问题:
阿里云的实现是Tair,是支持Redis原生同步协议的,腾讯云的你要问下他们客服,是否支持Redis原生通信。 我建议是你把背景写的更详细一些,比如为什么有多个版本,不同云厂商你是怎么用的,同步是为了解决什么问题?这些其实和x-pipe关系不大,倒是和解决你的问题比较有关。 |
@NickNYU 我们情况是这样的: 公司业务至今存在有十多年了,这十多年间先后购买了不同版本的Redis,属于历史问题。大部分业务线都在阿里云,小部分在腾讯云。 我们目前规划是统一所有的Redis版本为5.0,把低于5.0的版本都升级到5.0版本。云厂商的低版本Redis是支持升级到5.0版本的,但升级后是不支持再回滚到原低版本的。 我们评估用x-pipe,主要是期望:在低版本Redis升级到5.0版本后,当业务发现异常且短时间内不能解决时,通过x-pipe把高版本的Redis的全量+增量数据同步至另一个新的低版本的Redis,进而达到Redis版本回滚的目的。 我们用的云厂商Redis是高可用版本的,但其自带的哨兵是没有提供访问地址的,上面想确认的是哨兵对x-pipe来说是不是必须要有的组件呢 谢谢 ~ |
@callmedba 哨兵不是必须的,但是如果云厂商有哨兵的话,会导致切换以后,备机房的Redis会从keeper(x-pipe同步组件)的slave,切换成master,从而无法同步数据。
|
好的 了解了 多谢 ~ 对于双写可能涉及业务上的改造,可能还会带来更多的不确定性,以及升级周期的延长,目前暂不考虑 需要进行高版本升级的Redis数量近100个,但最终需要实施版本回滚的Redis数量可能很少,甚至个位数 目前偏向于选择一个类似x-pipe的组件,在异常情况出现时,短时间内把高版本Redis数据同步至低版本中,业务侧可以接受Redis部分数据在短时间内的不一致,借助云厂商5.0版本Redis提供的写日志API,在业务回滚至低版本Redis后进行事后补偿 |
@callmedba 那可能不太行,问题的本质在于full sync的RDB文件无法向下兼容 解决方案是你找一个Redis RDB的解析、转换工具,而且还需要改造xpipe,让xpipe的keeper拉取完RDB之后,可以完成从高版本到低版本的转换,才可以redis 5.x 同步给 redis 2.x。 |
嗯 是的 感谢大佬指点 @NickNYU |
@NickNYU 做法是在解析rdb时判断目标redis版本,再根据解析的结果生成一个低版本的dump格式,再restore到目标端 |
我们的Redis分布在阿里云和腾讯云,有标准主从版,也有集群版。有2.8,3.0,4.0,5.0等各个版本。云厂商的跨Reids间同步工具DTS不支持低版本Redis。
请问当前x-pipe对各个云厂商的Redis产品支持的如何呢?能否借助x-pipe实现云Redis5.0版本同步到云Redis2.8版本呢 ?目的是用来做大版本升级后的异常回滚
在Wiki中看到答疑说需要部署哨兵,这个哨兵是必须要部署的一个组件吗?
谢谢
The text was updated successfully, but these errors were encountered: