Csaba Nagy wrote:
> Why not have a design where the slave is in control for it's own data ?
> I mean the slave could ask for the base files (possibly through a
> special function deployed on the master), then ask for the WAL stream
> and so on. That would easily let a slave cascade too, as it could relay
> the WAL stream and serve the base backup too... or have a special WAL
> repository software with the same interface as a normal master, but
> having a choice of base backups and WAL streams. Plus that a slave in
> control approach would also allow multiple slaves at the same time for a
> given master...
I totally agree with that.
> The only downside of this approach is that the slave machine needs a
> full postgres super user connection to the master. That could be a
> security problem in certain scenarios.
I think the master-slave protocol needs to be separate from the normal
FE/BE protocol, with commands like "send a new base backup", or
"subscribe to new WAL that's generated". A master-slave connection isn't
associated with any individual database, for example. We can keep the
permissions required for establishing a master-slave connection
different from super-userness. In particular, while the slave will be
able to read all data from the whole cluster, by receiving it in the WAL
and base backups, it doesn't need to be able to modify anything in the
master.
> The master-centric scenario needs
> a connection in the other direction, which might be seen as more secure,
> I don't know for sure...
Which one initiates the connection, the master or slave, is a different
question. I believe we've all assumed that it's the slave that connects
to the master, and I think that makes the most sense.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com