Emergency Maintenance

[test]

If you're new here you might want to read the other thread titled: Closing?

Otherwise, sit tight. I'm replicating the database so instead of one DB server, we'll have two. With over 20GB of just raw data (i.e. this isn't counting images etc.) this will take 6-8 hours.

Oh and through out the day, one of the web servers has been failing catastrophically. Images uploaded today might have to be deleted/auto-rejected.

[UnknownVet]

Maybe your database maintanence needs to include some of the more drastic measures mentioned in the last thread. Otherwise, what's the point? There's just going to be one implosion after another until something drastic is done. And I don't think a single Band-aid is much help for a potentially lethal wound, if you get my meaning. If you don't... well, the lethal wound would be the implosions. And routine maintanence amounts to slapping a Band-aid on it. You need more meaningful actions to save the site in its current form. Even then, it may simply not be possible. I guess mirroring the database like you're doing might be akin to applying a tornequet (sp?): it's going beyond simple "Band-aid" quick fixes but is still not likely to be the entire long term solution.

[test]

What I'm doing right now is similar to solution #2 from the other thread.

2. Shard the database (hard choice because in the interm we'll simply have to shut down)

I'm not sharding but I'm doing replication so we'll have a master-slave setup If all works well, we'll have two DB servers to run queries against so the average load will be lower.

Its' not going to solve the underlying problems with the architecture, but it might give us some wiggle room. Currently we have none, anytime the site hits a peak it crashed DAILY.

[UnknownVet]

Originally Posted by test

What I'm doing right now is similar to solution #2 from the other thread.

I'm not sharding but I'm doing replication so we'll have a master-slave setup If all works well, we'll have two DB servers to run queries against so the average load will be lower.

Its' not going to solve the underlying problems with the architecture, but it might give us some wiggle room. Currently we have none, anytime the site hits a peak it crashed DAILY.

That's true. My point was, basically, the same thing you just said. In the long run, all you're doing is using a slightly bigger Band-aid. Big deal. At least you get a little more margin for error in the short term.

[leroylim]

test, I would suggest you guys try to get a donation system up going, and try to get a few load-balancers and a few more servers to make a Load-Balanced mySQL Cluster.

I was wondering what type of tables you guys were using etc InnoDB / MyISAM / ISAM and about how is your current server setup now? Master-Slave setup or Replication, and is mySQL configurations optimized?What is the size of the mySQL DB? And are you guys storing the images in the Hard drive or using the blob column and storing the images in mySQL?

[test]

Originally Posted by UnknownVet

That's true. My point was, basically, the same thing you just said. In the long run, all you're doing is using a slightly bigger Band-aid. Big deal. At least you get a little more margin for error in the short term.

You're right, I just don't like calling solutions bandaids. It trivializes them.

Originally Posted by leroylim

test, I would suggest you guys try to get a donation system up going, and try to get a few load-balancers and a few more servers to make a Load-Balanced mySQL Cluster.

I was wondering what type of tables you guys were using etc InnoDB / MyISAM / ISAM and about how is your current server setup now? Master-Slave setup or Replication, and is mySQL configurations optimized?What is the size of the mySQL DB? And are you guys storing the images in the Hard drive or using the blob column and storing the images in mySQL?

InnoDB except for the search table.

I don't think (or rather I hope..) we won't need to move to a mySQL cluster because as a rule I do most of the work outside of the database and heavily cache datasets.

The tag heirachy doesn't map well to a relational database, so I'm just using the database for integrity and not for computing each new tag set's view.

@ Everyone - We're now serving off the other. Some posts might have disappeared because of that. Also off topic posts were deleted from this thread.

[YDKJMF]

dude, come on, stop deleting my posts.

Hey, listen, this may be off topic, but I just remembered it. Last time the site was down, you set everything to go to a thread,(like this). Problem was, back then, that you couldn't sign up to make a post or anything. I mention this because it may prevent others that may help; from helping (like leroy). I have a feeling this may not be the case anymore, (as leroylim has 2 posts, and thus must have joined very recently), (and in which case delete my post), but I thought I ought to give this bit anyway.
Sorry 'bout the off-topic post + goodluck

[test]

Its not really a bug. its useful because its stops people from joining just to complain on the forum that the site is shut down.

[leroylim]

Originally Posted by test

You're right, I just don't like calling solutions bandaids. It trivializes them.



InnoDB except for the search table.

I don't think (or rather I hope..) we won't need to move to a mySQL cluster because as a rule I do most of the work outside of the database and heavily cache datasets.

The tag heirachy doesn't map well to a relational database, so I'm just using the database for integrity and not for computing each new tag set's view.

@ Everyone - We're now serving off the other. Some posts might have disappeared because of that. Also off topic posts were deleted from this thread.

Heh, I wonder whats the size of your data sets and how heavily you cache them...
Heh a dilliema, fun.. Mehs, haven't touched mySQL for ages since company's pretty much using Microsoft SQL and Oracle... =_=