SB down times

[KenGordon]

I get the feeling you do regular site maintenance at about 7am UTC on Sunday mornings. Maybe also Good Friday mornings....

Do you need to take the site down so often? That lands right about when I am having a coffee (assuming I haven't got up already to go diving).

Ken

 

[diversteve]

Actually it's 15 minutes every night (in the U.S.) at that time...

Our admininistrator can speak to why but I believe it's when there's the least impact on usage by the overall membership.

 

[KenGordon]

Every night? Wild. Oh well, I seem to recall it uses those quaint old physical servers too.

 

[HowardE]

It's because the database is very large, and the database backup occupies the entire database, and therefore the server would not respond while the dump was in process. Rather than have people get web pages that take 10 minutes to load, the site goes down for 15 minutes for the database to backup.

vBulletin uses a lot of queries with select * and locks the tables.

Anyway. The backup takes probably 6-8 minutes, but we left a window of 15 minutes to be safe.

 

[Diver0001]

I get the feeling you do regular site maintenance at about 7am UTC on Sunday mornings. Maybe also Good Friday mornings....

Do you need to take the site down so often? That lands right about when I am having a coffee (assuming I haven't got up already to go diving).

Ken

I believe it has to do with making back-ups. It takes 15 min a day at exactly the same time as every other day.

....even when you're drinking coffee.....

I do feel your pain. For Europeans the chosen time slot sucks balls, it really does. SB is often offline at exactly the one time in my morning when I have a chance to check it..... and I can't even count the number of times I've typed in a reply to a post and clicked "Post Reply" only to have it say, "sorry we're offline. try again later" (or whatever the exact message is).

Frankly, anno 2015 it's ridiculous beyond words that a database can't back itself up without going off line. Apparently VBulletin was programmed by jr. high-school students, which means we just have to suck it up.

R..

 

[dmaziuk]

Apparently VBulletin was programmed by jr. high-school students, which means we just have to suck it up.

Even mysql can now run a replica slave and you can backup the slave without off-lining the master these days. However, those of us who know that don't write blog engines, office suites, or a whole bunch of other applications. 'Cause they're mind-numbingly boring and nobody pays enough to compensate for the dead brane cells.

 

[descent]

... Frankly, anno 2015 it's ridiculous beyond words that a database can't back itself up without going off line. ... which means we just have to suck it up.

You're right, of course, but no, you shouldn't have to just sit and suffer.

Even mysql can now run a replica slave and you can backup the slave without off-lining the master these days. ...

I thought of several quick hacks using a read replica, or "slave". But each hack would prevent writes.

Am I too picky? I think a read-only ScubaBoard is an unusable ScubaBoard.

After a little more consideration, I could not come up with a reason why a master-master replication pair would not be able to solve this problem. Implemented correctly, this drastic revision of the back end would not be visible to the app at all.

Any backup script would need to 1) break replication, 2) choose one instance and cause that instance to be isolated from the app, 3) snapshot that instance, 4) re-establish replication, and 5) verify that the masters have fully synchronized, are passing writes in both directions successfully, and are committing those writes to reliable media.

As a bonus, SB would get a new set of DR tools and walk a little further down the path toward having a site that is always up and usable, even during upgrades.