Skip site navigation (1) Skip section navigation (2)

Re: Isolated databases or instances

From: "Henry, Nigel, CYFD" <nigel(dot)henry(at)state(dot)nm(dot)us>
To: "Scott Marlowe" <smarlowe(at)g2switchworks(dot)com>
Cc: <pgsql-admin(at)postgresql(dot)org>
Subject: Re: Isolated databases or instances
Date: 2007-02-16 22:30:02
Message-ID: 2488267002735E4293095085A7B5D86401446CB5@CEXMB4.nmes.lcl (view raw or flat)
Thread:
Lists: pgsql-admin
More information:
 
As stated, this is going to be a SLES 9.3 environment -- 64-bit.  VMWare, for now, is out of the question because we currently only have IBM HS20 blades which are unable to host the 64-bit environment in VMWare.  So we're running the OS on bare metal.  As I mentioned in my original post, we are trying to use our blades wisely by creating the three separate, isolated environments across the blades.  Much like this: #
separate install instances of the HTTP server (3 -- DEV/Test/UAT) 1st blade; 
separate install instances of the application server
(3 -- DEV/Test/UAT) 2nd blade -- the HTTP server will be installed from the application build rather than as a separate install; and
three PostgreSQL database instances (3 -- DEV/Test/UAT) on the last blade.
This is the only way we can create three environments since even though we have three blades, the blade housing databases belongs to the DBA group.  The application being developed is in Java and is not a transaction-intensive application.  
 
Nigel D. Henry 
State of New Mexico 
Computer Software Engineer 
Children, Youth, & Family Division 
Nigel(dot)Henry(at)state(dot)nm(dot)us 
(505) 841-6631 
 
Confidentiality Notice: This e-mail, including all attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided for under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message.

________________________________

From: Scott Marlowe [mailto:smarlowe(at)g2switchworks(dot)com]
Sent: Fri 2/16/2007 2:50 PM
To: Henry, Nigel, CYFD
Subject: RE: [ADMIN] Isolated databases or instances



There was no chastisement intended.  Please, post your reply to the
list, and include the details I asked for (i.e. what exactly are you
trying to accomplish here) and let's all work on it together.

Perhaps multiple pgsql instances are the best answer.  Perhaps VMWare is
the best way to accomplish it.  We just don't have enough details.

On Fri, 2007-02-16 at 14:09, Henry, Nigel, CYFD wrote:
> Thank you, sir.  I stand chastened before my colleagues.
> 
> Nigel D. Henry
> State of New Mexico
> Computer Software Engineer
> Children, Youth, & Family Division
> Nigel(dot)Henry(at)state(dot)nm(dot)us
> (505) 841-6631
> 
> Confidentiality Notice: This e-mail, including all attachments, is for
> the sole use of the intended recipient(s) and may contain confidential
> and privileged information. Any unauthorized review, use, disclosure
> or distribution is prohibited unless specifically provided for under
> the New Mexico Inspection of Public Records Act. If you are not the
> intended recipient, please contact the sender and destroy all copies
> of this message.
>
> ______________________________________________________________________
> From: Scott Marlowe [mailto:smarlowe(at)g2switchworks(dot)com]
> Sent: Fri 2/16/2007 12:52 PM
> To: Henry, Nigel, CYFD
> Cc: pgsql-admin(at)postgresql(dot)org
> Subject: Re: [ADMIN] Isolated databases or instances
>
>
>
> On Fri, 2007-02-16 at 13:18, Henry, Nigel, CYFD wrote:
> > We are at the beginning of the building of a 3-tier
> > development/test/uat environment.   We would like some advice on how
> > the PostgreSQL database should be configured for this environment.
> >
> > The environments will be installed on three blades of an IBM Blade
> > Center.  Due to budget restrictions, we are building the three
> > environments with separate install instances of the HTTP server
> > (3) 1st blade; separate install instances of the application server
> > (3) 2nd blade -- the HTTP server will be installed from the
> > application build rather than as a separate install; and
> > three PostgreSQL database instances on the last blade.
> >
> > My concern is that building the PostgreSQL databases as instances
> from
> > a single binary could lead to problems in a development environment.
> > My recommendation is to create three isolated databases (3
> > binaries) for each environment to mitigate an unforeseen mishaps.
> >
> > I would like some advice on what would be the best practice for
> > building a development environment, such as described above, in the
> > type of environment described above.
>
> What exactly are you trying to accomplish with multiple PostgreSQL
> instances here?  I can't see there being any great advantage to three
> separate instances than having three discrete databases defined in one
> instance.  Use pg_hba.conf to restrict connections to the databases to
> the proper users (testing, staging, and production, I assume) and you
> should get the same effect with less complexity.
>
> If you really need three discrete instances, you might want to look at
> using vmware to set up three separate virtual machines, each with
> their
> own IPs etc... on that one box.




Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System. 



Responses

pgsql-admin by date

Next:From: Chad WagnerDate: 2007-02-16 22:32:28
Subject: Re: WAL files backup
Previous:From: Benjamin AraiDate: 2007-02-16 22:05:50
Subject: Re: Priorities for users or queries?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group