Part 1. Introduction.Part 2. Replication. Repmgr.Part 3. Auto-failover. Repmgr daemons.Part 4. HA. Backup. Repmgr daemons. Barman.Part 5. Testing. Ansible. Final thoughts. At this part, we will: make PostgreSQL high available using repmgr daemons use barman for streaming backup combine HA feature and barman to store master and standby backups in the same barman place and …
Part 1. Introduction.Part 2. Replication. Repmgr.Part 3. Auto-failover. Repmgr daemons.Part 4. HA. Backup. Repmgr daemons. Barman.Part 5. Testing. Ansible. Final thoughts. At this part, we will create two repmgr daemons on backup server and setup auto-failover. Why not place daemons on db servers? Because in this case we don’t have voting majority, which dispose to …
Fault tolerant PostgreSQL cluster. Part 3. Auto-failover. Repmgr daemon. Read More »
Part 1. Introduction.Part 2. Replication. Repmgr.Part 3. Auto-failover. Repmgr daemons.Part 4. HA. Backup. Repmgr daemons. Barman.Part 5. Testing. Ansible. Final thoughts. At this part, we will setup master (db1) and standby (db2) replication servers using repmgr. First, create repmgr user and database on db1 server. su – postgres createuser -s repmgr psql -c “alter user …
Fault tolerant PostgreSQL cluster. Part 2. Replication. Repmgr. Read More »
Right off the bat, this is what you’ll get in the end: Synhronous standby server using repmgr Repmgr daemons running not on db servers No need of witness server with own PostgreSQL instance Split-brain tolerant auto-failover High available configuration without additional utils, such as HAProxy Backup server using barman Asynchronous WAL streaming Became synchronous, if …
ORADeveloper may save your connection information (including password) on disk if you want to. You can choose to save your connection with password or not. All passwords are encrypted and stored in private app memory area which is inaccessible by other programs. Passwords are using only for connecting and reconnecting to database.