Please upgrade your browser for the best possible experience.

Chrome Firefox Internet Explorer
×

Back end maintenance again???

STAR WARS: The Old Republic > English > General Discussion
Back end maintenance again???

TUXs's Avatar


TUXs
05.09.2017 , 08:15 AM | #11
Quote: Originally Posted by xordevoreaux View Post
1. Databases, which are basically what the game servers run, have these things called tables. The tables hold the information about every aspect of the game.

2. Tables in those databases have indexes. These are lists off to the side that help the database find information faster. When information comes and goes from the tables, the indexes get fragmented. You can't change the oil in a car and drive it at the same time, so when tables need to be re-indexed, the database must be brought off-line.

3. Tables have partitions. Partitions are another means of making finding data in the database faster. There are various partition schemes, but simply put, occasionally it makes sense to re-partition the tables when they get a bit to spread out from the original scheme (or if you're tossing more drives at the server, giving the admins more ways to partition).

4. Based on what we're seeing with the performance issues on Harbinger and Red Eclipse, with the anecdotal evidence that people are flocking to these servers because they're higher pop (my guild flocked to Ebon Hawk to remain East Coast), the need to do steps 2 and 3 above become even more important. They may, depending on the rack config for their Blade server or whatever they're using, be taking down older HDDs, replacing them with faster enterprise-quality SSD arrays (we could only hope), and this isn't done all at once at any given server (just for the tables in the database needing the extra speed for the number of query hits those tables receive).

5. In addition to ordinary table maintenance, databases can be "provisioned" by adding new hardware to them. For example, the database admin can set it up so that a really large table in the database has its very own disk volume to run in, thereby maximizing the number of hits that table can have in the shortest amount of time, as opposed to slowing down the seek time by dumping many tables onto a single volume (note that I'm not using the word "disk" because the volumes might already be configured in raid arrays). So, over time, if you're slowly in the process of reconfiguring the database to spread its table scheme across a wider array of disk volumes, you need to bring the database down.

6. Drives die. Hot-swappable drives arrayed in such a way that their data is in redundant locations on a server means a drive can fail, information is then shunted to its brother drive, and all is well, but at some point, you want to pull out that hot-swappable drive and replace it in case (when, not if) its twin dies as well. Hot-swappable drives do not require the database to be taken down, not taking down the database is the whole point of hot-swappable drives, but if coupled with reason number 5, there's more going on than mere replacement, you're reorganizing raid volumes.

7. Re-apportionment may be occurring. You don't need 6 (or however many they have) volumes pulling a server load of next to zero on Jung Ma or Prophecy of the Five or Bastion when that hardware could be used elsewhere. Therefore, you might want to move drives to servers needing them (Harb, TRE, etc). This means the server for POT5 or whatever now has fewer drives comprising its drive volumes, and the high-pop servers have more, so reapportionment might bring about a new round of table partitioning, etc., because there's now more data real estate available to spread the tables across.

8. Tables (can) have triggers. Triggers are tiny little programs inside each table that make the table do things all on its own when certain events happen. Triggers aren't easy to program if you're a new admin and you're walking into a situation where the purpose and extent of what the triggers do aren't well documented, and yet issues are happening that can't be explained by looking at the higher-level stored procedures. Triggers are typically used very sparingly, but if the early development cycle used triggers heavily, they may be migrating table maintenance away from triggers into stored procedures, and this isn't something you'd want to do to large portions of a database at once because of the amount of testing necessary afterward, so you take it slow, and I can easily see how they'd want to tackle just a few trigger conversions at a time, therefore spreading the process out over weekly Tuesday maintenance cycles.

9. The local donut shop two doors down has a buy-one-get-one on all breakfast bagels and free plain coffee on Tuesday mornings and the entire maintenance team likes to chill out there all morning.
#9...it's gotta be #9!!!!
All warfare is based on deception If his forces are united, separate them If you are far from the enemy, make him believe you are near A leader leads by example not by force
My referral code: here What you get: here (1 FREE transfer 7-day FREE sub FREE Jumpstart and Preferred Bundles)