Is replication not supported for Azure Postgres Flexible Server?
Zone redundancy can not be treated as alternative for Disaster Recovery. Such an important feature is missing. May be until it is in preview?
Hi #Abhijeet Azure Postgres Flexible server supports logical replication. You can refer to this documentation for more details. Let me know if you have additional queries.
Regards,
Oury
If by "replication" you mean "read replicas" then indeed this is currently not supported.
High Availability options, in theory, do implement replication, but as of 10.2022 still do not support read access and are meant for fail-over purposes.
On 12th of Oct 2022 they did announce that they are working on Read Replicas, and that the feature will enter public preview "soon-ish" but no specific dates are yet communicated.
See: https://techcommunity.microsoft.com/t5/azure-database-for-postgresql/ignite-2022-continued-innovation-with-azure-database-for/ba-p/3651653
Related
Is it possible to replicate a specific subset of data (certain schema,dbs') to a readonly copy of Azure postgres flexible server. Thanks Brian
From Logical replication and logical decoding in Azure Database for PostgreSQL - Flexible Server
Limitations
Read replicas - Azure Database for PostgreSQL read replicas are not
currently supported with flexible servers.
At the moment this is not possible with azure so we ended up using pglogical replication to copy specific databases over between the regions.
Read Replica feature will be available in Azure Database for PostgreSQL Flexible server around 6/30/22 in private preview and subsequently in public preview in Q3 quarter.
Is there anyway to enable logical replication wal_level = logical on Google Cloud Postgres instance? I want to do CDC (change data capture) to stream WAL Record to Apache Kafka. Thanks for your help!
Update:
This feature now is enabled on Google Cloud SQL. To enable wal_level to replication you just need to set the flag cloudsql.logical_decoding as on.
For more details:
https://cloud.google.com/sql/docs/postgres/replication/configure-logical-replication
Note: this issue was solved in August, 30th release.
No, this is not supported by Cloud SQL for PostgreSQL.
The Cloud SQL engineering team is working on this issue, here you can find a Feature Request. You can star it in order to get notified when it gets updated. Also you can write a comment there and ask a question. Please, bear in mind that we don't have an ETA for it.
I am reading about Arangodb and it is what I want to use for a new startup. I am confused on the asynchronous replication. Can I do asynchronous replication without having the enterprise edition? I will likely have multiple machines receiving a read only copy for backup and maybe in different locations. The enterprise edition talks about datacenter to datacenter replication and so I am confused. Can I get a read only remote asynchronous replicant with the community edition?
Thanx
You can do remote replication the way you describe using the documented methods here:
https://docs.arangodb.com/3.3/Manual/Administration/Replication/
This is not per se an enterprise feature. The enterprise feature dc2dc just does the whole operational setup and runtime for you. Is there a specific reason, why you would like to stay clear of it? It is free for evaluation.
The evaluations T&C are here: https://www.arangodb.com/customer-agreement
Is there some kind of native Postgres tool they use, or is it a custom one? Are the replicas always in sync or do they drift apart from time to time?
With Multi-AZ RDS replication is synchronous. And since AWS like to be in full control of their software, it’s most likely a customised replication (but I couldn’t tell you for sure).
I need to replicate a PostgreSQL database server as follows:
Two servers are adjacent to each-other - one is the master and the other standby. If the master fails, the standby takes over. Replication from master to slave needs to be failsafe, hence, synchronous. The standby will not be used for any querying unless it has become a master. So, no high-availability/load-balancing is required.
There is another backup server at a remote location. Data from the master server mentioned above will be replicated to this remote server asynchronously and in batches. Time is not a factor at all in this replication - a couple of hours is just fine. This server would be used just for backup.
I've studied the currently available replication solutions from the PostgreSQL docs as well as from Google, but can't decide which combination of synchronous-asynchronous solutions would I need.
The closest I came up with is using pgpool-II for scenario 1 and Mammoth for scenario 2. However, as pgpool is statement-based, what would happen to queries containing rand() and now()?
Please note that I'd rather use free and open-source replication tools.
Also, just a side question - according to scenario 1 above, when the master fails, the standby will take over. Would the master-slave role be reversed after that, or would after the recovery of the master server the slave would go back to its standby state?
Any suggestion would be highly appreciated. Thanks.
I suggest using DRBD for scenario 1 and either 9.0 built-in replication or Slony for scenario 2.
Before PostgreSQL 9.1 (not yet released), there is no other synchronous replication solution available, and DRBD is widely established for this purpose. Together with Pacemaker or Heartbeat, which come with all the scripts needed for PostgreSQL monitoring and switchover, you have a very robust and fairly easy to manage solution. (In fact, I'd consider continuing to use DRBD even after 9.1 comes out; it's just a lot easier and has a longer track record.)
For the cross-site asynchronous, you could try the built-in replication of PostgreSQL 9.0, perhaps in conjunction with repmgr for monitoring and management. Alternatively, you could try the (now a bit) old-school Slony, but I'd guess it will more complicated for your needs.
You didn't mention if the server in question was on a specific version or if this was a new project with the freedom to choose the version. The answers vary based on that information.
If you are starting with a clean slate, I would recommend designing based on the PostgreSQL 9.1 beta. The final version will be released long before you would be ready to go into a production environment and it has binary synchronous replication built-in.
I've been using the built-in asynchronous replication in PostgreSQL for years in almost the exact same scenario you describe and it has always been rock-solid for me. It's become even better with 9.0 with Hot standby and it's become much easier to configure and maintain. 9.1 provides the only missing piece you require.
However, if you are trying to replicate an existing server, built-in asynchronous replication with aggressive settings for "checkpoint_timeout" a very frequent backup of unarchived WAL files could be sufficient until you can upgrade to 9.1.
The bottom line here is that you can get exactly what you want is with stock PostgreSQL 9.1--no third-party products required.
As for failover, it is not an automatic process, you'll need to handle that yourself. I would recommend that after a failover, switching the roles of the two machines until either the next failover event or until a controlled manual failover during a scheduled outage during a slow period of use. Again, this is not automatic and much be managed by the administrator (via shell scripts, presumably).