On Tue, 2005-07-19 at 16:45 +0000, vinita bansal wrote:
> Hi,
>
> I am trying RAMFS solution with Postgres wherein I am pushing the most
> heavily used tables in RAM.
Why? I mean, what problem are you trying to solve?
> I have 32GB RAM on a 64 bit opteron machine. My database size is 40GB. I
> think Linux allows max. of 16GB (half of available RAM) to be used directly
> to push tables to it.
>
> I am concerned about reliabilty here (what if there is a power failure).
> What are the things that need to be considered and what all can be done to
> ensure that there is no data loss in case something goes wrong. What steps
> must be taken to ensure data recovery. I am planning to use Slony
> replication to replicate my database to a diff node so that incase something
> goes wrong, I can restore it from replication node and start my runs on that
> data again. The only problem here is that I need to run engines from
> beginning. Is there any other way of doing the same thing or such a thing is
> good enough given the fact that a failure like this happens very rarely. The
> most imp. thing for me is the **data** which should not be lost under any
> circumstances.
Then don't use RAMFS. Slony may be a good idea, but it's hard to tell if
you don't provide more info.
What is the database used for?
- heavy long running, CPU-based, read only queries?
- many simple queries but over the whole dataset (thus I/O based)?
- many INSERTs/UPDATEs?
Is the database accessed by many concurrent users? How many of them are
mostly read-only and how many perform writes?
Each problem in each scenario may have a different solution...
> Has anyone used Slony replication before. How good is it. Is there anything
> else available which is better then Slony Replication?
"better" is meaningless w/o a context. There are tasks in which Slony
may the best tool in the world, and others that require a totally
different approach. First you have to define what your problem is, and
why the obvious solution (a normal PostGreSQL server, with a standard
filesystem) does not work/fit. Then you choose a solution.
>
> Regards,
> Vinita Bansal
.TM.
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ Colombo@xxxxxx
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your
message can get through to the mailing list cleanly
