• Welcome to ScubaBoard


  1. Welcome to ScubaBoard, the world's largest scuba diving community. Registration is not required to read the forums, but we encourage you to join. Joining has its benefits and enables you to participate in the discussions.

    Benefits of registering include

    • Ability to post and comment on topics and discussions.
    • A Free photo gallery to share your dive photos with the world.
    • You can make this box go away

    Joining is quick and easy. Login or Register now by clicking on the button

SB down times

Discussion in 'Site Support' started by KenGordon, Apr 3, 2015.

  1. KenGordon

    KenGordon Rebreather Pilot

    3,623
    2,394
    113
    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
     
  2. diversteve

    diversteve always tired Rest in Peace ScubaBoard Supporter

    # of Dives: I'm a Fish!
    Location:
    26,281
    5,854
    113
    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.
     
    Last edited: Apr 3, 2015
  3. KenGordon

    KenGordon Rebreather Pilot

    3,623
    2,394
    113
    Every night? Wild. Oh well, I seem to recall it uses those quaint old physical servers too.
     
  4. HowardE

    HowardE Diver ScubaBoard Supporter

    # of Dives: 2,500 - 4,999
    Location: Boca Raton, Florida
    19,202
    1,436
    113
    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.
     
  5. Diver0001

    Diver0001 Instructor, Scuba

    0
    54
    0
    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..
     
  6. dmaziuk

    dmaziuk Regular of the Pub

    6,814
    3,000
    113
    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.
     
  7. descent

    descent Solo Diver

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


    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.
     

Share This Page