Get some better material to troll with, that crap has gotten old.
2 Likes
This is quite literally downtime-driven in-game behaviour.
8 Likes
Very much what Steve said.
1 Like
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.
4 Likes
You should have kept it a secret and just watched as people freak out when the servers did not go down!
25 Likes
Haven’t read everything but when I logged in around 12:10 today I was unable to see corp members in local or the corp channel 
2 Likes
I agree with this
1 Like
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:
- Sunday – no downtime
- Monday – downtime at 7 o’clock
- Tuesday – downtime at 11 o’clock
- Wednesday – no downtime
- Thursday – downtime at 11 o’clock
- Friday – no downtime
- Saturday – downtime at 7 o’clock
8 Likes
unrelated.
1 Like
Sorry must have misread the OP.
1 Like
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.
1 Like
We know that some things will be less than ideal, e.g., asteroid belts will probably be barren in the last 24 hours.
ah, missed that line. thank you
and I am a cuttle fish, not a vegetable
m
5 Likes
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. 
7 Likes
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.
4 Likes
He is not getting my point, like usual, as he’s just miserable. What I was aiming at were a time without any daily downtime, which means whenever something breaks that could be fixed during the daily downtime in the past, it would mean a random downtime. I prefer predictability over unnecessary schedule adjustments.
4 Likes
I know mySQL wasn’t the best example now as MariaDB is damned better than mySQL ( I said I was old and retired ). Worked mostly with AIX 4 and 5, Solaris 10 and RHEL with Oracle DB’s in banking (very large environments). Postgres might be viable.
2 Likes
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.
9 Likes
If we were to switch from MS SQL, then Postgres would be at the top of the list.
1 Like
Thanks, yes someone earlier mention it was unrelated.
I misread the OP and thought this had happened today which was why I thought I should mention it here.
2 Likes
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)
5 Likes