Couchbase Replication ID

sbarlow · March 7, 2017, 2:50am

How is the “replication/checkpoint id” generated in a Couchbase Lite <-> Sync Gateway system?

From https://github.com/couchbase/couchbase-lite-ios/wiki/Replication-Algorithm

Steps
1. Get unique identifiers for the source and target databases (which may just be their URLs, if no UUIDs are available).
2 . Generate a unique identifier for this replication based on the database IDs ….

So, the question then is, is a UUIDs available from Sync Gateway, or is the URL only used?

The reason for the question, is that I want to be sure that if I create a replica of a Sync Gateway bucket using CouchDB style replication (not XDCR), and then point the original Sync Gateway DNS at the new replica, that existing client replications will behave correctly (i.e. same URL, but new Sync Gateway replica with different sequence)

The second part of the question is: what would be the behaviour if I make the replica using XDCR, rather than CouchDB replication? Would this replica identify as a different, or the same database?

sbarlow · March 7, 2017, 2:54am

And to cut right to the chase:

What I want to do is use a blue/green deployment strategy to achieve a zero downtime update to the Sync Gateway sync function (changes to the channel allocation of various docs). How can I do that?

househippo · March 9, 2017, 6:16am

its origins are created from the function NSString* CBLCreateUUID()

github.com

couchbase/couchbase-lite-ios/blob/9a8903b9e851d5584abeec069ead4d2637b3bb91/Source/CBLMisc.m#L99


      
              BOOL ok = [str getBytes: buf maxLength: maxByteCount usedLength: &byteCount
                             encoding: NSUTF8StringEncoding options: 0
                                range: NSMakeRange(0, str.length) remainingRange: NULL];
              if (ok)
                  block(buf, byteCount);
              free(buf);
              return ok;
          }
          
          
          NSString* CBLCreateUUID() {
              // Generate 136 bits of entropy in base64:
              uint8_t random[17];
              if (SecRandomCopyBytes(kSecRandomDefault, sizeof(random), random) != 0)
                  return nil;
              NSMutableString* uuid = [[CBLBase64 encode: random length: sizeof(random)] mutableCopy];
              // Trim the two trailing '=' padding characters:
              [uuid deleteCharactersInRange: NSMakeRange(22, 2)];
              // URL-safe character set per RFC 4648 sec. 5:
              [uuid replaceOccurrencesOfString: @"/" withString: @"_" options: 0 range: NSMakeRange(0, 22)];
              [uuid replaceOccurrencesOfString: @"+" withString: @"-" options: 0 range: NSMakeRange(0, 22)];

househippo · March 9, 2017, 6:19am

ALSO

jens · March 10, 2017, 5:50pm

If I recall, the SG database’s UUID is stored in a special key in the bucket.

If you create a new database in SG it will have a different UUID. Using replication to copy the data won’t alter that. Couchbase Lite will treat this as a different database; the replication will work correctly, but it’ll take longer the first time because it will first have to check whether it has all the revisions in the database.

If you use XDCR the UUID will carry over to the new database. This is actually bad because the two buckets can diverge in contents, but the replicator won’t know because it thinks they’re the same database. That can cause data loss.