Please use this thread to discuss the No Downtime experiment dev blog.
For actual feedback on the experiment once it’s underway please use this thread. (The feedback thread will remain locked until the commencement of the actual extended uptime period at 11:00 UTC on Wednesday, December 4th).
Aussies have been quietly complaining about downtime in the middle of their prime time for years.
And grateful it’s been reduced repeatedly.
Sordina 1 - Brisc 0
Several players have reached out directly to me and other CSM members about downtime and the related issues when the server restarts. These issues have been relayed to CCP.
Not everyone likes to post publicly.
That might break. We know for a fact that asteroid belts will not reseed, we are unsure of the extent of other things.
They are not going to take place.
This is quite literally downtime-driven in-game behaviour.
Very much what Steve said.
From MS SQL to MySQL?
You’ll have to forgive me, but I suspect those databases were pretty trivial. The tooling for management of MySQL databases, and management of execution plans is, umm, less good.
Maybe Postgres. But MySQL has some fairly really old bugs in it, which aren’t going to get fixes.
Yeah, we never said randomly. This is an experiment to find out where to focus our efforts. Once we have fixed the paint points and can run for 48 hours we might come up with this kind of a schedule:
unrelated.
Mostly correct for the majority of the current cluster, which could be described as TQ Tech 3.3. We are due updating you on what has been happening recently.
We won’t be going for a random downtime. After this experiment it will revert to daily at the usual time but perhaps going forward we can have it less frequently. Maybe every few days, or just weekly. Whatever we end up with though DT itself will always occur at scheduled times so nobody gets surprised, although we won’t rule out having it at different times on different days to spread the pain around. 
Not related; interesting nevertheless since this is an issue that has happened once before and the first time it happened we had to reboot both the chat cluster and TQ. This time around we managed to resolve the issue while the TQ was live; so progress on fixing things without needing downtime/reboot.
I played EVE in the Australian timezone for 15 years and I can tell you the timing of DT has been a major issue for players on that side of the world the entire time. It comes up frequently in discussions between AUTZ players in-game and at pub meetups etc, and every EVE Down Under and Fanfest usually has at least one player ask CCP when they’re going to delete DT, usually to a room full of cheers.
If we were to switch from MS SQL, then Postgres would be at the top of the list.
You have my sympathy, for having to work with Oracle. It’s a powerful database, but not a nice one.
(source, 12 years as an Oracle DBA, now free)
You should come to an EVE Down Under. We’ve been anything but quiet about it.
Hush! I’m trying to pass you off as Canadians with better weather!
I already replied to this question; that was not related but demonstrated that we have further improved our ability to fix things without a reboot.
So, this is a bit tricky since some things may break or not behave as anticipated and we needed to be upfront about that aspect of this experiment. So we had to tell players.
Thanks for saying so and I acknowledge I haven’t been as active on these forums as I should be - something I hope to remedy now that the Invasion World Tour is over and I can begin concentrate more on the grassroots aspects of community development!
Why is that odd? We know of some issues, but we are not sure which of them might be most player-noticeable and have impact on the experience. During the experiment we have also discovered new issues, which may be more important to fix than some of the issues we know of.
We did and they were caught.
devtrackers.gg