4 ms·

Literally six lines Which is six lines too many for what is inherently a runtime configuration that shouldn't be mentioned in any config file at all. Then you

by moe 12y ago

Literally six lines Which is six lines too many for what is inherently a runtime configuration that shouldn't be mentioned in any config file at all. Then you use pg_basebackup, and start the slave. I take it you don't care for failover and monitoring then? Otherwise you would have mentioned either repmgr and pgpool here, or your conglomerate of rather complex homegrown scripts to mimic their functionality.

rosser 12y ago
No, and nor did I mention "fencing". I said "minimum viable". No other open source RDBMS manages those things, so calling postgres out for lacking them is a little disingenuous. Replication isn't "inherently" anything. Making it a runtime thing is one way of doing it. Just because it's your preferred way (or — as often seems to be the case among people who share your opinion about how postgres does it — just how they were first exposed to it) doesn't make any of the myriad other, perfectly viable ways of doing it wrong. As for my "conglomerate of homegrown scripts", I keep my db configs versioned in git, and use symlinks from $PGDATA into a role- and environment-specific (e.g., testing-master or production-slave or whatever) subdirectory in a clone of that repo. Puppet clones the repo on spinning up a new machine, and I repoint the symlinks as necessary. You know: $ ln -sf /path/to/repo/environment/role/*.conf $PGDATA/ Complex, huh?
- waitwaitwhay 12y ago
  > No other open source RDBMS manages those things, so calling postgres out for lacking them is a little disingenuous. Doesnt MySQL Cluster do this pretty well?
  - davidgerard 12y ago
    MySQL clustering is a goddamn PITA, just as MySQL replication is, regularly requiring you to take a plunger to unclog it. The quirks and bugs are myriad.
- moe 12y ago
  fencing Which relates to a master/slave cluster as in how? no other open source RDBMS out there manages those things either Rethinkdb, Redis, Riak, ElasticSearch all do. (them not being relational is irrelevant to replication) Making it a runtime thing is one way of doing it. It's the only way of doing it for modern, dynamic application layouts (the whole "cloud" thing). The stereotypical static database cluster, carefully configured by a graybeard once and then never touched again, it still exists. But it's rapidly losing ground. Puppet clones the repo on spinning up a new machine, and I repoint the symlinks as necessary. So how do you monitor e.g. the replication lag?
  - rosser 12y ago
    fencing ... relates to a master/slave cluster as in how? Because when you promote a slave, you also need to fence writes to the old master, otherwise you can end up in a "split-brain" scenario, where the old and new masters are both accepting writes, and nobody's replicating. Have fun cleaning that up. (them not being relational is irrelevant to replication) I disagree. Their being relational imposes extra constraints upon replication. ACID? So how do you monitor e.g. the replication lag? Icinga invokes this: https://bucardo.org/check_postgres/check_postgres.pl.html#replicate_row https://bucardo.org/check_postgres/check_postgres.pl.html#re... Look, I'm rapidly losing interest in going back and forth like this. You don't seem very interested in the validity of another perspective, but rather just keep finding fault in things that don't do it your preferred way. If you want to have a discussion, I'll play. If not, let's just walk away.
    - moe 12y ago
      Because when you promote a slave, you also need to fence writes to the master, otherwise you can end up in a "split-brain" scenario. There is only one master, hence there can not be a "split brain". You seem to be confusing master/slave and multi-master configuration (which pg doesn't support). I disagree. Their being relational imposes extra constraints upon replication. ACID? Well, it doesn't. Look, I'm rapidly losing interest in going back and forth like this. You claim things are "easy" that you clearly haven't done before. I was merely calling you out on that, but agree the discussion is unlikely to go anywhere from here. Edit: Oh and you retouching your comments all the time doesn't help either (the split-brain paragraph just changed...). I'm out.

by moe 12y ago

rosser 12y ago

No, and nor did I mention "fencing". I said "minimum viable". No other open source RDBMS manages those things, so calling postgres out for lacking them is a little disingenuous. Replication isn't "inherently" anything. Making it a runtime thing is one way of doing it. Just because it's your preferred way (or — as often seems to be the case among people who share your opinion about how postgres does it — just how they were first exposed to it) doesn't make any of the myriad other, perfectly viable ways of doing it wrong. As for my "conglomerate of homegrown scripts", I keep my db configs versioned in git, and use symlinks from $PGDATA into a role- and environment-specific (e.g., testing-master or production-slave or whatever) subdirectory in a clone of that repo. Puppet clones the repo on spinning up a new machine, and I repoint the symlinks as necessary. You know: $ ln -sf /path/to/repo/environment/role/*.conf $PGDATA/ Complex, huh?

waitwaitwhay 12y ago
> No other open source RDBMS manages those things, so calling postgres out for lacking them is a little disingenuous. Doesnt MySQL Cluster do this pretty well?
- davidgerard 12y ago
  MySQL clustering is a goddamn PITA, just as MySQL replication is, regularly requiring you to take a plunger to unclog it. The quirks and bugs are myriad.
moe 12y ago
fencing Which relates to a master/slave cluster as in how? no other open source RDBMS out there manages those things either Rethinkdb, Redis, Riak, ElasticSearch all do. (them not being relational is irrelevant to replication) Making it a runtime thing is one way of doing it. It's the only way of doing it for modern, dynamic application layouts (the whole "cloud" thing). The stereotypical static database cluster, carefully configured by a graybeard once and then never touched again, it still exists. But it's rapidly losing ground. Puppet clones the repo on spinning up a new machine, and I repoint the symlinks as necessary. So how do you monitor e.g. the replication lag?
- rosser 12y ago
  fencing ... relates to a master/slave cluster as in how? Because when you promote a slave, you also need to fence writes to the old master, otherwise you can end up in a "split-brain" scenario, where the old and new masters are both accepting writes, and nobody's replicating. Have fun cleaning that up. (them not being relational is irrelevant to replication) I disagree. Their being relational imposes extra constraints upon replication. ACID? So how do you monitor e.g. the replication lag? Icinga invokes this: https://bucardo.org/check_postgres/check_postgres.pl.html#replicate_row https://bucardo.org/check_postgres/check_postgres.pl.html#re... Look, I'm rapidly losing interest in going back and forth like this. You don't seem very interested in the validity of another perspective, but rather just keep finding fault in things that don't do it your preferred way. If you want to have a discussion, I'll play. If not, let's just walk away.
  - moe 12y ago
    Because when you promote a slave, you also need to fence writes to the master, otherwise you can end up in a "split-brain" scenario. There is only one master, hence there can not be a "split brain". You seem to be confusing master/slave and multi-master configuration (which pg doesn't support). I disagree. Their being relational imposes extra constraints upon replication. ACID? Well, it doesn't. Look, I'm rapidly losing interest in going back and forth like this. You claim things are "easy" that you clearly haven't done before. I was merely calling you out on that, but agree the discussion is unlikely to go anywhere from here. Edit: Oh and you retouching your comments all the time doesn't help either (the split-brain paragraph just changed...). I'm out.