[HIVE-20264] Bootstrap repl dump with concurrent write and drop of ACID table makes target inconsistent.

• Type: Sub-task
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 3.2.0, 4.0.0
• Fix Version/s: 3.2.0, 4.0.0-alpha-1
• Component/s: HiveServer2, repl
• Labels: DR pull-request-available replication
• Target Version/s: 3.2.0, 4.0.0
• Assignee: Sankar Hariappan
• Reporter: Sankar Hariappan
• Created: 29/Jul/18 17:01
• Updated: 17/Nov/22 08:54
• Resolved: 11/Aug/18 03:23

Description

During bootstrap dump of ACID tables, let's consider the below sequence.

• Get lastReplId = last event ID logged.
• Current session (Thread-1), REPL DUMP -> Open txn (Txn1) - Event-10
• Another session (Thread-2), Open txn (Txn2) - Event-11
• Thread-2 -> Insert data (T1.D1) to ACID table. - Event-12
• Thread-2 -> Commit Txn (Txn2) - Event-13
• Thread-2 -> Drop table (T1) - Event-14
• Thread-1 -> Dump ACID tables based on current list of tables. So, T1 will be missing.
• Thread-1 -> Commit Txn (Txn1)
• REPL LOAD from bootstrap dump will skip T1.
• Incremental REPL DUMP will start from Event-10 and hence allocate write id for table T1 and drop table(T1) is idempotent. So, at target, exist entries in TXN_TO_WRITE_ID and NEXT_WRITE_ID metastore tables.
• Now, when we create another table at source with same name T1 and replicate, then it may lead to incorrect data for readers at target on T1.

Couple of proposals:
1. Make allocate write ID idempotent which is not possible as table doesn't exist and MM table import may lead to allocate write id before creating table. So, cannot differentiate these 2 cases.
2. Make Drop table event to drop entries from TXN_TO_WRITE_ID and NEXT_WRITE_ID tables irrespective of table exist or not at target.

Issue Links

• links to: GitHub Pull Request #410