On 29 May 2018 at 06:12, Alex Davis <[email protected]> wrote: > I want to say thank you Bob for starting this conversation. > > IIUC, if tabs are the only problem we need to think of, this is a good > place to be in! Impact seems pretty minimal if you can run updates and > restart a server rather than do a full node migration. >
Agreed. I think the next step here would be to actually test it out in stage and see what the user experience feels like in practice, esp. with multiple devices connected. > As per > >> Is this true of other collections in general? In particular, I'm >> wondering about the possibilities of recovering the user's data atop a >> point-in-time backup using this method, along the following lines: >> > > Very happy we're talking about options around restoring data. Questions: > - Would resolving this issue with the current server benefit the sync.next > server that syncs with Mentat? (given that we "might" fork the existing > server to create the new one.. or so I've heard) > - Also, would it help reduce risk in any way to be able to recover from a > point-in-time when we start to migrate users to sync.next? > This is a whole 'nother topic that probably deserves its own thread. We're fast coming up on some strategic choices about how much to evolve the current sync servers vs how much to invest in a new one, and on what timeframe. I'll try to gather more thoughts later today and kickstart that discussion. Ryan > > -- > Alex Davis // Vancouver > Product Manager // Application Services > (514) 582-2539 > IRC & Slack: adavis > > On Sun, May 27, 2018 at 9:06 PM, Mark Hammond <[email protected]> > wrote: > >> On 28/05/2018 1:05 pm, Ryan Kelly wrote: >> >>> Is this true of other collections in general? In particular, I'm >>> wondering about the possibilities of recovering the user's data atop a >>> point-in-time backup using this method, along the following lines: >>> >>> * We take regular backup snapshots of the user's data on the server >>> * Something bad happens to a storage node, and we want to restore the >>> user's data from a backup, so we: >>> * Down the node, having it return 503s with backoff >>> * Restore the db from backup >>> * Futz with their meta/global to remove the syncIDs while leaving >>> other data intact >>> * Restore the node to service >>> * On its next sync, the client detects that the syncIDs have changed and >>> does a full re-sync >>> >> >> In general, this should cause clients to act as though they were just >> connected to Sync - they'll do a full reconcile etc. Or more accurately, it >> will probably behave as though the client was disconnected on the date of >> the backup and reconnected today. >> >> While I can see this approach being useful for users who are treating >> sync as a backup (ie, where they've lost the only syncing device, so any >> data is better than no data), there's a risk for accounts where active >> clients exist, particularly around the resurrection of deleted items, but >> also for reconciliation in general (where Sync may end up deciding the >> server data should be taken over the remote data) >> >> I guess we could decide the damage is likely to be minimal if the backup >> was recent enough, but the outcome will almost certainly never be >> deterministic as it is likely to depend on exactly how recent the backup >> is, what device ends up doing a first sync and when it previously synced. >> >> This is much easier to rationalize about for tabs because each tab record >> is written to by exactly 1 device - there's no opportunity for a stale >> client to screw up the record for a different device. >> >> (That said though, there might be scope to change client's behaviour - if >> each client knew that it was dealing with restored data it might be able to >> make better decisions, but that might end up being a very large change - >> eg, it might require all clients to move to tombstones and always persist >> those tombstones locally, some way to avoid "old" clients doing the first >> "recovery sync", etc) >> >> >> Mark >> _______________________________________________ >> Sync-dev mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/sync-dev >> > >
_______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
