Uh oh!
There was an error while loading. Please reload this page.
HBASE-24871 Replication may loss data when refresh recovered replicat… - #2249
Conversation
infraio
commented
Aug 12, 2020
Add a UT for this case? |
Apache-HBase
commented
Aug 12, 2020
🎊 +1 overall
This message was automatically generated. |
ddupg
commented
Aug 12, 2020
OK, I'll try it. |
Apache-HBase
commented
Aug 12, 2020
🎊 +1 overall
This message was automatically generated. |
Apache-HBase
commented
Aug 12, 2020
🎊 +1 overall
This message was automatically generated. |
huaxiangsun
commented
Aug 12, 2020
As @infraio said, it will be great to add an UT to show the issue w/o change. Otherwise, looks good to me. |
huaxiangsun
left a comment
There was a problem hiding this comment.
Add a UT for this case?
| this.oldsources.add(replicationSource); | ||
| for (SortedSet<String> walsByGroup : walsByIdRecoveredQueues.get(queueId).values()) { | ||
| walsByGroup.forEach(wal -> src.enqueueLog(new Path(wal))); | ||
| walsByGroup.forEach(wal -> replicationSource.enqueueLog(new Path(wal))); |
There was a problem hiding this comment.
So the problem is that logs from recovered queues were getting added to the new "normal" queue? And these logs are never read, then?
Nit: maybe worth rename the variable from line #516 from replicationSource to recoveredReplicationSource, for further clarity?
I endorse the call for an additional UT, here.
There was a problem hiding this comment.
So the problem is that logs from recovered queues were getting added to the new "normal" queue? And these logs are never read, then?
Yes. These log will be added to normal source. And will read by normal source. So this should not loss data but only affect the replicate order.
@ddupg I thought the issue title need to be changed.
There was a problem hiding this comment.
Thanks for clarifying, @infraio . Yes, let's change the title, please.
There was a problem hiding this comment.
Thank @wchevreuil@infraio for reviewing. In this case, it will loss data and duplicate data at the same time.
After we added these log to normal source, the normal source replicate the first WAL entries batch and updateLogPosition via zk.
It will successfully replicate first WAL entries batch, but data may be out-of date. And then failed to updateLogPosition in zk, which aborting RS, so we will also loss data.
Apache-HBase
commented
Aug 19, 2020
🎊 +1 overall
This message was automatically generated. |
Apache-HBase
commented
Aug 19, 2020
🎊 +1 overall
This message was automatically generated. |
Apache-HBase
commented
Aug 19, 2020
🎊 +1 overall
This message was automatically generated. |
Apache-HBase
commented
Aug 19, 2020
🎊 +1 overall
This message was automatically generated. |
Apache-HBase
commented
Aug 19, 2020
🎊 +1 overall
This message was automatically generated. |
Apache-HBase
commented
Aug 19, 2020
💔 -1 overall
This message was automatically generated. |
Apache-HBase
commented
Aug 20, 2020
🎊 +1 overall
This message was automatically generated. |
Apache-HBase
commented
Aug 20, 2020
🎊 +1 overall
This message was automatically generated. |
Apache-HBase
commented
Aug 20, 2020
🎊 +1 overall
This message was automatically generated. |
ddupg
commented
Aug 20, 2020
Thank @huaxiangsun for reviewing, I've added an UT for this case. |
huaxiangsun
commented
Aug 20, 2020
Thanks @ddupg. One quick question, will the new UT fail without changes in refreshSources()? Just want to make sure that the UT really does its job. +1 pending on your answer. |
huaxiangsun
left a comment
There was a problem hiding this comment.
Pending on the question I have for the new UT.
ddupg
commented
Aug 21, 2020
Yes, the UT fail without changes in this patch. Because it failed to updateLogPosition in zk after replicating first WAL edits batch, which aborting RS. |
huaxiangsun
commented
Aug 21, 2020
@infraio and @wchevreuil, any more comments before I merge the changes? Thanks. |
| !replication.getReplicationManager().getOldSources().isEmpty()); | ||
| // disable peer to trigger refreshSources | ||
| hbaseAdmin.disableReplicationPeer(PEER_ID2); |
There was a problem hiding this comment.
Which assert will failed if no this fix?
There was a problem hiding this comment.
The UT will timeout in last UTIL2.waitFor without this fix because of losing data.
Apache-HBase
commented
Aug 24, 2020
🎊 +1 overall
This message was automatically generated. |
Apache-HBase
commented
Aug 24, 2020
🎊 +1 overall
This message was automatically generated. |
Apache-HBase
commented
Aug 24, 2020
🎊 +1 overall
This message was automatically generated. |
…ion sources (#2249) Signed-off-by: huaxiangsun <huaxiangsun@apache.org> Signed-off-by: Guanghao Zhang <zghao@apache.org> Conflicts: hbase-server/src/main/java/org/apache/hadoop/hbase/replication/regionserver/ReplicationSourceManager.java
…ion sources (#2249) Signed-off-by: huaxiangsun <huaxiangsun@apache.org> Signed-off-by: Guanghao Zhang <zghao@apache.org> Conflicts: hbase-server/src/main/java/org/apache/hadoop/hbase/replication/regionserver/ReplicationSourceManager.java
…ion sources (#2249) Signed-off-by: huaxiangsun <huaxiangsun@apache.org> Signed-off-by: Guanghao Zhang <zghao@apache.org> Conflicts: hbase-server/src/main/java/org/apache/hadoop/hbase/replication/regionserver/ReplicationSourceManager.java Conflicts: hbase-server/src/main/java/org/apache/hadoop/hbase/replication/regionserver/ReplicationSourceManager.java
…ion sources (apache#2249) Signed-off-by: huaxiangsun <huaxiangsun@apache.org> Signed-off-by: Guanghao Zhang <zghao@apache.org> Conflicts: hbase-server/src/main/java/org/apache/hadoop/hbase/replication/regionserver/ReplicationSourceManager.java
…ion sources (apache#2249) Signed-off-by: huaxiangsun <huaxiangsun@apache.org> Signed-off-by: Guanghao Zhang <zghao@apache.org> Conflicts: hbase-server/src/main/java/org/apache/hadoop/hbase/replication/regionserver/ReplicationSourceManager.java Conflicts: hbase-server/src/main/java/org/apache/hadoop/hbase/replication/regionserver/ReplicationSourceManager.java (cherry picked from commit e300ae3) Change-Id: I5b2aa29597811d77ce99732019a2ac3217c93dab
…ion sources