Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # Utilizzo delle caratteristiche di PostgreSQL supportate da Amazon RDS for PostgreSQL Amazon RDS per PostgreSQL supporta molte delle funzioni PostgreSQL più comuni. Ad esempio, PostgreSQL ha una funzione di pulizia automatica che esegue la manutenzione di routine sul database. La funzione autovacuum è attivata per impostazione predefinita. Sebbene sia possibile disattivare questa caratteristica, è consigliabile tenerla attiva. Comprendere questa funzionalità e cosa puoi fare per assicurarti che funzioni come dovrebbe è un compito di base di qualsiasi DBA. Per ulteriori informazioni sulla caratteristica autovacuum, consulta [Utilizzo della funzionalità di autovacuum di PostgreSQL in Amazon RDS per PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Autovacuum.md). Per ulteriori informazioni su altre attività DBA comuni, [Attività DBA comuni per Amazon RDS for PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.md). RDS for PostgreSQL supporta anche estensioni che aggiungono funzionalità importanti all'istanza database. Ad esempio, è possibile utilizzare l'estensione PostGIS per lavorare con i dati spaziali o utilizzare l'estensione pg\$1cron per pianificare la manutenzione dall'istanza. Per ulteriori informazioni sulle estensioni PostgreSQL, consulta [Utilizzo delle estensioni PostgreSQL con Amazon RDS for PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Extensions.md). I wrapper di dati esterni sono un tipo specifico di estensione progettato per consentire all'istanza database RDS for PostgreSQL di lavorare con altri tipi di dati o database commerciali. Per ulteriori informazioni sui wrapper di dati esterni supportati da RDS for PostgreSQL, consulta [Utilizzo dei wrapper di dati esterni supportati per Amazon RDS for PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Extensions.foreign-data-wrappers.md). Di seguito sono riportate informazioni su alcune altre caratteristiche supportate da RDS per PostgreSQL. **Topics** + [ # Tipi di dati personalizzati ed enumerazioni con RDS for PostgreSQL ](PostgreSQL.Concepts.General.FeatureSupport.AlterEnum.md) + [ # Trigger di eventi per RDS for PostgreSQL ](PostgreSQL.Concepts.General.FeatureSupport.EventTriggers.md) + [ # Pagine di grandi dimensioni per RDS for PostgreSQL ](PostgreSQL.Concepts.General.FeatureSupport.HugePages.md) + [ # Esecuzione della replica logica per Amazon RDS for PostgreSQL ](PostgreSQL.Concepts.General.FeatureSupport.LogicalReplication.md) + [ # Configurazione dell'autenticazione IAM per le connessioni di replica logica ](PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.md) + [ # Disco RAM per stats\$1temp\$1directory ](PostgreSQL.Concepts.General.FeatureSupport.RamDisk.md) + [ # Spazi tabelle per RDS for PostgreSQL ](PostgreSQL.Concepts.General.FeatureSupport.Tablespaces.md) + [ # Regole di confronto RDS per PostgreSQL per EBCDIC e altre migrazioni di mainframe ](PostgreSQL.Collations.mainframe.migration.md) + [ # Gestione della sincronizzazione logica degli slot per RDS per PostgreSQL ](Appendix.PostgreSQL.CommonDBATasks.pglogical.slot.synchronization.md) # Tipi di dati personalizzati ed enumerazioni con RDS for PostgreSQL PostgreSQL supporta la creazione di tipi di dati personalizzati e l'utilizzo delle enumerazioni. Per ulteriori informazioni sulla creazione e sull'utilizzo di enumerazioni e altri tipi di dati, consulta [Tipi enumerati](https://www.postgresql.org/docs/14/datatype-enum.html) nella documentazione di PostgreSQL. Di seguito è riportato un esempio di creazione di un tipo come enumerazione e quindi di inserimento di valori in una tabella. ``` CREATE TYPE rainbow AS ENUM ('red', 'orange', 'yellow', 'green', 'blue', 'purple'); CREATE TYPE CREATE TABLE t1 (colors rainbow); CREATE TABLE INSERT INTO t1 VALUES ('red'), ( 'orange'); INSERT 0 2 SELECT * from t1; colors -------- red orange (2 rows) postgres=> ALTER TYPE rainbow RENAME VALUE 'red' TO 'crimson'; ALTER TYPE postgres=> SELECT * from t1; colors --------- crimson orange (2 rows) ``` # Trigger di eventi per RDS for PostgreSQL Tutte le versioni attuali di PostgreSQL supportano i trigger di eventi, così come tutte le versioni disponibili di RDS for PostgreSQL. Puoi utilizzare l'account utente principale (di default `postgres`) per creare, modificare, rinominare ed eliminare i trigger degli eventi. I trigger di eventi sono a livello di istanza database, quindi possono essere applicati a tutti i database in un'istanza. Ad esempio, il seguente codice crea un trigger di eventi che stampa l'utente corrente alla fine di ogni comando DDL (Data Definition Language). ``` CREATE OR REPLACE FUNCTION raise_notice_func() RETURNS event_trigger LANGUAGE plpgsql AS $$ BEGIN RAISE NOTICE 'In trigger function: %', current_user; END; $$; CREATE EVENT TRIGGER event_trigger_1 ON ddl_command_end EXECUTE PROCEDURE raise_notice_func(); ``` Per ulteriori informazioni sui trigger di eventi PostgreSQL, consulta [Trigger di eventi](https://www.postgresql.org/docs/current/static/event-triggers.html) nella documentazione di PostgreSQL. L'utilizzo dei trigger di eventi PostgreSQL su Amazon RDS prevede diverse limitazioni. Questi sono i seguenti: + Non puoi creare trigger di eventi su repliche di lettura. Tuttavia, puoi creare trigger di eventi su una replica di lettura master. I trigger di eventi vengono quindi copiati nella replica di lettura. I trigger di eventi sulla replica di lettura non vengono attivati sulla replica di lettura in caso di modifiche da parte del master. Tuttavia, se viene promossa la replica di lettura, i trigger di eventi esistenti si attivano in caso di operazioni del database. + Per eseguire un aggiornamento principale della versione a un'istanza database PostgreSQL che utilizza i trigger di eventi, assicurati di eliminare i trigger di eventi prima dell'aggiornamento dell'istanza. # Pagine di grandi dimensioni per RDS for PostgreSQL Le *pagine di grandi dimensioni* sono una caratteristica di gestione della memoria che riduce il sovraccarico quando un'istanza database lavora con grandi blocchi di memoria contigui, come quelli utilizzati dai buffer condivisi. Questa caratteristica di PostgreSQL è supportata da tutte le versioni RDS for PostgreSQL attualmente disponibili. Allocate enormi pagine per la vostra applicazione utilizzando chiamate `mmap` o `SYSV` memoria condivisa. RDS for PostgreSQL supporta pagine da 4 KB e 2 MB. È possibile attivare o disattivare pagine di grandi dimensioni modificando il valore del parametro `huge_pages`. La caratteristica è attivata per impostazione predefinita per tutte le classi di istanze database diverse dalle classi di istanza micro, small e medium. RDS for PostgreSQL usa le pagine di grandi dimensioni in base alla memoria condivisa disponibile. Se l'istanza database non è in grado di utilizzare le pagine di grandi dimensioni a causa dei limiti della memoria condivisa, Amazon RDS impedisce l'avvio dell'istanza database. In questo caso, Amazon RDS imposta lo stato dell'istanza database su uno stato dei parametri incompatibile. In questo caso, puoi impostare il parametro `huge_pages` su `off` per permettere a Amazon RDS di avviare l'istanza database. Il parametro `shared_buffers` è essenziale per impostare il pool della memoria condivisa richiesto per l'utilizzo delle pagine di grandi dimensioni. Il valore predefinito per il parametro `shared_buffers` utilizza una macro dei parametri del database. Questa macro imposta una percentuale di 8 KB in totale disponibili per la memoria dell'istanza database. Quando si utilizzano pagine di dimensioni enormi, queste pagine vengono allocate insieme alle pagine enormi. Amazon RDS inserisce un'istanza database in uno stato di parametri non compatibile se i parametri della memoria condivisa sono impostati in modo da richiedere più del 90% della memoria dell'istanza database. Per ulteriori informazioni sulla gestione della memoria PostgreSQL, consulta [Consumo di risorse](https://www.postgresql.org/docs/current/static/runtime-config-resource.html) nella documentazione di PostgreSQL. # Esecuzione della replica logica per Amazon RDS for PostgreSQL A partire dalla versione 10.4, RDS per PostgreSQL supporta la pubblicazione e la sottoscrizione della sintassi SQL introdotta in PostgreSQL 10. Per ulteriori informazioni, consulta [Replica logica](https://www.postgresql.org/docs/current/logical-replication.html) nella documentazione di PostgreSQL. **Nota** Oltre alla funzionalità di replica logica nativa di PostgreSQL introdotta in PostgreSQL 10, RDS per PostgreSQL supporta anche l'estensione `pglogical`. Per ulteriori informazioni, consulta [Utilizzo di pglogical per sincronizzare i dati tra le istanze](Appendix.PostgreSQL.CommonDBATasks.pglogical.md). Di seguito sono riportate informazioni sull'impostazione della replica logica per un'istanza database RDS for PostgreSQL. **Topics** + [ ## Comprendere la replica logica e la decodifica logica ](#PostgreSQL.Concepts.General.FeatureSupport.LogicalDecoding) + [ ## Lavorare con gli slot di replica logica ](#PostgreSQL.Concepts.General.FeatureSupport.LogicalReplicationSlots) + [ ## Replica dei dati a livello di tabella mediante la replica logica ](#PostgreSQL.Concepts.LogicalReplication.Tables) ## Comprendere la replica logica e la decodifica logica RDS for PostgreSQL supporta lo streaming delle modifiche write-ahead log (WAL) utilizzando slot di replica logica di PostgreSQL. Supporta inoltre l'utilizzo della decodifica logica. Puoi configurare gli slot di replica logica nell'istanza ed effettuare lo streaming delle modifiche del database tramite questi slot in un client come `pg_recvlogical`. Gli slot di replica logica sono creati a livello di database e supportano le connessioni di replica a un singolo database. I client più comuni per la replica logica di PostgreSQL AWS Database Migration Service sono o un host gestito in modo personalizzato su un'istanza Amazon EC2. Lo slot di replica logica non contiene informazioni sul ricevitore del flusso. Inoltre, non è necessario che il target sia un database di replica. Se configuri uno slot di replica logica e non leggi lo slot, i dati possono venire scritti e riempire rapidamente lo storage dell'istanza database. La replica logica e la decodifica logica PostgreSQL in Amazon RDS vengono attivate con un parametro, un tipo di connessione di replica e un ruolo di sicurezza. Il client per la decodifica logica può essere qualsiasi client in grado di stabilire una connessione di replica a un database in un'istanza database PostgreSQL. **Per attivare la decodifica logica per un'istanza database RDS for PostgreSQL** 1. Assicurati che l'account utente che stai utilizzando abbia i seguenti ruoli: + Il ruolo `rds_superuser` in modo da poter attivare la replica logica + Il ruolo `rds_replication` per concedere le autorizzazioni per gestire gli slot logici e per eseguire lo streaming dei dati utilizzando gli slot logici 1. Impostare il parametro statico `rds.logical_replication` su 1. Come parte dell'applicazione di questo parametro, imposta anche i parametri `wal_level`, `max_wal_senders`, `max_replication_slots` e `max_connections`. Le modifiche di questi parametri possono aumentare la generazione dei WAL, quindi imposta il parametro `rds.logical_replication` solo quando si utilizzano gli slot logici. 1. Affinché il parametro statico `rds.logical_replication` abbia effetto, riavviare l'istanza database. 1. Creare uno slot di replica logica come spiegato nella sezione successiva. Questo processo richiede che venga specificato un plug-in di decodifica. Attualmente RDS for PostgreSQL supporta i plugin di output test\$1decoding e wal2json forniti con PostgreSQL. Per ulteriori informazioni sulla decodifica logica di PostgreSQL, consulta la [documentazione di PostgreSQL](https://www.postgresql.org/docs/current/static/logicaldecoding-explanation.html). ## Lavorare con gli slot di replica logica Puoi utilizzare i comandi SQL per lavorare con gli slot logici. Ad esempio, il seguente comando crea uno slot logico denominato `test_slot` che utilizza il plugin di output PostgreSQL predefinito test\$1decoding `test_decoding`. ``` SELECT * FROM pg_create_logical_replication_slot('test_slot', 'test_decoding'); slot_name | xlog_position -----------------+--------------- regression_slot | 0/16B1970 (1 row) ``` Per elencare gli slot logici, utilizza il seguente comando: ``` SELECT * FROM pg_replication_slots; ``` Per eliminare uno slot logico, utilizza il seguente comando: ``` SELECT pg_drop_replication_slot('test_slot'); pg_drop_replication_slot ----------------------- (1 row) ``` Per ulteriori esempi su come lavorare con gli slot di replica logica, consulta gli [esempi di decodifica logica](https://www.postgresql.org/docs/9.5/static/logicaldecoding-example.html) nella documentazione PostgreSQL. Una volta creato lo slot di replica logica, puoi iniziare lo streaming. Nell'esempio seguente viene illustrato il modo in cui la decodifica logica viene controllata tramite il protocollo di replica in streaming. Questo esempio utilizza il programma pg\$1recvlogical, incluso nella distribuzione PostgreSQL. Questa operazione richiede che l'autenticazione del client sia configurata per permettere le connessioni alla replica. ``` pg_recvlogical -d postgres --slot test_slot -U postgres --host -instance-name.111122223333.aws-region.rds.amazonaws.com -f - --start ``` Per visualizzare il contenuto della vista `pg_replication_origin_status`, eseguire una query sulla funzione `pg_show_replication_origin_status`. ``` SELECT * FROM pg_show_replication_origin_status(); local_id | external_id | remote_lsn | local_lsn ----------+-------------+------------+----------- (0 rows) ``` ## Replica dei dati a livello di tabella mediante la replica logica In RDS per PostgreSQL è possibile utilizzare la replica logica per replicare i dati dalle tabelle di origine alle tabelle di destinazione. La replica logica esegue prima un caricamento iniziale dei dati esistenti dalle tabelle di origine e quindi continua a replicare le modifiche in corso. 1. **Creare le tabelle di origine** Stabilisci la connessione al database di origine nell’istanza database RDS per PostgreSQL: ``` source=> CREATE TABLE testtab (slno int primary key); CREATE TABLE ``` 1. **Inserire i dati nelle tabelle di origine** ``` source=> INSERT INTO testtab VALUES (generate_series(1,1000)); INSERT 0 1000 ``` 1. **Creare una pubblicazione per le tabelle di origine** + Crea una pubblicazione per le tabelle di origine: ``` source=> CREATE PUBLICATION testpub FOR TABLE testtab; CREATE PUBLICATION ``` + Utilizza una query SELECT per verificare i dettagli della pubblicazione creata: ``` source=> SELECT * FROM pg_publication; oid | pubname | pubowner | puballtables | pubinsert | pubupdate | pubdelete | pubtruncate | pubviaroot --------+---------+----------+--------------+-----------+-----------+-----------+-------------+------------ 115069 | testpub | 16395 | f | t | t | t | t | f (1 row) ``` + Verifica che le tabelle di origine siano state aggiunte alla pubblicazione: ``` source=> SELECT * FROM pg_publication_tables; pubname | schemaname | tablename ---------+------------+----------- testpub | public | testtab (1 rows) ``` + Per replicare tutte le tabelle di un database, utilizza: ``` CREATE PUBLICATION testpub FOR ALL TABLES; ``` + Se la pubblicazione è già stata creata per una singola tabella e devi aggiungere una nuova tabella, puoi eseguire la query seguente per aggiungere nuove tabelle alla pubblicazione esistente: ``` ALTER PUBLICATION add table ; ``` 1. **Connettersi al database di destinazione e creare tabelle di destinazione** + Stabilisci la connessione al database di destinazione nell’istanza database di destinazione. Crea le tabelle di destinazione con gli stessi nomi delle tabelle di origine: ``` target=> CREATE TABLE testtab (slno int primary key); CREATE TABLE ``` + Assicurati che nelle tabelle di destinazione non siano presenti dati eseguendo una query SELECT sulle tabelle: ``` target=> SELECT count(*) FROM testtab; count ------- 0 (1 row) ``` 1. **Creare e verificare la sottoscrizione nel database di destinazione** + Crea la sottoscrizione nel database di destinazione: ``` target=> CREATE SUBSCRIPTION testsub CONNECTION 'host= port=5432 dbname= user= password=' PUBLICATION testpub; NOTICE: Created replication slot "testsub" on publisher CREATE SUBSCRIPTION ``` + Utilizza una query SELECT per verificare che la sottoscrizione sia abilitata: ``` target=> SELECT oid, subname, subenabled, subslotname, subpublications FROM pg_subscription; oid | subname | subenabled | subslotname | subpublications -------+---------+------------+-------------+----------------- 16434 | testsub | t | testsub | {testpub} (1 row) ``` + Quando la sottoscrizione viene creata, tutti i dati delle tabelle di origine vengono caricati nelle tabelle di destinazione. Esegui una query SELECT sulle tabelle di destinazione per verificare che i dati iniziali vengano caricati: ``` target=> SELECT count(*) FROM testtab; count ------- 1000 (1 row) ``` 1. **Verificare lo slot di replica nel database di origine** La creazione di una sottoscrizione nel database di destinazione ha per effetto la creazione di uno slot di replica nel database di origine. Verifica i dettagli dello slot di replica tramite la seguente query SELECT sul database di origine: ``` source=> SELECT * FROM pg_replication_slots; slot_name | plugin | slot_type | datoid | database | temporary | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn | wal_status | safe_wal_size ----------+----------+-----------+--------+----------+-----------+--------+------------+------+--------------+-------------+---------------------+------------+--------------- testsub | pgoutput | logical | 115048 | source | f | t | 846 | | 6945 | 58/B4000568 | 58/B40005A0 | reserved | (1 row) ``` 1. **Eseguire il test della replica** + Verifica se le modifiche ai dati nelle tabelle di origine vengono replicate nelle tabelle di destinazione inserendo righe nelle tabelle di origine: ``` source=> INSERT INTO testtab VALUES(generate_series(1001,2000)); INSERT 0 1000 source=> SELECT count(*) FROM testtab; count ------- 2000 (1 row) ``` + Controlla il numero di righe nelle tabelle di destinazione per verificare che i nuovi inserti vengano replicati: ``` target=> SELECT count(*) FROM testtab; count ------- 2000 (1 row) ``` 1. **Aggiornare la sottoscrizione dopo l’aggiunta di tabelle** + Quando aggiungi nuove tabelle a una pubblicazione esistente, è obbligatorio aggiornare la sottoscrizione per rendere effettive le modifiche: ``` ALTER SUBSCRIPTION REFRESH PUBLICATION; ``` + Questo comando recupera dal publisher le informazioni mancanti sulle tabelle e avvia la replica delle tabelle che sono state aggiunte alle pubblicazioni sottoscritte dopo la creazione o l’ultimo aggiornamento della sottoscrizione. # Configurazione dell'autenticazione IAM per le connessioni di replica logica A partire dalle versioni 11 e successive di RDS per PostgreSQL, puoi AWS Identity and Access Management utilizzare l'autenticazione (IAM) per le connessioni di replica. Questa funzionalità migliora la sicurezza consentendo di gestire l'accesso al database utilizzando i ruoli IAM anziché le password. Funziona sia a livello di granularità del cluster che dell'istanza e segue lo stesso modello di sicurezza dell'autenticazione IAM standard. L'autenticazione IAM per le connessioni di replica è una funzionalità opzionale. Per abilitarla, imposta il `rds.iam_auth_for_replication` parametro su 1 nel cluster DB o nel gruppo di parametri DB. Poiché si tratta di un parametro dinamico, non è necessario riavviare il cluster o l'istanza DB, il che consente di sfruttare l'autenticazione IAM con i carichi di lavoro esistenti senza tempi di inattività. Prima di abilitare questa funzionalità, è necessario soddisfare i prerequisiti elencati di seguito. **Topics** + [ ## Prerequisiti ](#PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.Prerequisites) + [ ## Abilitazione dell'autenticazione IAM per le connessioni di replica ](#PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.Enabling) + [ ## Disabilitazione dell'autenticazione IAM per le connessioni di replica ](#PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.Disabling) + [ ## Considerazioni e limitazioni ](#PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.Limitations) ## Prerequisiti Per utilizzare l'autenticazione IAM per le connessioni di replica, devi soddisfare tutti i seguenti requisiti: + L'istanza DB RDS per PostgreSQL deve essere la versione 11 o successiva. + Nell'istanza DB di Publisher RDS for PostgreSQL: + Abilita l'autenticazione del database IAM. Per ulteriori informazioni, consulta [Abilitazione e disabilitazione dell’autenticazione database IAM](UsingWithRDS.IAMDBAuth.Enabling.md). + Abilita la replica logica impostando il `rds.logical_replication` parametro su 1. Nella replica logica, l'editore è il database RDS di origine per PostgreSQL che invia i dati al database degli abbonati. Per ulteriori informazioni, consulta [Esecuzione della replica logica per Amazon RDS for PostgreSQL](PostgreSQL.Concepts.General.FeatureSupport.LogicalReplication.md). **Nota** Sia l'autenticazione IAM che la replica logica devono essere abilitate sull'istanza DB di Publisher RDS for PostgreSQL. Se una delle due non è abilitata, non è possibile utilizzare l'autenticazione IAM per le connessioni di replica. ## Abilitazione dell'autenticazione IAM per le connessioni di replica Completa i seguenti passaggi per abilitare l'autenticazione IAM per la connessione di replica. **Per abilitare l'autenticazione IAM per le connessioni di replica** 1. Verifica che il cluster o l'istanza DB RDS for PostgreSQL soddisfi tutti i prerequisiti per l'autenticazione IAM con connessioni di replica. Per informazioni dettagliate, vedi [Prerequisiti](#PostgreSQL.Concepts.General.FeatureSupport.IAMLogicalReplication.Prerequisites). 1. Configura il `rds.iam_auth_for_replication` parametro in base alla configurazione di RDS per PostgreSQL: + Per le istanze DB RDS per PostgreSQL: modifica il gruppo di parametri DB. + Per i cluster Multi-AZ: modifica il gruppo di parametri del cluster DB. Impostato su `rds.iam_auth_for_replication` 1. Si tratta di un parametro dinamico che ha effetto immediato senza richiedere il riavvio. **Nota** I cluster Multi-AZ utilizzano solo gruppi di parametri del cluster DB. I gruppi di parametri delle singole istanze non possono essere modificati nei cluster Multi-AZ. 1. Connect al database e assegna i ruoli necessari all'utente di replica: I seguenti comandi SQL garantiscono i ruoli necessari per abilitare l'autenticazione IAM per le connessioni di replica: ``` -- Grant IAM authentication role GRANT rds_iam TO replication_user_name; -- Grant replication privileges ALTER USER replication_user_name WITH REPLICATION; ``` Dopo aver completato questi passaggi, l'utente specificato deve utilizzare l'autenticazione IAM per le connessioni di replica. **Importante** Quando abiliti la funzionalità, gli utenti con entrambi i `rds_iam` `rds_replication` ruoli devono utilizzare l'autenticazione IAM per le connessioni di replica. Ciò vale sia che i ruoli vengano assegnati direttamente all'utente o ereditati da altri ruoli. ## Disabilitazione dell'autenticazione IAM per le connessioni di replica Puoi disabilitare l'autenticazione IAM per le connessioni di replica utilizzando uno dei seguenti metodi: + Imposta il `rds.iam_auth_for_replication` parametro su 0 nel gruppo di parametri DB per le istanze DB o nel gruppo di parametri del cluster DB per i cluster Multi-AZ. + In alternativa, puoi disabilitare una di queste funzionalità sul tuo cluster o istanza DB RDS for PostgreSQL: + Disabilita la replica logica impostando il parametro su 0 `rds.logical_replication` + Disabilita l'autenticazione IAM Quando disabiliti la funzionalità, le connessioni di replica possono utilizzare le password del database per l'autenticazione. **Nota** Le connessioni di replica per gli utenti senza il `rds_iam` ruolo possono utilizzare l'autenticazione tramite password anche quando la funzionalità è abilitata. ## Considerazioni e limitazioni Prendi in considerazione le seguenti limitazioni e considerazioni quando utilizzi l'autenticazione IAM per le connessioni di replica logica: + Questa funzionalità è disponibile solo per le versioni 11 e successive di RDS per PostgreSQL. + L'editore deve supportare l'autenticazione IAM per le connessioni di replica. + Per impostazione predefinita, il token di autenticazione IAM scade dopo 15 minuti. Potrebbe essere necessario aggiornare le connessioni di replica di lunga durata prima della scadenza del token. # Disco RAM per stats\$1temp\$1directory Puoi utilizzare il parametro `rds.pg_stat_ramdisk_size` di RDS for PostgreSQL per specificare la memoria di sistema allocata a un disco RAM per l'archiviazione di `stats_temp_directory` PostgreSQL. Il parametro del disco RAM è disponibile solo in RDS per PostgreSQL versione 14 e precedenti. In determinati carichi di lavoro, l'impostazione di questo parametro può migliorare le prestazioni e ridurre I/O i requisiti. Per ulteriori informazioni su `stats_temp_directory`, consulta la [ documentazione di PostgreSQL.](https://www.postgresql.org/docs/current/static/runtime-config-statistics.html#GUC-STATS-TEMP-DIRECTORY). Per impostare un disco RAM per `stats_temp_directory`, imposta il parametro `rds.pg_stat_ramdisk_size` su un valore diverso da zero nel gruppo di parametri utilizzato dalla tua istanza database. Questo parametro utilizza MB, quindi è necessario specificare un valore intero. Espressioni, formule e funzioni non sono valide per il parametro `rds.pg_stat_ramdisk_size`. Assicurati di riavviare l'istanza database in modo da applicare il nuovo valore. Per informazioni sull'estensione dei parametri consulta [Gruppi di parametri per Amazon RDS](USER_WorkingWithParamGroups.md). Ad esempio, il AWS CLI comando seguente imposta il parametro del disco RAM su 256 MB. ``` aws rds modify-db-parameter-group \ --db-parameter-group-name pg-95-ramdisk-testing \ --parameters "ParameterName=rds.pg_stat_ramdisk_size, ParameterValue=256, ApplyMethod=pending-reboot" ``` Dopo il riavvio, esegui il seguente comando per visualizzare lo stato di `stats_temp_directory`: ``` postgres=> SHOW stats_temp_directory; ``` Il comando deve restituire quanto segue. ``` stats_temp_directory --------------------------- /rdsdbramdisk/pg_stat_tmp (1 row) ``` # Spazi tabelle per RDS for PostgreSQL RDS for PostgreSQL supporta gli spazi tabelle per la compatibilità. Poiché tutto lo storage si trova su un unico volume logico, non è possibile utilizzare le tablespace per la I/O suddivisione o l'isolamento. I nostri benchmark e la nostra esperienza indicano che un singolo volume logico è la configurazione migliore per la maggior parte dei casi d'uso. Per creare e utilizzare spazi tabelle con l'istanza database di RDS for PostgreSQL occorre il ruolo `rds_superuser`. L'account utente principale dell'istanza database RDS for PostgreSQL (nome di default, `postgres`) è un membro di questo ruolo. Per ulteriori informazioni, consulta [Informazioni su ruoli e autorizzazioni di PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Roles.md). Se si specifica un nome di file quando si crea uno spazio tabelle, il prefisso del percorso è `/rdsdbdata/db/base/tablespace`. Nell'esempio seguente i file dello spazio tabelle vengono posizionati in `/rdsdbdata/db/base/tablespace/data`. Questo esempio presuppone l'esistenza di un utente (ruolo) `dbadmin` e la concessione del ruolo `rds_superuser` necessario per lavorare con gli spazi tabella. ``` postgres=> CREATE TABLESPACE act_data OWNER dbadmin LOCATION '/data'; CREATE TABLESPACE ``` Per ulteriori informazioni sugli spazi tabella PostgreSQL, consulta [Spazi tabella](https://www.postgresql.org/docs/current/manage-ag-tablespaces.html) nella documentazione di PostgreSQL. # Regole di confronto RDS per PostgreSQL per EBCDIC e altre migrazioni di mainframe RDS per PostgreSQL versione 10 e successive include la versione 60.2 di ICU, basata su Unicode 10.0 e include le regole di confronto tratte da Unicode Common Locale Data Repository, CLDR 32. Queste librerie di internazionalizzazione del software garantiscono la coerenza a livello di presentazione delle codifiche dei caratteri, indipendentemente dal sistema operativo o dalla piattaforma. Per ulteriori informazioni su Unicode CLDR-32, consulta la [Nota di rilascio di CLDR 32](https://cldr.unicode.org/index/downloads/cldr-32) sul sito Web Unicode CLDR. Puoi saperne di più sui componenti di internazionalizzazione per Unicode (ICU) nel sito Web [ICU Technical Committee (ICU-TC)](https://icu.unicode.org/home). Per informazioni su ICU-60, consulta la pagina [Download ICU 60](https://icu.unicode.org/download/60). A partire dalla versione 14.3, RDS per PostgreSQL include anche regole di confronto che facilitano l'integrazione e la conversione dei dati dai sistemi basati su EBCDIC. Il codice di interscambio decimale con codice binario esteso codifica *EBCDIC* (Extended Binary Coded Decimal Interchange Code) è comunemente utilizzata dai sistemi operativi mainframe. Queste regole di confronto fornite da Amazon RDS sono definite in modo restrittivo per ordinare solo i caratteri Unicode mappati direttamente alle tabelle codici EBCDIC. I caratteri sono ordinati in base all'ordine dei punti di codice EBCDIC per consentire la convalida dei dati dopo la conversione. Queste regole di confronto non includono i moduli denormalizzati, né i caratteri Unicode non associati direttamente a un carattere nella tabella codici EBCDIC di origine. Le mappature dei caratteri tra le tabelle codici EBCDIC e i punti di codice Unicode si basano su tabelle pubblicate da IBM. Il set completo è disponibile presso IBM come [file compresso](http://download.boulder.ibm.com/ibmdl/pub/software/dw/java/cdctables.zip) da scaricare. RDS per PostgreSQL ha utilizzato queste mappature con gli strumenti forniti da ICU per creare le regole di confronto elencate nelle tabelle di questa sezione. I nomi delle regole di confronto includono la lingua e il paese richiesti da ICU. Tuttavia, le tabelle codici EBCDIC non specificano le lingue e alcune tabelle codici EBCDIC coprono più paesi. Ciò significa che la parte relativa alla lingua e al paese dei nomi delle regole di confronto nella tabella è arbitraria e non deve necessariamente corrispondere alla lingua corrente. In altre parole, il numero della tabella codici è la parte più importante del nome della regola di confronto in questa tabella. È possibile utilizzare una qualsiasi delle regole di confronto elencate nelle tabelle seguenti in qualsiasi database RDS per PostgreSQL. + [Unicode to EBCDIC collations table](#ebcdic-table)— Alcuni strumenti di migrazione dei dati mainframe utilizzano LATIN1 o LATIN9 codificano ed elaborano internamente i dati. Tali strumenti utilizzano schemi round trip per preservare l'integrità dei dati e supportare la conversione inversa. Le regole di confronto contenute in questa tabella possono essere utilizzate da strumenti che elaborano i dati utilizzando la LATIN1 codifica, che non richiede una gestione speciale. + [Unicode to LATIN9 collations table](#latin9-table): è possibile utilizzare queste regole di confronto in qualsiasi database RDS per PostgreSQL. Nella tabella seguente sono disponibili le regole di confronto disponibili in RDS per PostgreSQL che mappano le tabelle codici EBCDIC ai punti di codice Unicode. Si consiglia di utilizzare le regole di confronto contenute in questa tabella per lo sviluppo di applicazioni che richiedono l'ordinamento in base all'ordine delle tabelle codici IBM. | Nome della regola di confronto PostgreSQL | Descrizione della mappatura e dell'ordinamento delle tabelle codici | | --- | --- | | da-DK-cp277-x-icu | I caratteri Unicode mappati direttamente alla tabella codici IBM EBCDIC 277 (per tabelle di conversione) sono ordinati in base all'ordine dei punti di codice IBM CP 277 | | de-DE-cp273-x-icu | I caratteri Unicode mappati direttamente alla tabella codici IBM EBCDIC 273 (per tabelle di conversione) sono ordinati in base all'ordine dei punti di codice IBM CP 273 | | en-GB-cp285-x-icu | I caratteri Unicode mappati direttamente alla tabella codici IBM EBCDIC 285 (per tabelle di conversione) sono ordinati in base all'ordine dei punti di codice IBM CP 285 | | en-US-cp037-x-icu | I caratteri Unicode mappati direttamente alla tabella codici IBM EBCDIC 037 (per tabelle di conversione) sono ordinati in base all'ordine dei punti di codice IBM CP 37 | | es-ES-cp284-x-icu | I caratteri Unicode mappati direttamente alla tabella codici IBM EBCDIC 284 (per tabelle di conversione) sono ordinati in base all'ordine dei punti di codice IBM CP 284 | | fi-FI-cp278-x-icu | I caratteri Unicode mappati direttamente alla tabella codici IBM EBCDIC 278 (per tabelle di conversione) sono ordinati in base all'ordine dei punti di codice IBM CP 278 | | fr-FR-cp297-x-icu | I caratteri Unicode mappati direttamente alla tabella codici IBM EBCDIC 297 (per tabelle di conversione) sono ordinati in base all'ordine dei punti di codice IBM CP 297 | | it-IT-cp280-x-icu | I caratteri Unicode mappati direttamente alla tabella codici IBM EBCDIC 280 (per tabelle di conversione) sono ordinati in base all'ordine dei punti di codice IBM CP 280 | | nl-BE-cp500-x-icu | I caratteri Unicode mappati direttamente alla tabella codici IBM EBCDIC 500 (per tabelle di conversione) sono ordinati in base all'ordine dei punti di codice IBM CP 500 | Amazon RDS fornisce una serie di regole di confronto aggiuntive che ordinano i punti di codice Unicode LATIN9 mappati ai caratteri utilizzando le tabelle pubblicate da IBM, nell'ordine dei punti di codice originali in base alla tabella codici EBCDIC dei dati di origine. | Nome della regola di confronto PostgreSQL | Descrizione della mappatura e dell'ordinamento delle tabelle codici | | --- | --- | | DA-DK-CP1142 m-x-icu | I caratteri Unicode mappati ai LATIN9 caratteri originariamente convertiti da IBM EBCDIC Code Page 1142 (per tabelle di conversione) vengono ordinati secondo l'ordine dei punti di codice IBM CP 1142 | | de-DE-CP1141 m-x-icu | I caratteri Unicode mappati ai LATIN9 caratteri originariamente convertiti dalla pagina di codice IBM EBCDIC 1141 (per tabelle di conversione) vengono ordinati secondo l'ordine dei punti di codice IBM CP 1141 | | it-GB-CP1146 m-x-icu | I caratteri Unicode mappati ai LATIN9 caratteri originariamente convertiti da IBM EBCDIC Code Page 1146 (per tabelle di conversione) sono ordinati secondo l'ordine dei punti di codice IBM CP 1146 | | it-US-CP1140 m-x-icu | I caratteri Unicode mappati ai LATIN9 caratteri originariamente convertiti dalla pagina di codice IBM EBCDIC 1140 (per tabelle di conversione) vengono ordinati secondo l'ordine dei punti di codice IBM CP 1140 | | es-ES-CP1145 m-x-icu | I caratteri Unicode mappati ai LATIN9 caratteri originariamente convertiti da IBM EBCDIC Code Page 1145 (per tabelle di conversione) vengono ordinati secondo l'ordine dei punti di codice IBM CP 1145 | | fi-FI-CP1143 m-x-icu | I caratteri Unicode mappati ai LATIN9 caratteri originariamente convertiti da IBM EBCDIC Code Page 1143 (per tabelle di conversione) vengono ordinati secondo l'ordine dei punti di codice IBM CP 1143 | | fr-FR-CP1147 m-x-icu | I caratteri Unicode mappati ai LATIN9 caratteri originariamente convertiti da IBM EBCDIC Code Page 1147 (per tabelle di conversione) vengono ordinati secondo l'ordine dei punti di codice IBM CP 1147 | | it-IT-CP1144 m-x-icu | I caratteri Unicode mappati ai LATIN9 caratteri originariamente convertiti da IBM EBCDIC Code Page 1144 (per tabelle di conversione) vengono ordinati secondo l'ordine dei punti di codice IBM CP 1144 | | nl-BE-CP1148 m-x-icu | I caratteri Unicode mappati ai LATIN9 caratteri originariamente convertiti da IBM EBCDIC Code Page 1148 (per tabelle di conversione) sono ordinati secondo l'ordine dei punti di codice IBM CP 1148 | Di seguito viene fornito un esempio di come utilizzare una regola di confronto RDS per PostgreSQL. ``` db1=> SELECT pg_import_system_collations('pg_catalog'); pg_import_system_collations ----------------------------- 36 db1=> SELECT '¤' < 'a' col1; col1 ------ t db1=> SELECT '¤' < 'a' COLLATE "da-DK-cp277-x-icu" col1; col1 ------ f ``` Si consiglia di utilizzare le regole di confronto contenute nella [Unicode to EBCDIC collations table](#ebcdic-table) e nella [Unicode to LATIN9 collations table](#latin9-table) per lo sviluppo di applicazioni che richiedono l'ordinamento in base all'ordine delle tabelle codici IBM. Le seguenti regole di confronto (con il suffisso «b») sono visibili anche in`pg_collation`, ma sono destinate all'uso da parte degli strumenti di integrazione e migrazione dei dati mainframe, AWS che mappano le code page con cambiamenti di punti di codice specifici e richiedono una gestione speciale delle regole di confronto. In altre parole, si sconsiglia l'utilizzo delle regole di confronto elencate di seguito. + DA-DK-277 b-x-icu + Da-DK-1142 b-x-icu + De-DE-CP273 b-x-icu + de-DE-CP1141 b-x-icu + it-GB-CP1146 b-x-icu + it-GB-CP285 b-x-icu + it-IT-CP037 b-x-icu + it-IT-CP1140 b-x-icu + it-IT-CP1145 b-x-icu + fr-ES-CP284 b-x-icu + fi-FI-CP1143 b-x-icu + FR-IT-CP1147 b-x-icu + fr-IT-CP297 b-x-icu + it-IT-CP1144 b-x-icu + IT-IT-CP280 b-x-icu + NL-BE-CP1148 b-x-icu + nl-BE-CP500 b-x-icu [Per ulteriori informazioni sulla migrazione delle applicazioni dagli ambienti mainframe a, vedi Cos'è la modernizzazione del mainframe? AWSAWS](https://docs.aws.amazon.com/m2/latest/userguide/what-is-m2.html) . Per ulteriori informazioni sulla gestione delle regole di confronto in PostgreSQL, consulta la pagina relativa al [supporto delle regole di confronto](https://www.postgresql.org/docs/current/collation.html) nella documentazione di PostgreSQL. # Gestione della sincronizzazione logica degli slot per RDS per PostgreSQL A partire dalla versione Community PostgreSQL 17, è stata introdotta una nuova funzionalità per sincronizzare automaticamente gli slot di replica logica dai server primari a quelli in standby tramite il parametro `sync_replication_slots` o la funzione `pg_sync_replication_slots()` correlata, che sincronizza manualmente gli slot in esecuzione. Queste funzionalità sono disponibili a partire da RDS per PostgreSQL 17. Una configurazione tipica prevede un’istanza primaria e la relativa [replica di lettura](USER_PostgreSQL.Replication.ReadReplicas.md), oltre a un subscriber di replica logica alla primaria. Assicurati che l’abbonamento sia creato con l’opzione di failover impostata su true: ``` CREATE SUBSCRIPTION subname CONNECTION 'host=...' PUBLICATION pubname WITH (failover = true); ``` In questo modo viene creato uno slot logico sul publisher con il failover abilitato. ``` postgres=> SELECT slot_name, slot_type, failover FROM pg_catalog.pg_replication_slots; slot_name | slot_type | failover -----------+-----------+---------- subname | logical | t (1 row) ``` Abilitando la sincronizzazione degli slot, tutti gli slot di replica logica di failover sull’istanza primaria vengono creati automaticamente negli standby fisici e sincronizzati periodicamente. Assicurati che i seguenti valori siano stati impostati tramite [gruppi di parametri](USER_WorkingWithParamGroups.Associating.md): + `rds.logical_replication` deve essere `1` per abilitare la replica logica + `hot_standby_feedback` deve essere `1` sullo standby + `rds.logical_slot_sync_dbname` sullo standby deve essere impostato su un nome di database valido Il valore predefinito del parametro è `postgres`. Se l’istanza di pubblicazione logica dispone del database `postgres`, non è necessario modificare il parametro predefinito. + `synchronized_standby_slots` sull’istanza primaria deve essere impostato sullo slot di replica fisico dello standby destinato alla sincronizzazione + `sync_replication_slots` deve essere `1` per abilitare sincronizzazione automatica Con uno slot di abbonamento abilitato al failover e i valori dei parametri sopra indicati, quando viene promosso uno standby, il subscriber può modificare il proprio abbonamento a questa nuova istanza promossa e continuare la replica logica senza problemi.