redundant cloud servers

[Dirk Hohndel]

Yes, the US server VM ran out of memory and killed a process that didn't have an auto-restart in its systemd service file...

Should be up and running again.

Those who used the latest master SHOULD have been automatically redirected to the European server which continued working :-)

/D

> On Apr 24, 2021, at 11:54 AM, Attilla de Groot <attilla at attilla.nl> wrote:
> 
> Hi Dirk,
> 
> Are there any issues with the backend today? I’m not able to sync either from my desktop or mobile (also over 4G).
> 
> 
> — Attilla
> 
>> On 19 Apr 2021, at 22:58, Dirk Hohndel via subsurface <subsurface at subsurface-divelog.org> wrote:
>> 
>> Hi Jason,
>> 
>> Thanks for the feedback. Yes, the new DNS records now have much longer TTL and are therefore more likely to be cached.
>> I also made some subtle changes to the logic when we first attempt to connect and actually try to start writing to the cloud that might make a difference there.
>> 
>> /D
>> 
>>> On Apr 19, 2021, at 1:50 PM, Jason Bramwell  wrote:
>>> 
>>> Many thanks as always.
>>> 
>>> I used to see a ‘feature’ where the first attempt to load Subsurface would fall back to using the local cache and i’d have to close/reopen Subsurface to get it to connect to the cloud storage, Linux diagnosed this as likely slow DNS lookup, very brief testing (I do mean very brief) seems to indicate that this is no longer the save now and it ‘just works’.
>>> 
>>> Jason
>>> 
>>> Sent from Mail for Windows 10
>>> 
>>> From: Dirk Hohndel via subsurface
>>> Sent: 19 April 2021 21:00
>>> To: Subsurface Mailing List
>>> Subject: redundant cloud servers
>>> 
>>> 
>>> Over the past couple of weeks I quietly moved the cloud server backend and the authentication database out of my home network and back into the public cloud.
>>> The fact that apparently no one noticed and nothing broke was rather encouraging :-)
>>> 
>>> I then setup a second cloud server in the public cloud, this one in Europe (actually, Frankfurt, Germany).
>>> 
>>> A few minutes ago I merged a pull request that adds a couple of interesting new features to both Subsurface and Subsurface-mobile:
>>> 
>>> - geo based choice of cloud server (those in the Americas should end up using the US server, everyone else should get directed to the European server), which is intended to be completely transparent to the user.
>>> I.e., unless you explicitly look for it, you shouldn't notice (or care) which server you are using
>>> - hot failover between the two servers (so if the server that you have used before is unavailable, Subsurface and Subsurface-mobile should try the other one - and the implementation makes it easy to add more servers if that appears useful)
>>> 
>>> The two servers are automatically kept in sync in the background. I can create one extremely artificial case where there is a fairly short (generally sub one second in my tests) window for a race condition. A user would have to have two different devices that are synced to different servers (for example because they took their phone with them on an overseas dive trip), that have made conflicting changes to the dive log, and the user would then have to cause a save to the cloud on both devices within the roughly one second window. Forcing that race turned out to be fairly hard because the mobile app does a few other things before storing the data to the cloud - so for testing I ended up using two instances of Subsurface and synchronized clicks... really -- not a realistic scenario.
>>> 
>>> If this were to happen, I will get an automated email alert and fixing the problem isn't really hard - but I wanted to give a full disclosure of the issues that I am aware of.
>>> 
>>> What would help right now if people tested all this.
>>> So far I have not had the time to make new beta versions of Subsurface-mobile, but as I said, it's actually easier to test on the desktop.
>>> 
>>> /D
>>> _______________________________________________
>>> subsurface mailing list
>>> subsurface at subsurface-divelog.org
>>> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>> 
>> _______________________________________________
>> subsurface mailing list
>> subsurface at subsurface-divelog.org
>> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>