Myself and a few of the people I work with are throwing around an idea for running a forum and want to get another opinion.
The goal of this is to test the effect on disk speed on the performance of the forum and most directly slow queries on the DB.
The plan is to run a forum where the DB is located completely in RAM. The problem this places is that should you crash, anything that was changed in ram but not on the HD is of course lost. The solution we have come up with is to have a file that is updated every time a change is made to that database listing the exact command that is being run on the DB.
This file provides 2 things for us. The first is that is give us a way to keep the hard copy of the DB updated, the 2nd is that it gives and extremely powerful backup tool. By setting up log rotation on these updates, you can actually have a backup of every single change made to a database. Now of course taking a little more time and effort you can build monthly snapshots of the database up to that date, this provides a very fast way to rebuild a database to any instant in time.
What we are looking for are the obvious things we have missed. I am sure there is something we haven’t taken into account that will effect this experiment. Anyone have anything they can think of?
Need some advise from Web or DB admins
Moderator: Dictators in Training
Need some advise from Web or DB admins
For to win one hundred victories in one hundred battles is not the acme of skill. To subdue the enemy without fighting is the acme of skill.
Anytime your database is accessing disks, and not doing checkpoint writes, it's setup wrong.
The way databases work already solely uses RAM, Gidan. It doesn't matter the vendor.
Speed is dependent on your database footprint and how it's normalized and the amount of full tablescans. Even mysql caches most things, and does little in regards to disk writes.
If you want a bulletproof database with zero downtime and flawless recovery, then its simply a matter of mirroring all your disks, and having redundancy. That seems more your goal than performance, which is a completely separate issue to recovery.
Another option that would make more sense given what you are looking at is running a standy server or parallel server option which gives you a syncronized cheaper backup solution that is updated fast, but doesn't slow down performance.
Anyways, your post is a tad disjointed. So my response is probably equally disjointed. If you have any exact database questions, let me know. I've been building them for 15 years.
The way databases work already solely uses RAM, Gidan. It doesn't matter the vendor.
Speed is dependent on your database footprint and how it's normalized and the amount of full tablescans. Even mysql caches most things, and does little in regards to disk writes.
If you want a bulletproof database with zero downtime and flawless recovery, then its simply a matter of mirroring all your disks, and having redundancy. That seems more your goal than performance, which is a completely separate issue to recovery.
Another option that would make more sense given what you are looking at is running a standy server or parallel server option which gives you a syncronized cheaper backup solution that is updated fast, but doesn't slow down performance.
Anyways, your post is a tad disjointed. So my response is probably equally disjointed. If you have any exact database questions, let me know. I've been building them for 15 years.
What saves a man is to take a step. Then another step.
– C. S. Lewis
– C. S. Lewis