为什么redis-port出现连不上redis的时候也要退出 about redis-port

[spinlock]

redis-port 就是一个迁移工具，遇到不能处理的问题及时退出没有问题呀。

主要原因还是，redis-port 默认使用的 sync 协议，每次建立连接都是全量同步。假设第一次同步全量是 A，第二次同步全量是 B。那么 redis-port 需要在第二次同步前清空后面的 codis 以避免 A-B ≠ ∅ 带来的数据不同步。但是 codis 不支持 flushdb/flushall 。。。咋办。。。

此外，如果有需要，redis-port 支持 psync，简单的网络异常会遵循 psync 协议重试的。

[spinlock]

psync 的意思是继续上次 sync 中断的位置继续。如果发现中断太久无法继续，psync 协议会重新全量 sync，这时候 redis-port 也会退出。和上面是同一个理由。

[cyflhn]

像遇到网络异常特别是一开始建立连接的时候，以及遇到读，写超时的时候我觉得加上重试应该更加好一点吧，数据同步就应该是一次头的过程，所以我觉得中间不要有中断。如果确实出现需要进行重新sync，也可以打错误日志，是否终止同步由使用者来决定。如果遇到异常就退出，运维要抱怨死了，怪我们写的程序健壮性不够。

[yangzhe1991]

我个人觉得这个迁移工具本来就应该是运维操作的不应该是写程序的人用吧？

[yangzhe1991]

举个极端例子，网络很不靠谱，不断自动重试，redis不断sync，不断的bgsave，会卡死的……

[cyflhn]

运维人员就怕程序莫名其妙挂掉，重试的时间间隔可以控制一下，总之是否需要重新sync交给使用者就可以了，使用者能通过日志及时发现问题，及时处理，可以根据实际情况选择是否停止程序，个人觉得这样挺好。

[yangzhe1991]

离线工具怎么搞都行吧，写一个不断重试的程序 或者 写一个出错就挂的程序+一个不断重试的脚本 其实是一个意思。后者反而更可控

[spinlock]

"所以我觉得中间不要有中断"，不是 redis-port 想中断，是网络中断。网络中断以后，redis-port 没有办法继续下去了，即便进行下去已经没有办法做到同步了，所以只能退出。

即便不退出最后运维发现，也只能 杀掉->_清空_->重新同步。

而且 redis-port 退出的时候有 log。已经把错误和异常保留下来了。还有就是，如果是运维人员的需求的话，可不可以运维写两行代码 wait redis-port 的返回值。正常情况下 redis-port 永不退出，否则退出并 exit(1)，我相信运维这点技能还是有的。

此外，redis-port 支持 psync，如果强调网络中断，请使用 psync。

针对你说的重试，我需要强调一下，增加间隔重试也没有办法保证一致性。所以只能退出。我觉得大多数情况下，一致性比运维操作重要。如果运维真的想重试，请写脚本重启 redis-port

[cyflhn]

今天进行数据迁移，真的碰到退出的情况，原因是发生eof了，我看了代码，只有在恢复rdb文件的时候才使用了并发操作，这时候一旦发生错误(目标端网络问题)，进行重试不会造成数据不一致的情况吧。毕竟这时候是读取当前的rdb文件，后续的命令还没有写到rdb文件中吧。我用脚本重启同步实在是麻烦，每次同步到一般挂了，又要重新同步。

[yangzhe1991]

我用脚本重启同步实在是麻烦

这个应该一点也不麻烦？

[cyflhn]

我说的麻烦不是说写脚本烦 是每次同步到一半 报错 又要重新同步

[cyflhn]

我今天下午已经同步了3次 都没成功 都是eof

[yangzhe1991]

eof的原因是什么？应该不是网络不稳吧？同步目标的proxy那边有log吗？

[cyflhn]

有 broken pipe 连接目标redis报的错 我改成重试应该没问题吧，我进度来不及了

[cyflhn]

肯定tcp层面的问题，但是不是持久性的，但是这个问题必须要跨越过去啊

[spinlock]

我的建议是，先不要这么大火气。这仅仅是一个工具，而且是 free 的。

1. 如果确定是同步 rdb 的过程出现异常，你可以尝试在自己的分支上进行修复：重新建立连接，重新执行 slotsrestore 指令（或者是 restore 指令）。这种情况很少见，而且这个项目仅仅是 codis 的一个周边工具，并不是主要项目，所以我们应该不会再花费人力在这种错误上了。
2. 同步 rdb 过程并发的原因是：a. redis.Do 是同步操作，所以会有 ping-pong 的开销，b. 虽然同步量很大，但是指令之间没有依赖关系。而后续指令的同步需要保证同步顺序，但是通过不同 routine 分别进行 读和写操作使得 pipeline 同步速度足够满足需要了，如果不能满足，只能说明 master 写入太快，再快的同步也没有办法。这仅仅是一点解释，顺道提一下。
3. 如果你确定是 redis-port 到 slave 之间的同步失败的话，解释一下：broken pipe 应该是 send request 出错，eof 是 receive response 出错。无论何种错误，都是 redis-port 和 slave 之间的网络异常。我们开发这个工具的初衷是解决 twemproxy 集群迁移到到 codis 集群，跨机房的同步操作我们不建议这么做，也没有成熟的解决方案，同时也不能保证 rdb 同步完成之后，后续指令的同步不出现异常而崩溃。因为很多操作如 incr 是非幂等的，届时你仍然需要清掉 slave 数据重新同步。
4. 我怀疑你是 master 和 redis-port 之间网络环境好，而 slave 和 redis-port 之间网络环境不好。我建议，你修改一下同步方式，master 和 redis-port 之间使用 --psync 协议 + sockfile，而 redis-port 和 slave 部署在同一个机器或者机房内。这样 redis-port 内部实现了简单的 psync 协议，在 rdb 同步完成之后，有一定的容错能力，而 redis-port 和 slave 之间带宽足够大。而且，使用 sockfile 之后，消耗不了多少内存，而且能够增加从 master 的同步速度。
5. 别生气，有什么问题可以再商量。

[cyflhn]

不好意思 我没有生气啊， 我后来仔细查了一下 应该不是网络问题 我用tcpdump抓了一下包 发现在restore的时候报了Protocol error: invalid bulk length，然后tcp连接就断了。我发现是在同步一个hash值的时候报错，这个hash对应的value很长。我上传一下附件，麻烦帮忙看看，谢谢了。大家都是做技术的，希望共同进步啊。再说一遍，真的没有生气的。

[cyflhn]

我看了redis的代码。这个报错应该是
ok = string2ll(c->querybuf+pos+1,newline-(c->querybuf+pos+1),&ll);
if (!ok || ll < 0 || ll > 512_1024_1024) {
addReplyError(c,"Protocol error: invalid bulk length");
setProtocolError(c,pos);
return REDIS_ERR;
}
所以我怀疑是不是这个restore指令太长了

麻烦尽快帮忙看下，谢谢了

这里附上tcp流：
*1

$4

PING

+PONG

*1

$4

PING

+PONG

*4

$12

slotsrestore

$18

REC_SWR_SPROD_FREE

$1

0

$774056667

...h...;#).710848405,695750932.Y.c,1712227135,726708825,758280625,756055965,756507925.7..(.@q@w.736899845,67286371 ..65507135,712[email protected] ..343465 '[email protected] E ?.60087 ..0726 3 O.79927052 Y.9604702...5(@w665289182,666217202,761642305,691810065,650981025,687481202,669365305,758401925,720056145,702570092,666630602,672112312..[.$@w710204755,725486785,682347455,717392485,731738395,753822375,744744225,620493104,747572705,767330835,694983682,757054765....).@[email protected],670780775,[email protected] ..6345194 ..043286 ..64568521.56@
..2309733 [email protected] c.7 &.16565...>)....,.....@w718411425,718332665,763781785,702123725,694325322,750579915,716988475,698791052,686961245,668153435,683676622,610416254.j(.'.683747195,769439455,761701975....$@w728024445,620227652,673774835,756705085,741623495,760489425,711662465,649133075,673012052,675166941,718581145,608893484..0D,.@r@w.746071395,75414451 [email protected] ..5405712 . %@0 ..55062465,685653152,72 [email protected] ..636 O.02,693689192...A$@w760649955,726829435,761667995,722069885,683623615,675550171,635493845,703635625,752407645,752673935,714495405,754531845.o.,@w727381785,725174145,690921175,608512982,739987055,731863855,768378755,767143475,769575895,682899825,753395065,747945675...B-@w735731345,750874055,750408275,748959305,704199795,678887682,739439335,720987285,754849665,740642995,755410015,723515455..k.'@w695765155,670036365,710107305,705606465,720362125,612201384,676911762,691128005,670111835,702580222,693529532,685539882..p.)'755633795,692980602,699342432,759761495.C
.'@w745868665,639418935,678167532,670912152,749730845,687061342,613586515,706419385,767489005,685062862,759581005,618240802..P.'."&A(....(@w762697175,706257765,731462055,745038545,718269675,722683535,763194395,746449225,751563095,724638265,693277822,702491035..e.@w674945892,664153255,667114252,697190702,625934985,698043312,746620165,768693905,701340482,621081294,702901935,724560215.PI.(@w400034637,666189132,677784221,684918112,704000962,689577532,666463222,698094412,651054865,674429492,103202479,667701012....(@w743610855,686534042,707240845,746527475,711470505,667714541,732205505,662849541,692936702,690737242,688569982,706749565..A.1667732235,727591835,622267692,690277402,670626902.<..$@w663047102,651546995,768537115,695986572,699182795,741840045,697034102,734341655,753850325,621093314,741681525,753465435.g..$@w698526692,670244602,747548395,743849975,696187162,722930295,650796585,746207455,670338172,730403985,750127665,687430652.
.y&@w683517225,617974175,661773055,749128705,698687435,641119095,729413085,615901162,764509895,703484232,768104405,643509245.5..'@w732992925,687082085,716555705,754021075,729655835,685905212,677032342,736266375,716707785,687607185,697113052,693595992...S$.@r@w.707985415,723669535,68708...07547144,76643558 '.60040@'.755008@;.63445012 ..80748042, [email protected] c.6 j.84622...)@w708159655,721883885,665495945,765678465,688260442,703960335,686069145,695537982,662186692,671393961,707505345,751027695....(@w639021615,644304115,754707825,662972285,749091455,732404055,712643035,700868302,680356982,708976765,713149565,687865992.#..(@w631672155,711520115,695107675,678679185,622386542,684336372,699928535,676928522,697799742,744689265,753071045,730227655...]+@w676025235,617812224,743046935,749259835,680071232,717498855,645895355,715666175,753400485,695922802,400147029,699297585.....683983342,684846332.(TX(...](.SJ.(@w697928292,707523225,714966875,643951345,640559125,692181215,675312795,641709535,737441815,727661635,698283305,722876025.[..+.696476422,724795225,683320542...4(@w609919901,724855365,703890612,612129122,679958702,675458361,697467472,745959005,685544362,759695585,753535675,734279755.(S.(@w749053395,754293305,751409825,747225545,747390905,765283025,695820842,697025462,753868125,620916112,703543335,677738771....+.@q@w.749840725,696211232 [email protected],75535574 '[email protected] !.,6791279 ..701872 P [email protected].;.99206675..A.+.@q@w.693534742,726334035,75983665 [email protected] ..,[email protected] [email protected] . ;.4 :.1@;.2284429 '[email protected])...;)...<(.752202725,753513165.e..+@w734084885,755236845,697329372,730899205,749439595,754935195,671752072,748056255,761021205,748158765,738460555,718356975..0J_@w683049762,677502315,712354835,723989985,702768662,642684375,751453445,744031615,708907105,724278715,748843305,662743985.v.7$.@q@w.730079665,70
.4815,684032612,[email protected] '.362063 ' [email protected] ;[email protected]@E [email protected].'@O669269945,751476405,699872572,645400695,724338765,768216775,731660165,765285995.X.i)@w723884345,758075095,731329085,666201172,683416662,699628315,672580531,748380315,730203345,643081975,725270465,731587155...L(@w693828182,698204952,744518235,744360805,759510715,746563665,720725955,620239622,725280395,724363435,696262552,748094425.B..$@w664141245,688957465,631937975,679451282,725741295,697714795,740515555,727361295,748192345,682204862,706625615,711521235...V%@w662778962,671543265,661886892,725465175,606250564,734231855,736614905,606858475,726587055,733717945,760507695,720547555. Ez$@t700222685,713590715,678636062,740992235,618966905,698628535,665745995,236573,674023195,766920635,715590115,692563875.....@p@w.686611492,670050255,707029345,64.987687 [email protected]@..66652 [email protected]. U 1.2 '.1 Q.396 . . 2.25.,..$@Y743908925,695940515,741483225,679327991,702568172,617243622,665955632,701142812,702904942..[5).@[email protected],74778662 ..541334...95201..50984. 383235,6770 ..72,722609.1.6682@'.6310087 1.2683010 1.82858402..:.'@w759489565,731764045,724442595,701423032,769024445,735196685,692688242,674448052,745804795,650816005,757067565,744337375....(@w689395872,725089695,646022325,636434285,699999045,740265685,756656155,755796345,748566835,733028215,720203785,666328685.7..).@[email protected],720905285 ..4358855,687833912,6701 . 31,69850109 '.6282702 ..383 >;[email protected] O J.79605.Q..(.@r@w.694217465,755242695,62123227 ..1852151 ..6381815 [email protected] ..67545280 ..81645482 '.437 &...3 b ..02075752....+1759979135,684344182,685139972,745370315,764688555..W.'@w678168511,743751825,606691644,707950825,725353115,694932775,621214872,735392695,722414665,620263422,730003935,698780662..L.$.@r@w.754094255,751641605,67891153 ..87959042,72307746 '.2329522 ..09262...194048 ..6253939 ;.659273@;.4728 [email protected]....%@w674101292,748916835,746059255,757790215,737528345,762014235,685986312,700924132,687611602,756760175,691528842,744076295...9%@w609666194,739243115,695895212,732334875,759421725,714828655,765481025,671606151,646883225,686478002,744558125,766565035...@%@w685542902,745157535,664553135,701100152,763873295,713615365,648033625,664353595,666398865,721601785,730351255,684383225...Z%@w679709822,754646715,705585415,754634295,662903395,734920855,679040391,769947065,769475645,764562615,606691864,630659155....&.@q@w.736837265,72995932 [email protected],64230955 ..151584'.523153 ..73691352,7497578 ..7475 P;.607314@'.69 I.42..I,).@r@w.698548002,70313154 ..51561125,724911135,691220162,671.20667..76468 1.0412825 ..6347 . ;.655630;@..23 1.98 ..082....('725938455,701330542,751644805,753406945....@w745794425,679633845,684439175,67-ERR Protocol error: invalid bulk length

[spinlock]

OK，这么看的确是了。restore 指令是对单个 key-value 的操作，value 会被压缩成 rdb dump 格式。
你提到的这种情况属于单个 value 特别大的情况，参见 CodisLabs/codis#425 。

Redis 单个 bulk bytes 限制是 512M。所以单条 restore 指令是肯定出错的。

这种情况不属于 Codis 的应用场景。所以我们也不会进行特殊处理。

如果你十分需要这种情况的话，我可以给你的建议是修改代码，在 restore 前，将数据用 https://github.com/wandoulabs/redis-port/blob/master/pkg/rdb/decoder.go 内提供的 Decoder 转成 Hash 然后逐条 HSet。

[cyflhn]

请问下 这个为什么不是codis的应用场景，如果我有很多这样的key value，那怎么办？ 我现在要把老redis的数据散列到codis集群里面，这样key应该不少。 那redis做主从同步的时候是怎么处理的

[spinlock]

codis 主要应对的是多 key 但是单个 key-value 都不太大的场景。因为 codis 本质是将所有的 key 按照 hash 值分配到不同的 redis 实例中，在需要的时候能够对 key 进行迁移和重新分布。

codis 修改了 redis 实现，在里面增加了与 slot 有关的数据结构以及与 slot 迁移有关的操作。codis 在迁移的时候本质也是发送一条指令给 server-src，命令其将对应数据迁移到 server-dst 中去，迁移过程实际上也是通过 slotsrestore 完成的。

所以如果 redis-port 没有办法将数据同步到 codis 中去的话，当 codis 发生迁移时，codis 也没有办法完成将该数据从 server-src 迁移到 server-dst 的操作。同时，为了减少阻塞的的时间，codis 后面的 redis 实例在迁移过程的超时一般都设置成很小，现在的设置是3s，所以即便数据能装入单个 bulk 中，3s 内也很难保证 500M 数据迁移到目标实例中。

codis 为了保证操作的原子性，迁移实际上是按照 tag 迁移的，所以就要求有相同 tag 的数据总和不能太大。不然很容易超时。tag 的定义可以在 codis 的 doc 里面搜到。或者直接参考 twemproxy 的文档。

[cyflhn]

那如果迁移过程中超时了 那么在dashboard上能看到吗，会重试吗， 还有，像我这种场景应该怎么解决。

[Apache9]

codis的架构就决定了他处理不了单个key对应的value特别大的情况，按照我们经验，几兆大小的一个set或者list还可以忍，再大的话迁移的时候就很容易堵了，几百兆估计迁移都无法成功。如果完全不做迁移的话，这么用倒是也可以但这就失去用codis最大的意义了。

这种情况下如果想用codis，只能是修改代码。比较常见的办法是自己在代码里再做一次sharding，比如你hashkey对应的这个hash有1G大小，那么你把他拆成1024个小的hash，hashkey-0~hashkey-1023，那么每个hash的大小就差不多只有1M了，就可以使用codis了。具体怎么拆就需要看你自己的业务了。

谢谢

[cyflhn]

@Apache9 你说的改代码是指改哪部分的代码，改codis代理层，还是改codis redis部分的代码

[Apache9]

改你自己业务的代码。。。

[cyflhn]

我主要担心的是老数据的平滑迁移问题，新业务是不会出现这种大key-val情况的。改老业务代码代价太大了。

[Apache9]

那这个真不好办了。。。