Database Server Role Design Considerations

[Stef Walter]

On 12.12.2014 18:52, Simo Sorce wrote:
> On Thu, 11 Dec 2014 12:45:02 -0500
> Stephen Gallagher <sgallagh at redhat.com> wrote:
>> Unlike the Domain Controller role, the Database Server role will
>> almost certainly need to support multiple instances. There are a
>> couple ways that we can do this, both with their own pluses and
>> minuses.
> 
> Why do we need to support multiple instances ?
> 
>> 1) Similar to the Domain Controller role, we can install the postgres
>> packages on the local machine and then have each role instance create
>> and manage a specific database within the server. This would be the
>> easiest to implement, although I'm not sure what the start/stop
>> semantics would have to be for the role instances, since we almost
>> certainly don't want to stop all databases at the same time.
> 
> Are you thinking about multiple separate postgres installations within
> the same machine each listening on a different port?
> 
> Or just the ability to create new databases within the single postgres
> instance ?

With postgres this is not so super necessary, since it supports multiple
databases, namespaces, users etc. It is mostly possible to "virtual
host" postgres the way you would Apache.

But with other databases like MongoDB it starts to become a clearer
need. Multiple instances store distinct sets of data.

>> 2) We could instead use Docker to create discrete postgres containers
>> for each database we wanted to create. The advantages here would be
>> better isolation and service control as well as protection against
>> unwanted version upgrades. Containerized databases might be easier to
>> move between machines as well. The primary disadvantages would be that
>> the containers wouldn't be able to share a single port on the system,
>> upgrades for security and bugfixes might be harder and that Docker is
>> only currently supported on x86_64.
> 
> Docker is cool, but I do not think we should wander in that direction
> with server roles.

I think that containers (or pods of containers) would be a great fit for
server roles. A really great fit in fact. It's a shame we're not doing
that already. I sorta assumed it had something to do with immaturity of
the container solutions, with regard to updates etc. Note that these
containers don't have to be Docker specific ...

Stef

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20141212/abcc219b/attachment.sig>