Message-ID: <4EA117EC.7000406@mastertraining.it>
Date: Fri, 21 Oct 2011 08:57:48 +0200
From: "d.davolio@mastertraining.it" <d.davolio@mastertraining.it>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: Re: How many Cluster database on a single server
References: <4E9E9C82.4060400@mastertraining.it>
	<4E9ED696.1080107@emolecules.com>
	<4E9EE69E.4070502@mastertraining.it>
	<4E9EA2D60200002500042216@gw.wicourts.gov>
In-Reply-To: <4E9EA2D60200002500042216@gw.wicourts.gov>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Thanks everybody for the suggestions. Now I have a better idea on which 
direction proceed. When we will have some results we will post again to 
share.
Thanks again!


On 10/19/2011 05:13 PM, Kevin Grittner wrote:
> "d.davolio@mastertraining.it"<d.davolio@mastertraining.it>  wrote:
>
>> We are thinking to use the Streaming Replica feature to keep in
>> sync a number of little DB servers around the net. The replica
>> should happen on one or more centralized servers. I didn't tested
>> the replica personally bus as I can see, it syncs the whole
>> Cluster DB. So, on the centralized server(s), we will have perfect
>> copies of the Cluster Databases. We sure need to test this
>> configuration but first of all I was wondering if there are known
>> drawbacks.
>
> We do something very much like this with about 100 standby database
> clusters on a single machine.  We don't have any illusion that we
> could switch to one of these for a normal production load and have
> good performance with all of these competing for resources -- it's
> primarily to confirm that the PITR backup process is working and
> staying up to date, and to provide a quick source for a copy to a
> standby production server.
>
> The one thing I would strongly recommend is that you use a separate
> OS user as the owner of each cluster's data directory (and, of
> course, to run the cluster's service).  We didn't initially do this,
> and had problems on recovery when the server crashed.  If you search
> the archives you can probably dig up all the details on why this is
> an issue and why separate users is a good solution; but really, this
> is important.
>
> -Kevin