Re: [PROPOSAL] Add SCTP network protocol to postgresql backend and frontend

On Wed, 23 Mar 2016 14:03:31 +0100
Andreas Karlsson <andreas(at)proxel(dot)se> wrote:

> On 03/23/2016 01:55 PM, Eduardo Morras wrote:
> > Benefits:
> >
> > Dynamic multihoming, modifiable at run time, don't need aggregate
> > links at OS level or shutdown servers/clients for a hardware or
> > topology network change. Message oriented connection. Message
> > reliability. Inmune to SYN floods that affect tcp.
> > Assimetric multihoming, a client with 4 links(3x 1GbEth + wifi) can
> > connect to a server with 1 link (10GbEth). Metadata connection
> > messages.
>
> While SCTP has some nice advantages in general (I think it is a pity
> it is not used more) I wonder how well these benefits translate into
> the database space. Many databases are run either in a controlled
> server environment with no direct access from the Internet, or
> locally on the same machine as the application. In those environments
> you generally do not have to worry about SYN floods or asymmetric
> links.
>
> Do you have any specific use case in mind?

The main use case is change the network topology on the fly, without shutting down postgresql server, postgresql middleware, or any of the applications that uses it through libpq.

Specific use case, backup is backup server on OS level or pgdump, not postgresql slave, (hope it don't wraps)

backup <-> postgresql <-> middleware <-> client apps <-> backup

At peak times you need all nics connected between postgresql servers and middleware and client apps,

backup <-> postgresql <=> middleware <=> client apps <-> backup

at night or idle time or while backup, you can reassign the nics to get more network bandwith to backup server

backup <=> postgresql <-> middleware <-> client apps <=> backup

On a crash restore, all nics are used from backup to servers

backup <?> postgresql < > middleware < > client apps <?> backup

> Andreas

--- ---
Eduardo Morras <emorrasg(at)yahoo(dot)es>