Database Server Role Design Considerations

Russell Doty rdoty at redhat.com
Fri Dec 12 21:47:29 UTC 2014


On Fri, 2014-12-12 at 14:42 -0500, Simo Sorce wrote:
> On Fri, 12 Dec 2014 19:41:52 +0100
> Stef Walter <stefw at redhat.com> wrote:
> 
> > 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 ...
> 
> Well I do not want to re-invent something like mesos or kubernetes in
> rolekit. And this space is pretty immature still, there is no winner
> and even Docker is somewhat under threat of not being the final word on
> containers since Rocket and LXC and other things are still bubbling up
> every other day.
> 
> I wouldn't want to spend 6 months building something to find out at the
> end of the cycle that we have to start from scratch because we failed
> to pick the winner (and no upgrade path will then be possible so you
> compound failure there).
> 
> Maybe I am a bit conservative, but the server space tend to be that way
> and using mature components for our underlying infrastructure is the
> only way we can think of slowing down Fedora Server release cycle (if
> we still are thinking of doing that at some point) and maintain it for
> longer.
> 
> However I may have misunderstood our aim or maybe we need to re-discuss
> some of the goals of Fedora Server and get all back on the same page.
> 
> Simo.
> 
Sounds like it is time to do some prototyping. As noted, it isn't clear
which container technology will be the long term winner. Or where the
holes in the current container implementations are, especially around
application lifecycle. 

I'd like to see a comparison between traditional approaches and
containers for performing a set of database tasks: installation, update,
backup/restore, using the database from applications, performing DB
maintenance, configuring replication, etc.




More information about the server mailing list