Multi-master Asynchronous Replication February, 2019

Problem Asynchronous Replication generates conflicts Resolution of conflicts happens too late Uniqueness requirements are not met Eventually consistent replication approaches do not resolve this

Problem Clients 1 & 2s' requests processed promptly 1. Protect Stop Date = DATE1 2. Protect Stop Date = DATE2 3. Conflict Server 1 Server 2 Key Management Domain Clients 1 & 2s' requests processed promptly Server 1 then replicates to Server 2 (async) Too late to tell Client 1 of conflict Client 1 and Client 2 different views Client 1 wins or client 2 wins or both lose Conflict resolution occurs after client responses Real-world problem!

Problem Clients 1 & 2s' requests processed promptly 1. A.Name = Fred 2. B.Name = Fred 3. Conflict Server 1 Server 2 Key Management Domain Clients 1 & 2s' requests processed promptly Server 1 then replicates to Server 2 (async) Too late to tell Client 1 of conflict Conflict resolution occurs after client responses A.Name = Fred and B.Name = Fred Real-world problem!

Quantum Solution Quantum Database IPR declaration – patent pending Simultaneously holding all possible attribute values Unfortunately it cannot tell you which attributes have which value at the same time And is unable to be FIPS140-2 approved IPR declaration – patent pending Yes this is levity … and it should include a cat slide …

Conclusion Uniqueness of Names causes issues Reduce the context for Name clashes Introduction of Namespaces could help