Aggiornamento: ho postato su questo nei forum AWS - per favore, entra e chiedi lì .
Al momento della scrittura, Amazon RDS non supporta la replica fisica al di fuori di RDS. Puoi GRANTutilizzare gli utenti con il REPLICATIONdiritto utilizzando un rds_superuserlogin, ma non puoi configurare replicationvoci per IP esterni in pg_hba.conf.
Inoltre, quando si crea un gruppo di parametri DB in RDS, alcuni parametri chiave vengono visualizzati ma bloccati, ad esempio archive_command, a cui è bloccato /etc/rds/dbbin/pgscripts/rds_wal_archive %p. AWS RDS per PostgreSQL non sembra esporre questi WAL per l'accesso esterno (diciamo, tramite S3) come sarebbe necessario se si dovesse usare la replica di spedizione WAL per PITR esterno.
Quindi, a questo punto, se si desidera wal-shipping, non utilizzare RDS. È un database in scatola facile da usare, ma facile da usare spesso significa che è anche limitato, e questo è certamente il caso qui. Come sottolinea Joe Love nei commenti, fornisce la spedizione WAL e PITR all'interno di RDS , ma non è possibile accedere a WAL da quello esterno RDS.
Quindi è necessario utilizzare le funzionalità di backup di RDS: dump, istantanee e il proprio PITR basato su WAL.
Anche se RDS ti ha permesso di effettuare connessioni di replica (per pg_basebackupo streaming di replica) e ti ha permesso di accedere a WAL archiviato, potresti non essere in grado di consumare effettivamente quel WAL. RDS esegue un PostgreSQL con patch, anche se nessuno sa quanto sia pesantemente modificato o se altera in modo significativo il formato su disco. Funziona anche con l'architettura selezionata da Amazon, che è probabilmente x64 Linux, ma non facilmente determinabile. Poiché PostgreSQL sul formato del disco e la replica dipendono dall'architettura, è possibile replicare solo su host con la stessa architettura utilizzata da Amazon RDS e solo se la build PostgreSQL era compatibile con la loro.
Tra le altre cose, ciò significa che non hai un modo semplice per migrare da RDS. Dovresti interrompere tutte le scritture nel database abbastanza a lungo per eseguire un pg_dump, ripristinarlo e far funzionare il nuovo DB. I soliti trucchi con replica e failover, con rsync, ecc., Non funzioneranno perché non si ha accesso diretto all'host DB.
Anche se RDS avesse eseguito un PostgreSQL senza patch, Amazon probabilmente non avrebbe voluto permetterti di eseguire lo streaming WAL in RDS o importarlo in RDS pg_basebackupper motivi di sicurezza. PostgreSQL considera la directory dei dati come contenuto attendibile e se hai creato funzioni intelligenti "LANGUAGE c" che agganciano la funzionalità interna o fanno qualsiasi altra cosa complicata potresti essere in grado di sfruttare il server per ottenere un accesso maggiore di quello che dovresti avere . Quindi Amazon non consentirà WAL in entrata in qualunque momento presto.
Potrebbero supportare l'invio di WAL in uscita, ma continuano ad applicarsi i problemi di cui sopra con compatibilità di formato, libertà di apportare modifiche, ecc.
Invece dovresti usare uno strumento come Londiste o Bucardo.