That seems like overkill, and that much abstraction forces a black box on us. Bucardo multi-master, and asynchronous replication We need synchronous replication, and we don’t need multi-master. Repmgr replication management and automatic failover Does one thing, does it well. Plus, it’s written by 2nd Quadrant. Tools, tools
| priority | active | |----+---------+------------------+---------+------------------+----------+--------| | 1 | master | | prod | api-1-prod | 102 | t | | 2 | standby | 1 | prod | api-2-prod | 101 | f | | 3 | standby | 1 | prod | reporting-0-prod | -1 | f | The Repmgr setup Repmgr maintains its own small database and table with the nodes and information on the replication state between them.
can lose some data, but the service needs to be up. Please fix it soon! The disk usage is at 80%, and the DB is crawling! The disk usage was only 72% last night, and we were running the bulk deletion script. How did it go up to 80% overnight? I need to ﬁx the issue before debugging.
row invisible to future transactions. • AUTOVACUUM “removes” the invisible rows over time and adds them to the free space map per relation. • Actual disk space is not reclaimed to the OS during routine operations **. • The default AUTOVACUUM worker configurations are ineffective for big tables. We have no choice but to make them far more aggressive.
data now and more report queries too. So we need more IOPS, and more cores. Easy Peasy! I’ll start the clone tonight. LOG: started streaming WAL from primary at 4038/29000000 on timeline 2 There, it’s transferring the data at 40MB/s. We should have our shiny new box up and running in the morning.
part of setting a standby. Think about it. • We can prevent against WAL recovery issues using: • WAL archives • Rsync • Filesystem backups • Things to monitor: network throughput, DB load and disk i/o on master
due to recovery conflicts. • Applying back pressure on primary is an option but causes bloat. • We cannot use different schemas while using synchronous replication. • We can change the ﬁlesystem or hardware without affecting replication. • Things to monitor: replication lag, slow queries, bloat, vacuum