mb4nck

The (first?) version of the real recording is now up: https://media.ccc.de/v/37c3-11859-operation_triangulation_wh...

At least the first version of the recording is now up: https://media.ccc.de/v/37c3-11859-operation_triangulation_wh...

Video was taken down by bilibili.com, this is apparently a repost of it on Twitter: https://twitter.com/_nomoreencore/status/1688207369124368384

See also https://www.reddit.com/r/LK99/comments/15jscal/comment/jv1mx...

spock and pgedge are cool, but they are NOT open source (and they try hard to make it look like they are).

It is under the Confluent license (with s/confluent/pgedge/), basically a source-available-but-Amazon-cannot-use-it kind of license.

OTOH the PolarDB specific changes seem to be contained enough that if you decide to run it in production, you can probably just apply most of the changes from the v11 branch yourself.

But I agree it's not a very good look to code-drop something on a .2 release when there's been 2,5 years of fixes.

I don't know, maybe you should.

CockroachDB seems to be a distributed database system written in Go which has implemented a Postgres query/wire protocol compatibility layer.

PolarDB is a Postgres fork actually using the Postgres codebase and extending it to a distributed database system. Maybe one day they can unfork because it's possible to implement PolarDB on top of Postgres as an extension and/or they contribute/get all their changes into Postgres core.

Looks like it, yeah.

Also, Postgres 12 introduced pluggable storage, which might help to implement a shared-nothing architecture without huge changes to vanilla Postgres (I haven't looked at how large their delta is)

But that's also true for e.g. the US and russian presidents, no? Except those actually hold real power.

In practise, most german presidents will just be way too old four years after they leave office to be a viable candidate, and it looks a bit absurd for them to be pushed back into the office, exactly because there's very little real power.

For the record, on Debian unstable:

  root@pg1:~# LANG=C apt install postgresql-12 
  Reading package lists... Done
  [...]
  0 upgraded, 32 newly installed, 0 to remove and 0 not upgraded.
  Need to get 59.7 MB of archives.
  After this operation, 240 MB of additional disk space will be used.
  Do you want to continue? [Y/n] ^C
  root@pg1:~# LANG=C apt install postgresql-12 postgresql-12-postgis-3
  Reading package lists... Done
  [...]
  0 upgraded, 105 newly installed, 0 to remove and 0 not upgraded.
  Need to get 104 MB of archives.
  After this operation, 418 MB of additional disk space will be used.
  Do you want to continue? [Y/n]

There is a fork/spoon here, which supports 9.4+: https://github.com/credativ/pg_checksums

It is also available as a Debian package for the above versions via apt.postgresql.org.

Notably, that feature got written by somebody from Salesforce (I assume on their work time, but not sure), and finished up by a Postgres major contributor. It might be the first major contribution from Salesforce outside of all the stuff Tom Lane did when he was working there.

There are no good multi-master solution with a HA focus available for Postgres, at least no open source ones.

The patroni project checks most of your other requirements: docker/containerized design with leader election/continuing operation via etcd or another external DCS. Not sure how easy upgrades are but I think the procedure is at least documented.

To the contrary, I think journalists often only get to advise on the headline, and the editors then choose/override one to their liking.

patroni builds upon etcd and (optionally) haproxy, two rather mature pieces of infrastructure (which can both be made HA on their own if SPOFs are to be avoided).

I understand where you are coming from, but having this kind of multi-server-who-is-master knowledge baked into Postgres itself will surely take another couple of releases, if it will be included at all.

Probably BDR (bi-directional replication, master-master like logical replication) will be there first, but whether the question is whether it will help a lot for local scale-out workloads (as opposed to glueing two datacenters together and allow transactions on both sides).

Note that starting from Postgres 10 (which this thread is about), you don't need to adjust wal_level and max_wal_senders (or max_replication_slots, for that matter) anymore. You still have to enable hot_standby=on on the standbys, though.

(and it is in general a good idea to keep the configuration the same as much as possible between primary and standbys).

You can get pg_rewind for 9.4 (and 9.3 in its branch) here:

https://github.com/vmware/pg_rewind/tree/REL9_4_STABLE

It's from the people who wrote it upstream, they provide the code there for earlier Postgres releases.

About redirection of write queries to the master, from 10 on, you will be able to specify all members of the cluster in the connection string and demand to connect to the master (like "postgresql://host1:5432,host2:5432/somedb?target_session_attrs=read-write"); libpq will do this automatically for you then, see the parameters "host" (now plural) and "target_session_attr" in section 33.1.2. here: https://www.postgresql.org/docs/devel/static/libpq-connect.h...

About raft-based leader-election, I believe the current recommendation is to look at patroni ( https://github.com/zalando/patroni), which has been built for docker and is now being integrated with Kubernetes; however, I don't think there is an inherent limitation that it couldn't be run on bare-metal.