I spent some time thinking about this type of solution on another project I was working on so I think I understand what you are trying to do.
There cannot be a true "source of truth” database in a master-master cluster, which is the idea on which CouchDB’s protocols are based. The source of truth is within the individual documents. So, I think your options are: 1. Clear/purge the database from all other nodes in the syncing system (esp. the “master server”/Couchbase/CouchDB) and resync from your local backup. I don’t know how you accomplish this in your environment. 2. If you know the individual bad doc: 1) make a copy of the correct version when restoring from backup 2) sync from master 3) push an edit of the ‘bad doc’ from the ‘good copy’ made from your backup. Neither are ideal, but it’s the way the technology is structured, not a failing. Cheers. > On Nov 22, 2015, at 2:33 AM, Brendan Duddridge <[email protected]> wrote: > > I forgot to add that I would think then the sync process could start from > scratch, uploading the data from the client to the server. Basically the > client gets to decide who the "source of truth" is in this circumstance. > > On Sunday, November 22, 2015 at 3:31:34 AM UTC-7, Brendan Duddridge wrote: > Well that definitely complicates things. Perhaps another way to reset back to > a previous state would be to purge all the documents on the server for a > specific channel? Given that in my case a user can have multiple cblite2 > database files, each belonging to their own channel. And then restore the > cblite2 database file to a previous version? > > Thanks, > > Brendan > > On Saturday, November 21, 2015 at 11:39:51 PM UTC-7, Jens Alfke wrote: > >> On Nov 21, 2015, at 7:19 PM, Brendan Duddridge <[email protected]> wrote: >> >> Are you implying in your response to this question that you can't just >> replace the cblite2 database package and that you must read through the >> backup file, restoring to the current database with the contents of the >> backup file? Does that mean that you would then also have to delete all the >> documents created since the most recent document in the backup database? > > Yes, if your purpose in backing up is to reset the database back to the state > it was in at some past time (as opposed to just being able to restore the > database later on in case of data loss.) In resetting back to a past state, > you are fighting against the replicator, whose job it is to update to the > latest state available on the server. That’s why you can’t just restore the > database file — it contains old revisions that will be replaced by newer ones > from the server. > > —Jens > > -- > You received this message because you are subscribed to the Google Groups > "Couchbase Mobile" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/mobile-couchbase/1bb08566-99cc-490c-a4ef-1187daef9b93%40googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Couchbase Mobile" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/0D6FA539-9A30-4ABE-9C66-85FDE6F07C5F%40gmail.com. For more options, visit https://groups.google.com/d/optout.
