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à. # Amazon RDS per MySQL Amazon RDS supporta varie versioni di MySQL per le istanze database. Per informazioni complete sulle versioni supportate, consulta [Versioni di MySQL in Amazon RDS](MySQL.Concepts.VersionMgmt.md). Creare un'istanza database di Amazon RDS per MySQL, utilizza gli strumenti di gestione o le interfacce di Amazon RDS. A questo punto puoi effettuare le seguenti operazioni: + Ridimensionare l'istanza database + Autorizzare le connessioni all'istanza database + Creare e ripristinare da backup o snapshot + Creare istanze secondarie Multi-AZ + Creare repliche di lettura + Monitorare le prestazioni dell'istanza database Per archiviare e accedere ai dati nell'istanza database, utilizza le utilità e le applicazioni MySQL standard. Amazon RDS for MySQL è conforme a molti standard di settore. Ad esempio, puoi utilizzare i database RDS per MySQL per creare applicazioni conformi a HIPAA. Puoi utilizzare database RDS per MySQL per archiviare informazioni sanitarie, inclusi dati sanitari protetti (PHI), in base a un Contratto di società in affari (BAA) con AWS. Amazon RDS per MySQL soddisfa inoltre i requisiti di sicurezza Federal Risk and Authorization Management Program (FedRAMP). Inoltre, Amazon RDS per MySQL ha ricevuto una certificazione FedRAMP Joint Authorization Board (JAB) Provisional Authority to Operate (P-ATO) alla FedRAMP HIGH Baseline all'interno delle AWS GovCloud (US). Per ulteriori informazioni sugli standard di conformità supportati, consulta [Conformità di AWS Cloud](https://aws.amazon.com/compliance/). Per ulteriori informazioni sulle caratteristiche in ogni versione di MySQL, consulta la pagina relativa alle [caratteristiche principali di MySQL](https://dev.mysql.com/doc/refman/8.0/en/features.html) nella documentazione di MySQL. Prima di creare un'istanza database, completa i passaggi in [Configurazione dell’ambiente Amazon RDS](CHAP_SettingUp.md). Quando crei un'istanza database, l'utente principale di RDS ottiene privilegi DBA, con alcune limitazioni. Utilizzare questo account per attività amministrative, ad esempio la creazione di account di database aggiuntivi. Puoi creare: + Istanze DB + Snapshot DB + Ripristini point-in-time + Backup automatizzati + Backup manuali Puoi utilizzare istanze database che eseguono MariaDB all'interno di un cloud privato virtuale (VPC) basato su Amazon VPC. Inoltre, puoi attivare varie opzioni per aggiungere altre funzionalità all'istanza database MySQL. Amazon RDS supporta le implementazioni multi-AZ per MySQL come soluzione failover a elevata disponibilità. **Importante** Per offrire un'esperienza di servizio gestito, Amazon RDS non fornisce accesso shell alle istanze database. Limita anche l'accesso ad alcune procedure di sistema e tabelle che richiedono privilegi avanzati. Puoi accedere al database utilizzando i client SQL standard come il client mysql. Tuttavia, non è possibile accedere direttamente all'host utilizzando Telnet o Secure Shell (SSH). **Topics** + [ # Supporto delle funzionalità MySQL su Amazon RDS ](MySQL.Concepts.FeatureSupport.md) + [ # Versioni di MySQL in Amazon RDS ](MySQL.Concepts.VersionMgmt.md) + [ # Connessione all’istanza database MySQL ](USER_ConnectToInstance.md) + [ # Protezione delle connessioni di istanze database MySQL ](securing-mysql-connections.md) + [ # Prestazioni delle query migliorate per RDS per MySQL con Amazon RDS Optimized Reads ](rds-optimized-reads.md) + [ # Prestazioni di scrittura migliorate con Scritture ottimizzate per Amazon RDS per MySQL ](rds-optimized-writes.md) + [ # Aggiornamenti del motore di database RDS per MySQL ](USER_UpgradeDBInstance.MySQL.md) + [ # Aggiornamento di una versione del motore di snapshot di database MySQL ](mysql-upgrade-snapshot.md) + [ # Importazione di dati in un’istanza database Amazon RDS per MySQL ](MySQL.Procedural.Importing.Other.md) + [ # Uso della replica MySQL in Amazon RDS ](USER_MySQL.Replication.md) + [ # Configurazione di cluster attivi-attivi in RDS per MySQL ](mysql-active-active-clusters.md) + [ # Esportazione di dati da un'istanza database MySQL tramite la replica ](MySQL.Procedural.Exporting.NonRDSRepl.md) + [ # Opzioni per le istanze database MySQL ](Appendix.MySQL.Options.md) + [ # Parametri per MySQL ](Appendix.MySQL.Parameters.md) + [ # Attività di log DBA comuni per istanze database MySQL ](Appendix.MySQL.CommonDBATasks.md) + [ # Fuso orario locale per le istanze database MySQL ](MySQL.Concepts.LocalTimeZone.md) + [ # Problemi e limitazioni note per Amazon RDS for MySQL ](MySQL.KnownIssuesAndLimitations.md) + [ # Riferimento delle stored procedure RDS per MySQL ](Appendix.MySQL.SQLRef.md) # Supporto delle funzionalità MySQL su Amazon RDS RDS per MySQL supporta la maggior parte delle caratteristiche e delle funzionalità di MySQL. Alcune funzionalità potrebbero avere un supporto o privilegi limitati. Puoi filtrare le nuove funzionalità di Amazon RDS alla pagina [Quali sono le novità del database?](https://aws.amazon.com/about-aws/whats-new/database/). Per **Prodotti**, scegli **Amazon RDS**. Quindi esegui la ricerca utilizzando parole chiave come **MySQL 2022**. **Nota** I seguenti elenchi non sono esaustivi. **Topics** + [ ## Supporto delle funzionalità MySQL nelle versioni principali di Amazon RDS per MySQL ](#MySQL.Concepts.FeatureSupport.MajorVersions) + [ ## Motori di storage supportati per RDS for MySQL ](#MySQL.Concepts.Storage) + [ ## Uso di memcached e altre opzioni con MySQL su Amazon RDS ](#MySQL.Concepts.General.Options) + [ ## Precaricamento della cache InnoDB per MySQL su Amazon RDS ](#MySQL.Concepts.InnoDBCacheWarming) + [ ## Modifiche per un linguaggio inclusivo in RDS per MySQL 8.4 ](#mysql-8-4-inclusive-language-changes) + [ ## Caratteristiche di MySQL non supportate da Amazon RDS ](#MySQL.Concepts.Features) ## Supporto delle funzionalità MySQL nelle versioni principali di Amazon RDS per MySQL Nelle seguenti sezioni sono disponibili informazioni sul supporto delle funzionalità MySQL nelle versioni principali di Amazon RDS per MySQL: **Topics** + [ ### Supporto di MySQL 8.4 in Amazon RDS ](#MySQL.Concepts.FeatureSupport.8-4) Per informazioni sulle versioni secondarie di Amazon RDS per MySQL supportate, consulta [Versioni secondarie di MySQL supportate in Amazon RDS](MySQL.Concepts.VersionMgmt.md#MySQL.Concepts.VersionMgmt.Supported). ### Supporto di MySQL 8.4 in Amazon RDS Amazon RDS supporta le nuove funzionalità seguenti per le istanze database che eseguono MySQL 8.4 o versioni successive. + **Libreria crittografica**: RDS for MySQL ha sostituito OpenSSL con (), che è certificato FIPS 140-3. AWS Libcrypto AWS-LC Per ulteriori informazioni, consulta il repository all'indirizzo. AWS-LC GitHub [https://github.com/aws/aws-lc](https://github.com/aws/aws-lc) + **Modifiche TLS**: RDS per MySQL supporta solo TLS 1.2 e TLS 1.3. Per ulteriori informazioni, consulta [Supporto di SSL/TLS per le istanze database MySQL in Amazon RDS](MySQL.Concepts.SSLSupport.md). + **Supporto memcached**: l’interfaccia memcached non è più disponibile in MySQL 8.4. Per ulteriori informazioni, consulta [Supporto per memcached MySQL](Appendix.MySQL.Options.memcached.md). + **Plugin di autenticazione predefinito**: il plugin di autenticazione predefinito è `caching_sha2_password`. Per ulteriori informazioni, consulta [Plugin di autenticazione MySQL predefinito](MySQL.KnownIssuesAndLimitations.md#MySQL.Concepts.KnownIssuesAndLimitations.authentication-plugin). + **Utilità client `mysqlpump`**: l’utilità client `mysqlpump` non è più disponibile in MySQL 8.4. Per ulteriori informazioni, consulta [Privilegio basato sui ruoli per RDS per MySQL](Appendix.MySQL.CommonDBATasks.privilege-model.md) e [mysqldump e mysqlpump](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-large-mysql-mariadb-databases/mysqldump-and-mysqlpump.html) nel *Prontuario AWS *. + **Stored procedure della replica gestita**: quando si utilizzano stored procedure per gestire la replica con un utente di replica configurato con `caching_sha2_password`, è necessario configurare TLS specificando `SOURCE_SSL=1`. `caching_sha2_password` è il plugin di autenticazione predefinito per RDS per MySQL 8.4. + **Modifiche al comportamento dei parametri**: i parametri seguenti sono stati modificati in MySQL 8.4. + `innodb_dedicated_server`: il parametro è ora abilitato per impostazione predefinita. Per ulteriori informazioni, consulta [Configurazione delle dimensioni del pool di buffer e della capacità dei log di redo in MySQL 8.4](Appendix.MySQL.CommonDBATasks.Config.Size.8.4.md). + `innodb_buffer_pool`: il motore di database ora calcola questo parametro, ma è possibile sovrascrivere l’impostazione. Per ulteriori informazioni, consulta [Configurazione delle dimensioni del pool di buffer e della capacità dei log di redo in MySQL 8.4](Appendix.MySQL.CommonDBATasks.Config.Size.8.4.md). + `innodb_redo_log_capacity`: il parametro ora controlla la dimensione dei file di log di redo. Il motore di database ora calcola questo parametro, ma è possibile sovrascrivere l’impostazione. Per ulteriori informazioni, consulta [Configurazione delle dimensioni del pool di buffer e della capacità dei log di redo in MySQL 8.4](Appendix.MySQL.CommonDBATasks.Config.Size.8.4.md). + **Parametri obsoleti o rimossi**: RDS per MySQL ha rimosso i seguenti parametri dai gruppi di parametri per le istanze database MySQL 8.4. Il `innodb_redo_log_capacity` parametro ora controlla la dimensione dei file di log di redo. + `innodb_log_file_size` + `innodb_log_files_in_group` + **Nuovi valori predefiniti per i parametri**: i parametri seguenti hanno nuovi valori predefiniti per le istanze database MySQL 8.4: + Diversi parametri della Community MySQL relativi alle prestazioni sono cambiati. Per ulteriori informazioni, consulta [What is New in MySQL 8.4 since MySQL 8.0](https://dev.mysql.com/doc/refman/8.4/en/mysql-nutshell.html). Si consiglia di testare le prestazioni dell’applicazione in RDS per MySQL 8.4 prima di migrare un’istanza di produzione. + `innodb_purge_threads`: il valore predefinito è impostato sulla formula `LEAST({DBInstanceVCPU/2},4)` per evitare che la lunghezza dell’elenco della cronologia di InnoDB aumenti troppo. + `group_replication_exit_state_action`: il valore predefinito è `OFFLINE_MODE`, allineato con il valore predefinito nella Community MySQL. Per ulteriori informazioni, consulta [Considerazioni e best practice per i cluster attivi-attivi di RDS per MySQL](mysql-active-active-clusters-considerations-limitations.md#mysql-active-active-clusters-considerations). + `binlog_format`: il valore predefinito è `ROW`, allineato con il valore predefinito nella Community MySQL. È possibile modificare il parametro per le istanze database Single-AZ o Multi-AZ, ma non per i cluster di database Multi-AZ. I cluster di database Multi-AZ utilizzano la replica semisincrona e quando `binlog_format` è impostato su `MIXED` o `STATEMENT`, la replica non riesce. + **Modifiche per un linguaggio inclusivo**: in RDS per MySQL 8.4 sono state apportate modifiche da RDS per MySQL 8.0 relative alle parole chiave e agli schemi di sistema per un linguaggio inclusivo. Per ulteriori informazioni, consulta [Modifiche per un linguaggio inclusivo in RDS per MySQL 8.4](#mysql-8-4-inclusive-language-changes). Per un elenco di tutte le funzionalità e tutte le modifiche di MySQL 8.4, consulta [What Is New in MySQL 8.4 since MySQL 8.0](https://dev.mysql.com/doc/refman/8.4/en/mysql-nutshell.html) nella documentazione MySQL. Per un elenco delle funzionalità non supportate, consulta [Caratteristiche di MySQL non supportate da Amazon RDS](#MySQL.Concepts.Features). ## Motori di storage supportati per RDS for MySQL MySQL supporta più motori di storage con funzionalità diverse, ma non tutti sono ottimizzati per il recovery e la durabilità dei dati. Amazon RDS supporta completamente il motore di archiviazione InnoDB per le istanze database MySQL. Le funzionalità di Amazon RDS come Point-In-Time restore e snapshot restore richiedono un motore di storage recuperabile e sono supportate solo per il motore di storage InnoDB. Per ulteriori informazioni, consulta [Supporto per memcached MySQL](Appendix.MySQL.Options.memcached.md). Il motore di storage Federated non è attualmente supportato da Amazon RDS for MySQL. Per gli schemi creati dall'utente, il motore di archiviazione MyISAM non supporta un ripristino affidabile e può causare la perdita o il danneggiamento dei dati quando MySQL viene riavviato dopo un ripristino, impedendo che il ripristino o il ripristino delle istantanee funzionino come previsto. Point-In-Time Tuttavia, se scegli comunque di utilizzare MyISAM con Amazon RDS gli snapshot possono essere utili in alcune situazioni. **Nota** Le tabelle del sistema nello schema `mysql` possono trovarsi nello storage MyISAM. Per convertire le tabelle MyISAM esistenti in tabelle InnoDB, è possibile utilizzare il comando `ALTER TABLE`, ad esempio `alter table TABLE_NAME engine=innodb;`. Tieni presente che MyISAM e InnoDB hanno diversi punti di forza e di debolezza, quindi è necessario valutare a fondo le conseguenze di questa modifica sulle applicazioni, prima di eseguirla. MySQL 5.1, 5.5 e 5.6 non sono più supportati in Amazon RDS. Puoi tuttavia ripristinare gli snapshot di MySQL 5.1, 5.5 e 5.6 esistenti. Quando ripristini uno snapshot di MySQL 5.1, 5.5 o 5.6, l'istanza database viene aggiornata automaticamente a MySQL 5.7. ## Uso di memcached e altre opzioni con MySQL su Amazon RDS La maggior parte dei motori di database Amazon RDS supporta gruppi di opzioni che permettono di selezionare caratteristiche aggiuntive per l'istanza database. Le istanze di database RDS per MySQL supportano l'opzione `memcached`, una cache semplice basata su chiave. Per ulteriori informazioni su `memcached` e altre opzioni, consulta [Opzioni per le istanze database MySQL](Appendix.MySQL.Options.md). Per ulteriori informazioni sull'utilizzo di gruppi di opzioni, consulta [Uso di gruppi di opzioni](USER_WorkingWithOptionGroups.md). ## Precaricamento della cache InnoDB per MySQL su Amazon RDS Il precaricamento della cache InnoDB può offrire vantaggi in termini di prestazioni per l'istanza database MySQL salvando lo stato corrente del pool di buffer quando l'istanza database viene arrestata e quindi ricaricando il pool di buffer con le informazioni salvate quando l'istanza database si avvia. Ciò evita la necessità di preparare il pool di buffer dal normale utilizzo del database e permette invece di precaricare il pool di buffer con le pagine per le query comuni note. Il file che archivia le informazioni del pool di buffer salvato archivia solo i metadati per le pagine che si trovano nel pool di buffer e non le pagine stesse. Di conseguenza, il file non richiede molto spazio di storage. La dimensione del file equivale circa allo 0,2% della dimensione della cache. Ad esempio, per una cache da 64 GiB, il file di precaricamento della cache è di 128 MiB. Per ulteriori informazioni sul precaricamento della cache InnoDB, consulta la pagina relativa al [salvataggio e ripristino dello stato del pool di buffer](https://dev.mysql.com/doc/refman/8.0/en/innodb-preload-buffer-pool.html) nella documentazione di MySQL. Le istanze database RDS per MySQL supportano il precaricamento della cache InnoDB. Per abilitare il precaricamento della cache InnoDB, imposta i parametri `innodb_buffer_pool_dump_at_shutdown` e `innodb_buffer_pool_load_at_startup` su 1 nel gruppo di parametri per l'istanza database. La modifica dei valori di questi parametri in un gruppo di parametri ha effetto in tutte le istanze database MySQL che utilizzano tale gruppo di parametri. Per abilitare il precaricamento della cache InnoDB per istanze database MySQL specifiche, devi creare un nuovo gruppo di parametri per tali istanze. Per informazioni sui gruppi di parametri, consulta [Gruppi di parametri per Amazon RDS](USER_WorkingWithParamGroups.md). Il precaricamento della cache InnoDB fornisce principalmente un vantaggio in termini di prestazioni per le istanze database che utilizzano lo storage standard. Se utilizzi lo storage PIOPS non riscontrerai generalmente un vantaggio significativo in termini di prestazioni. **Importante** Se l'istanza database MySQL non si arresta normalmente, ad esempio durante un failover, lo stato del pool di buffer non viene salvato nel disco. In questo caso, al riavvio dell'istanza database, MySQL carica il file del pool di buffer disponibile. Ciò non comporta alcun problema, ma il pool di buffer ripristinato potrebbe non riflettere lo stato più recente del pool di buffer prima del riavvio. Per fare in modo che sia disponibile uno stato recente del pool di buffer per precaricare la cache InnoDB all'avvio, è consigliabile eseguire periodicamente un dump del pool di buffer "on demand". Puoi creare un evento per eseguire il dump del pool di buffer automaticamente e a intervalli regolari. L'istruzione seguente crea ad esempio un evento denominato `periodic_buffer_pool_dump` che esegue il dump del pool di buffer ogni ora. ``` 1. CREATE EVENT periodic_buffer_pool_dump 2. ON SCHEDULE EVERY 1 HOUR 3. DO CALL mysql.rds_innodb_buffer_pool_dump_now(); ``` Per ulteriori informazioni sugli eventi MySQL, consulta la [sintassi degli eventi](https://dev.mysql.com/doc/refman/8.0/en/events-syntax.html) nella documentazione di MySQL. ### Dump e caricamento del pool di buffer on demand Puoi salvare e caricare la cache InnoDB "on demand". + Per eseguire il dump dello stato corrente del pool di buffer su disco, chiama la stored procedure [mysql.rds\$1innodb\$1buffer\$1pool\$1dump\$1now](mysql-stored-proc-warming.md#mysql_rds_innodb_buffer_pool_dump_now). + Per caricare lo stato salvato del pool di buffer dal disco, chiama la stored procedure [mysql.rds\$1innodb\$1buffer\$1pool\$1load\$1now](mysql-stored-proc-warming.md#mysql_rds_innodb_buffer_pool_load_now). + Per annullare un'operazione di caricamento in corso, chiama la stored procedure [mysql.rds\$1innodb\$1buffer\$1pool\$1load\$1abort](mysql-stored-proc-warming.md#mysql_rds_innodb_buffer_pool_load_abort). ## Modifiche per un linguaggio inclusivo in RDS per MySQL 8.4 In RDS per MySQL 8.4 sono state apportate modifiche dalla versione Community di MySQL 8.4 relative alle parole chiave e agli schemi di sistema per un linguaggio inclusivo. Ad esempio, il comando `SHOW REPLICA STATUS` sostituisce `SHOW SLAVE STATUS`. **Topics** + [ ### Modifiche dei nomi dei parametri di configurazione ](#mysql-8-4-inclusive-language-changes-params) + [ ### Modifiche dei nomi delle stored procedure ](#mysql-8-4-inclusive-language-changes-sp) ### Modifiche dei nomi dei parametri di configurazione I seguenti parametri di configurazione hanno nuovi nomi in RDS per MySQL 8.4. Per compatibilità, è possibile controllare i nomi dei parametri nel client `mysql` utilizzando entrambi i nomi. È possibile utilizzare i nuovi nomi solo quando si modificano i valori in un gruppo di parametri di MySQL 8.4 personalizzato. Per ulteriori informazioni, consulta [Gruppi di parametri predefiniti e personalizzati](parameter-groups-overview.md#parameter-groups-overview.custom). | Nome da rimuovere | Nome nuovo o preferito | | --- | --- | | `init_slave` | `init_replica` | | `log_slave_updates` | `log_replica_updates` | | `log_slow_slave_statements` | `log_slow_replica_statements` | | `rpl_stop_slave_timeout` | `rpl_stop_replica_timeout` | | `skip_slave_start` | `skip_replica_start` | | `slave_checkpoint_group` | `replica_checkpoint_group` | | `slave_checkpoint_period` | `replica_checkpoint_period` | | `slave_compressed_protocol` | `replica_compressed_protocol` | | `slave_exec_mode` | `replica_exec_mode` | | `slave_load_tmpdir` | `replica_load_tmpdir` | | `slave_max_allowed_packet` | `replica_max_allowed_packet` | | `slave_net_timeout` | `replica_net_timeout` | | `slave_parallel_type` | `replica_parallel_type` | | `slave_parallel_workers` | `replica_parallel_workers` | | `slave_pending_jobs_size_max` | `replica_pending_jobs_size_max` | | `slave_preserve_commit_order` | `replica_preserve_commit_order` | | `slave_skip_errors` | `replica_skip_errors` | | `slave_sql_verify_checksum` | `replica_sql_verify_checksum` | | `slave_transaction_retries` | `replica_transaction_retries` | | `slave_type_conversions` | `replica_type_conversions` | | `sql_slave_skip_counter` | `sql_replica_skip_counter` | **Nota** Il parametro `replica_allow_batching` non è disponibile perché Amazon RDS non supporta i cluster NDB. ### Modifiche dei nomi delle stored procedure Le stored procedure seguenti hanno nuovi nomi in RDS per MySQL 8.4. Per compatibilità, è possibile utilizzare entrambi i nomi nella versione iniziale di RDS per MySQL 8.4. I nomi delle procedure precedenti devono essere rimossi in una versione futura. Per ulteriori informazioni, consulta [Configurazione, avvio e arresto della replica dei log binari (binlog)](mysql-stored-proc-replicating.md). | Nome da rimuovere | Nome nuovo o preferito | | --- | --- | | `mysql.rds_next_master_log` | `mysql.rds_next_source_log ` | | `mysql.rds_reset_external_master` | `mysql.rds_reset_external_source` | | `mysql.rds_set_external_master` | `mysql.rds_set_external_source` | | `mysql.rds_set_external_master_with_auto_position` | `mysql.rds_set_external_source_with_auto_position` | | `mysql.rds_set_external_master_with_delay` | `mysql.rds_set_external_source_with_delay` | | `mysql.rds_set_master_auto_position` | `mysql.rds_set_source_auto_position` | ## Caratteristiche di MySQL non supportate da Amazon RDS Al momento, Amazon RDS non supporta le caratteristiche seguenti di MySQL: + Plug-in di autenticazione + Registrazione degli errori nel log di sistema + Crittografia di spazi tabelle InnoDB + Cluster NDB + Plug-in per la complessità della password + Variabili di sistema persistenti + Plugin di riscrittura Rewriter Query + Replica semisincrona, ad eccezione dei cluster di database Multi-AZ + Spazio di tabella trasportabile + Plug-in IDE Per offrire un'esperienza di servizio gestito, Amazon RDS non fornisce accesso shell alle istanze database. Limita anche l'accesso ad alcune procedure di sistema e tabelle che richiedono privilegi avanzati. Amazon RDS supporta l'accesso ai database in un'istanza database con qualsiasi applicazione client SQL standard. Amazon RDS non consente l'accesso host diretto a un'istanza database tramite Telnet, Secure Shell (SSH) o Windows Remote Desktop Connection. Quando si crea un’istanza database, viene assegnato il ruolo *db\$1owner* per tutti i database dell’istanza e si dispone di tutte le autorizzazioni a livello di database, ad eccezione di quelle utilizzate per i backup. Amazon RDS gestisce i backup per tuo conto. # Versioni di MySQL in Amazon RDS Per MySQL, i numeri di versione sono organizzati come versione X.Y.Z. Nella terminologia di Amazon RDS; X.Y indica la versione principale e Z è il numero di versione secondaria. Per le implementazioni di Amazon RDS, una modifica di versione è considerata principale se cambia il numero di versione principale—ad esempio nel caso di un passaggio dalla versione 5.7 alla 8.0. Una modifica di versione è considerata secondaria se cambia solo il numero di versione secondaria, ad esempio nel caso di un passaggio dalla versione 8.0.32 alla 8.0.34. **Topics** + [ ## Versioni secondarie di MySQL supportate in Amazon RDS ](#MySQL.Concepts.VersionMgmt.Supported) + [ ## Versioni principali di MySQL supportate in Amazon RDS ](#MySQL.Concepts.VersionMgmt.ReleaseCalendar) + [ ## Versioni del supporto esteso per Amazon RDS di RDS per MySQL ](#mysql-extended-support-releases) + [ ## Utilizzo dell’ambiente di anteprima del database ](#mysql-working-with-the-database-preview-environment) + [ ## MySQL versione 9.5 nell'ambiente Database Preview ](#mysql-preview-environment-version-9-5) + [ ## MySQL versione 9.4 nell'ambiente Database Preview ](#mysql-preview-environment-version-9-4) + [ ## MySQL versione 9.3 nell’ambiente di anteprima del database ](#mysql-preview-environment-version-9-3) + [ ## Versioni obsolete per Amazon RDS for MySQL ](#MySQL.Concepts.DeprecatedVersions) ## Versioni secondarie di MySQL supportate in Amazon RDS Attualmente Amazon RDS supporta le versioni secondarie di MySQL seguenti. **Nota** Il supporto esteso per Amazon RDS non è disponibile per le versioni secondarie. Nella tabella seguente sono indicate le versioni secondarie di MySQL 8.4 supportate attualmente da Amazon RDS. | Versione del motore MySQL | Data di rilascio nella community | Data di rilascio per RDS | Data di fine del supporto standard RDS | | --- | --- | --- | --- | | 8,48 | 20 gennaio 2026 | 3 febbraio 2026 | 3 febbraio 2027 | | 8.4.7 | 21 ottobre 2025 | 13 novembre 2025 | 30 novembre 2026 | | 8.4.6 | 22 luglio 2025 | 1 agosto 2025 | 30 settembre 2026 | | 8.4.5 | 15 aprile 2025 | 29 aprile 2025 | 30 settembre 2026 | | 8.4.4 | 21 gennaio 2025 | 19 febbraio 2025 | 31 maggio 2026 | | 8.4.3 | 15 ottobre 2024 | 21 novembre 2024 | 31 maggio 2026 | Nella tabella seguente sono indicate le versioni secondarie di MySQL 8.0 supportate attualmente da Amazon RDS. **Nota** Le versioni secondarie possono raggiungere la fine del supporto standard prima di quelle principali. Ad esempio, la versione secondaria 8.0.28 ha raggiunto la data di fine del supporto standard il 28 marzo 2024, mentre la versione principale 8.0 raggiunge tale data il 31 luglio 2026. RDS supporterà versioni secondarie 8.0.\$1 aggiuntive che la Community MySQL rilascerà nell’intervallo tra queste date. Si consiglia di aggiornare il più spesso possibile tutte le versioni principali all’ultima versione secondaria disponibile. | Versione del motore MySQL | Data di rilascio nella community | Data di rilascio per RDS | Data di fine del supporto standard RDS | | --- | --- | --- | --- | | 8,0,45 | 20 gennaio 2026 | 3 febbraio 2026 | 31 luglio 2026 | | 8.0.44 | 21 ottobre 2025 | 13 novembre 2025 | 31 luglio 2026 | | 8.0.43 | 22 luglio 2025 | 1 agosto 2025 | 31 luglio 2026 | | 8,0,42 | 15 aprile 2025 | 29 aprile 2025 | 31 luglio 2026 | | 8,0,41 | 21 gennaio 2025 | 19 febbraio 2025 | 31 maggio 2026 | | 8,0,40 | 15 ottobre 2024 | 13 novembre 2024 | 31 maggio 2026 | Nella tabella seguente sono indicate le versioni secondarie di MySQL 5.7 disponibili nell’ambito del supporto esteso per Amazon RDS. **Nota** Le versioni secondarie possono raggiungere la fine del supporto esteso prima di quelle principali. Ad esempio, la versione secondaria 5.7.44-RDS.20240529 raggiunge la data di fine del supporto esteso a settembre 2025, mentre la versione principale 5.7 raggiunge tale data il 28 febbraio 2027. RDS genererà e rilascerà versioni secondarie 5.7.44-RDS.xxyyzz aggiuntive nell’intervallo tra queste date. Si consiglia di aggiornare il più spesso possibile tutte le versioni principali all’ultima versione secondaria disponibile. | Versione del motore MySQL | Data di rilascio nella community | Data di rilascio per RDS | Data di fine dell'estensione del supporto RDS | | --- | --- | --- | --- | | 5.7.44-RDS.20260212\$1 | Non applicabile | 26 febbraio 2026 | 28 febbraio 2027 | | 5.7.44-RDS.20251212\$1 | Non applicabile | 12 dicembre 2025 | 30 dicembre 2026 | | 5.7.44-RDS.20250818\$1 | Non applicabile | 15 settembre 2025 | 30 settembre 2026 | | 5.7.44-RDS.20250508\$1 | Non applicabile | 20 maggio 2025 | 30 settembre 2026 | | 5.7.44-RDS.20250213\$1 | Non applicabile | 12 marzo 2025 | 30 settembre 2026 | | 5.7.44-RDS.20250103\$1 | Non applicabile | 13 febbraio 2025 | 31 maggio 2026 | \$1 La Community MySQL ha ritirato la versione principale 5.7 e non rilascerà nuove versioni secondarie. Questa è una versione secondaria rilasciata da Amazon RDS con patch di sicurezza critiche e correzioni di bug per i database MySQL 5.7 coperti dal supporto esteso per RDS. Per ulteriori informazioni su queste versioni secondarie, consulta [Versioni del supporto esteso per Amazon RDS di RDS per MySQL](#mysql-extended-support-releases). Per ulteriori informazioni sul supporto esteso per RDS, consulta [Supporto esteso per Amazon RDS con Amazon RDS](extended-support.md). Quando crei una nuova istanza database, puoi specificare qualsiasi versione di MySQL attualmente supportata. Puoi specificare la versione principale MySQL 5.7 e qualsiasi versione secondaria supportata per la versione principale specificata. Se non viene specificata alcuna versione, Amazon RDS utilizza per impostazione predefinita una versione supportata, in genere la più recente. Se viene specificata una versione principale ma non una secondaria, per impostazione predefinita Amazon RDS utilizza una release recente della versione principale specificata. Per visualizzare un elenco delle versioni supportate, nonché le impostazioni predefinite per le istanze DB appena create, esegui il comando. [https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html) AWS CLI Ad esempio, per visualizzare l'elenco delle versioni di motori supportate per RDS per MySQL. esegui il comando CLI seguente: ``` aws rds describe-db-engine-versions --engine mysql --query "*[].{Engine:Engine,EngineVersion:EngineVersion}" --output text ``` La versione predefinita di MySQL potrebbe variare in base alla Regione AWS. Per creare un'istanza DB con una versione secondaria specifica, specifica la versione secondaria durante la creazione dell'istanza DB. È possibile determinare la versione secondaria predefinita per an Regione AWS eseguendo il comando seguente: AWS CLI ``` aws rds describe-db-engine-versions --default-only --engine mysql --engine-version major_engine_version --region region --query "*[].{Engine:Engine,EngineVersion:EngineVersion}" --output text ``` Sostituire *major\$1engine\$1version* con la versione principale del motore e sostituire *region* con Regione AWS. Ad esempio, il AWS CLI comando seguente restituisce la versione del motore secondario MySQL predefinita per la versione principale 5.7 e gli Stati Uniti occidentali (Oregon) (us-west-2): Regione AWS ``` aws rds describe-db-engine-versions --default-only --engine mysql --engine-version 5.7 --region us-west-2 --query "*[].{Engine:Engine,EngineVersion:EngineVersion}" --output text ``` Con Amazon RDS, puoi controllare quando eseguire l'aggiornamento dell'istanza MySQL a una nuova versione supportata da Amazon RDS. Puoi mantenere la compatibilità con versioni specifiche di MySQL, testare le nuove versioni con l'applicazione prima di distribuirle in produzione e aggiornare le versioni quando è più appropriato in base alla tua pianificazione. Quando l'aggiornamento automatico della versione secondaria è abilitato, l'istanza DB verrà aggiornata automaticamente alle nuove versioni secondarie di MySQL in quanto sono supportate da Amazon RDS. L'applicazione di patch avviene durante la finestra di manutenzione pianificata. È possibile modificare un'istanza DB per abilitare o disabilitare gli aggiornamenti automatici delle versioni secondarie. Se annulli gli aggiornamenti automatici pianificati, puoi eseguire manualmente l'aggiornamento a una versione secondaria supportata seguendo la stessa procedura utilizzata per l'aggiornamento di una versione principale. Per informazioni, consulta [Aggiornamento della versione del motore di di un'istanza database](USER_UpgradeDBInstance.Upgrading.md). Amazon RDS supporta i seguenti aggiornamenti per le versioni principali del motore di database MySQL: + Da MySQL 5.7 a MySQL 8.0 + Da MySQL 8.0 a MySQL 8.4 Poiché gli aggiornamenti della versione principale prevedono alcuni rischi di compatibilità, non vengono eseguiti automaticamente, ma devi inviare una richiesta di modifica dell'istanza database. Testa in modo approfondito qualsiasi aggiornamento prima di applicarlo alle istanze di produzione. Per informazioni sull'aggiornamento di un'istanza database MySQL, consulta [Aggiornamenti del motore di database RDS per MySQL](USER_UpgradeDBInstance.MySQL.md). Puoi testare una nuova versione per un'istanza database prima di eseguire l'aggiornamento creando uno snapshot DB dell'istanza database esistente, eseguendo il ripristino dallo snapshot DB per creare una nuova istanza database e quindi avviando un aggiornamento della versione per la nuova istanza database. Potrai quindi effettuare le prove che desideri sul clone aggiornato dell'istanza database prima di decidere se aggiornare o meno l'istanza database originale. ### Versioni secondarie di MySQL in Amazon RDS Per le modifiche apportate dalla Community MySQL alle versioni secondarie, consulta [Critical Patch Updates, Security Alerts and Bulletins](https://www.oracle.com/security-alerts/) sul sito web di Oracle. In **Critical Patch Update**, scegli il mese in cui Oracle ha rilasciato la versione secondaria, quindi scegli la versione secondaria di MySQL in **Affected Products and Versions**. **Topics** + [ #### MySQL versione 8.4.8 ](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.4.8) + [ #### MySQL versione 8.4.7 ](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.4.7) + [ #### MySQL versione 8.4.6 ](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.4.6) + [ #### MySQL versione 8.4.5 ](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.4.5) + [ #### MySQL versione 8.4.4 ](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.4.4) + [ #### MySQL versione 8.0.45 ](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.0.45) + [ #### MySQL versione 8.0.44 ](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.0.44) + [ #### MySQL versione 8.0.43 ](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.0.43) + [ #### MySQL versione 8.0.42 ](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.0.42) + [ #### MySQL versione 8.0.41 ](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.0.41) + [ #### MySQL versione 8.0.40 ](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.0.40) + [ #### MySQL versione 8.0.39 ](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.0.39) + [ #### MySQL versione 8.0.37 ](#MySQL.Concepts.VersionMgmt.Supported.Minor.8.0.37) #### MySQL versione 8.4.8 La versione 8.4.8 di MySQL è ora disponibile su Amazon RDS. Tale versione contiene correzioni e miglioramenti aggiunti dalla Community MySQL e da Amazon RDS. **Nuove funzionalità e miglioramenti** + Sono state aggiornate le informazioni sul fuso orario per basarle su `tzdata2025c`. + È stato risolto un problema che poteva impedire la registrazione di alcune istruzioni SQL nel registro di controllo. #### MySQL versione 8.4.7 La versione 8.4.7 di MySQL è ora disponibile su Amazon RDS. Tale versione contiene correzioni e miglioramenti aggiunti dalla Community MySQL e da Amazon RDS. #### MySQL versione 8.4.6 MySQL versione 8.4.6 è ora disponibile in Amazon RDS. Tale versione contiene correzioni e miglioramenti aggiunti dalla Community MySQL e da Amazon RDS. #### MySQL versione 8.4.5 MySQL versione 8.4.5 è ora disponibile in Amazon RDS. Tale versione contiene correzioni e miglioramenti aggiunti dalla Community MySQL e da Amazon RDS. **Nuove funzionalità e miglioramenti** + Sono state aggiornate le informazioni sul fuso orario per basarle su `tzdata2025b`. #### MySQL versione 8.4.4 MySQL versione 8.4.4 è ora disponibile in Amazon RDS. Tale versione contiene correzioni e miglioramenti aggiunti dalla Community MySQL e da Amazon RDS. **Nuove funzionalità e miglioramenti** + Sono state aggiornate le informazioni sul fuso orario per basarle su `tzdata2025a`. + È stato corretto un bug che causava un errore nelle regole di confronto durante l’esecuzione delle stored procedure `mysql.rds_set_configuration` e `mysql.rds_kill` di Amazon RDS. #### MySQL versione 8.0.45 La versione 8.0.45 di MySQL è ora disponibile su Amazon RDS. Tale versione contiene correzioni e miglioramenti aggiunti dalla Community MySQL e da Amazon RDS. **Nuove funzionalità e miglioramenti** + Sono state aggiornate le informazioni sul fuso orario per basarle su `tzdata2025c`. + È stato risolto un problema che poteva impedire la registrazione di alcune istruzioni SQL nel registro di controllo. #### MySQL versione 8.0.44 La versione 8.0.44 di MySQL è ora disponibile su Amazon RDS. Tale versione contiene correzioni e miglioramenti aggiunti dalla Community MySQL e da Amazon RDS. #### MySQL versione 8.0.43 MySQL versione 8.0.43 è ora disponibile in Amazon RDS. Tale versione contiene correzioni e miglioramenti aggiunti dalla Community MySQL e da Amazon RDS. #### MySQL versione 8.0.42 MySQL versione 8.0.42 è ora disponibile in Amazon RDS. Tale versione contiene correzioni e miglioramenti aggiunti dalla Community MySQL e da Amazon RDS. **Nuove funzionalità e miglioramenti** + Sono state aggiornate le informazioni sul fuso orario per basarle su `tzdata2025b`. #### MySQL versione 8.0.41 MySQL versione 8.0.41 è ora disponibile in Amazon RDS. Tale versione contiene correzioni e miglioramenti aggiunti dalla Community MySQL e da Amazon RDS. **Nuove funzionalità e miglioramenti** + Sono state aggiornate le informazioni sul fuso orario per basarle su `tzdata2025a`. + È stato corretto un bug che causava un errore nelle regole di confronto durante l’esecuzione delle stored procedure `mysql.rds_set_configuration` e `mysql.rds_kill` di Amazon RDS. #### MySQL versione 8.0.40 MySQL versione 8.0.40 è ora disponibile in Amazon RDS. Tale versione contiene correzioni e miglioramenti aggiunti dalla Community MySQL e da Amazon RDS. **Nuove funzionalità e miglioramenti** + È stato corretto un bug che causava errori di mancata corrispondenza dei set di caratteri durante gli aggiornamenti del database. #### MySQL versione 8.0.39 MySQL versione 8.0.39 è ora disponibile in Amazon RDS. Tale versione contiene correzioni e miglioramenti aggiunti dalla Community MySQL e da Amazon RDS. **Nuove funzionalità e miglioramenti** + È stato corretto un bug che impediva il corretto funzionamento di `sql_log_off` con il privilegio `SESSION_VARIABLES_ADMIN`. + È stato corretto un bug che impediva all’utente master di concedere il privilegio `SESSION_VARIABLE_ADMIN` ad altri utenti del database. + È stato corretto un bug che causava una combinazione illegale di regole di confronto durante l’esecuzione delle stored procedure fornite da RDS. #### MySQL versione 8.0.37 MySQL versione 8.0.37 è ora disponibile in Amazon RDS. Tale versione contiene correzioni e miglioramenti aggiunti dalla Community MySQL e da Amazon RDS. **Nuove funzionalità e miglioramenti** + È stato corretto un bug relativo all’esecuzione di un’istruzione DDL istantanea seguita da un’istruzione UPDATE che causava un errore di asserzione. ## Versioni principali di MySQL supportate in Amazon RDS Il supporto standard delle versioni principali di RDS per MySQL resta disponibile almeno fino alla fine del ciclo di vita della community per la versione della community corrispondente. Puoi continuare a utilizzare una versione principale dopo la data di fine del supporto RDS standard a pagamento. Per ulteriori informazioni, consulta [Supporto esteso per Amazon RDS con Amazon RDS](extended-support.md) e [Prezzi di Amazon RDS per MySQL](https://aws.amazon.com/rds/mysql/pricing/). È possibile utilizzare le date seguenti per pianificare i cicli di test e aggiornamento. **Nota** È inoltre possibile visualizzare le informazioni sulle date di supporto per le principali versioni del motore utilizzando AWS CLI o l'API RDS. Per ulteriori informazioni, consulta [Visualizzazione delle date di supporto per le versioni del motore con supporto esteso per Amazon RDS](extended-support-viewing-support-dates.md). | Versione principale di MySQL | Data di rilascio nella community | Data di rilascio per RDS | Data di fine vita nella community | Data di fine del supporto standard RDS | Data di inizio validità dei prezzi per l'estensione del supporto RDS (1 anno) | Data di inizio validità dei prezzi per l'estensione del supporto RDS (3 anni) | Data di fine dell'estensione del supporto RDS | | --- | --- | --- | --- | --- | --- | --- | --- | | MySQL 8.4 | 30 aprile 2024 | 21 novembre 2024 | 30 aprile 2029 | 31 luglio 2029 | 1 agosto 2029 | 1 agosto 2031 | 31 luglio 2032 | | MySQL 8.0 | 19 aprile 2018 | 23 ottobre 2018 | 30 aprile 2026 | 31 luglio 2026 | 1 agosto 2026 | 1 agosto 2028 | 31 luglio 2029 | | MySQL 5.7\$1 | 21 ottobre 2015 | 22 febbraio 2016 | 31 ottobre 2023 | 29 febbraio 2024 | 1 marzo 2024 | 1 marzo 2026 | 28 febbraio 2027 | \$1 MySQL 5.7 è ora disponibile solo con il supporto esteso per RDS. Per ulteriori informazioni, consulta [Supporto esteso per Amazon RDS con Amazon RDS](extended-support.md). ## Versioni del supporto esteso per Amazon RDS di RDS per MySQL Di seguito sono elencati tutti i rilasci delle versioni del supporto esteso per RDS di RDS per MySQL. **Topics** + [ ### RDS Extended Support per RDS per MySQL versione 5.7.44-RDS.20260212 ](#mysql-extended-support-releases-version-5.7.44-RDS.20260212) + [ ### RDS Extended Support per RDS per MySQL versione 5.7.44-RDS.20251212 ](#mysql-extended-support-releases-version-5.7.44-RDS.20251212) + [ ### RDS Extended Support per RDS per MySQL versione 5.7.44-RDS.20250818 ](#mysql-extended-support-releases-version-5.7.44-RDS.20250818) + [ ### Supporto esteso per RDS di RDS per MySQL versione 5.7.44-RDS.20250508 ](#mysql-extended-support-releases-version-5.7.44-20250508) + [ ### Supporto esteso per RDS di RDS per MySQL versione 5.7.44-RDS.20250213 ](#mysql-extended-support-releases-version-5.7.44-20250213) + [ ### Supporto esteso per RDS di RDS per MySQL versione 5.7.44-RDS.20250103 ](#mysql-extended-support-releases-version-5.7.44-20250103) + [ ### Supporto esteso per RDS di RDS per MySQL versione 5.7.44-RDS.20240808 ](#mysql-extended-support-releases-version-5.7.44-20240808) + [ ### Supporto esteso per RDS di RDS per MySQL versione 5.7.44-RDS.20240529 ](#mysql-extended-support-releases-version-5.7.44-20240529) + [ ### Supporto esteso per RDS di RDS per MySQL versione 5.7.44-RDS.20240408 ](#mysql-extended-support-releases-version-5.7.44-20240408) ### RDS Extended Support per RDS per MySQL versione 5.7.44-RDS.20260212 È disponibile RDS Extended Support for RDS for MySQL versione 5.7.44-RDS.20260212. **Bug corretti:** + Aggiorna il certificato di prova utilizzato per testare la correzione del bug 22295186. + Risolve una perdita di memoria con l'indice del prefisso sulle colonne blob. **CVEs risolto:** + [CVE-2026-21936](https://nvd.nist.gov/vuln/detail/CVE-2026-21936) + [CVE-2026-21968](https://nvd.nist.gov/vuln/detail/CVE-2026-21968) + [CVE-2026-21941](https://nvd.nist.gov/vuln/detail/CVE-2026-21941) + [CVE-2026-21948](https://nvd.nist.gov/vuln/detail/CVE-2026-21948) ### RDS Extended Support per RDS per MySQL versione 5.7.44-RDS.20251212 È disponibile RDS Extended Support for RDS for MySQL versione 5.7.44-RDS.20251212. **Bug corretti:** + È stato risolto un problema con l'avvio del server quando la dimensione del pool di buffer superava il limite superiore. + Risolto il problema `INFORMATION_SCHEMA.INNODB_LOCKS` che causava la chiusura anomala del server in caso di lettura. + È stato risolto un problema con il supporto per la JUnit segnalazione in MySQL Test Run (MTR). + Risolti i problemi di compilazione durante la creazione con l'opzione. `-DWITH_INNODB_MEMCACHED=ON` + Risolto un problema con l'esecuzione di MySQL Test Run (MTR) per il bug 25182306. **CVEs risolto:** + [CVE-2025-53054](https://nvd.nist.gov/vuln/detail/CVE-2025-53054) + [CVE-2025-53044](https://nvd.nist.gov/vuln/detail/CVE-2025-53044) + [CVE-2025-53045](https://nvd.nist.gov/vuln/detail/CVE-2025-53045) + [CVE-2025-53062](https://nvd.nist.gov/vuln/detail/CVE-2025-53062) + [CVE-2025-53040](https://nvd.nist.gov/vuln/detail/CVE-2025-53040) + [CVE-2025-53042](https://nvd.nist.gov/vuln/detail/CVE-2025-53042) + [CVE-2025-53067](https://nvd.nist.gov/vuln/detail/CVE-2025-53067) ### RDS Extended Support per RDS per MySQL versione 5.7.44-RDS.20250818 È disponibile RDS Extended Support for RDS for MySQL versione 5.7.44-RDS.20250818. **Bug corretti:** + È stato risolto un problema a causa del quale il plug-in di riscrittura delle query non funzionava quando il server funzionava con. `autocommit=OFF` + È stato risolto un problema di autorizzazione che impediva l'esecuzione delle build di Debian e Ubuntu in modalità rootless. + Risolto l'aggiornamento mancante per il bug 30875669. **CVEs risolto:** + [CVE-2025-50082](https://nvd.nist.gov/vuln/detail/CVE-2025-50082) + [CVE-2025-50083](https://nvd.nist.gov/vuln/detail/CVE-2025-50083) + [CVE-2025-50079](https://nvd.nist.gov/vuln/detail/CVE-2025-50079) + [CVE-2025-50084](https://nvd.nist.gov/vuln/detail/CVE-2025-50084) + [CVE-2025-50087](https://nvd.nist.gov/vuln/detail/CVE-2025-50087) + [CVE-2025-50091](https://nvd.nist.gov/vuln/detail/CVE-2025-50091) + [CVE-2025-50101](https://nvd.nist.gov/vuln/detail/CVE-2025-50101) + [CVE-2025-50102](https://nvd.nist.gov/vuln/detail/CVE-2025-50102) + [CVE-2025-50098](https://nvd.nist.gov/vuln/detail/CVE-2025-50098) + [CVE-2025-53023](hhttps://nvd.nist.gov/vuln/detail/CVE-2025-53023) + [CVE-2025-50081](https://nvd.nist.gov/vuln/detail/CVE-2025-50081) + [CVE-2025-50085](https://nvd.nist.gov/vuln/detail/CVE-2025-50085) + [CVE-2025-50077](https://nvd.nist.gov/vuln/detail/CVE-2025-50077) + [CVE-2025-50088](https://nvd.nist.gov/vuln/detail/CVE-2025-50088) + [CVE-2025-50092](https://nvd.nist.gov/vuln/detail/CVE-2025-50092) + [CVE-2025-50099](https://nvd.nist.gov/vuln/detail/CVE-2025-50099) + [CVE-2025-50096](https://nvd.nist.gov/vuln/detail/CVE-2025-50096) ### Supporto esteso per RDS di RDS per MySQL versione 5.7.44-RDS.20250508 Il supporto esteso per RDS di RDS per MySQL versione 5.7.44-RDS.20250508 è disponibile. **Bug corretti:** + È stato corretto lo stato instabile degli indici virtuali dopo il rollback quando `index_id` è maggiore del valore massimo `uint32`. + È stata corretta la mancata riuscita dei test a causa di un problema di memoria. + È stato risolto il problema di `` vuoto per `Execute`. + È stato risolto il problema di compilazione di MySQL con GCC 14 [noclose 5.7]. **CVEs risolto:** + [CVE-2025-30682](https://nvd.nist.gov/vuln/detail/CVE-2025-30682) + [CVE-2025-30687](https://nvd.nist.gov/vuln/detail/CVE-2025-30687) + [CVE-2025-30688](https://nvd.nist.gov/vuln/detail/CVE-2025-30688) + [CVE-2025-21581](https://nvd.nist.gov/vuln/detail/CVE-2025-21581) + [CVE-2025-21585](https://nvd.nist.gov/vuln/detail/CVE-2025-21585) + [CVE-2025-30689](https://nvd.nist.gov/vuln/detail/CVE-2025-30689) + [CVE-2025-30722](https://nvd.nist.gov/vuln/detail/CVE-2025-30722) + [CVE-2025-21577](https://nvd.nist.gov/vuln/detail/CVE-2025-21577) + [CVE-2025-30693](https://nvd.nist.gov/vuln/detail/CVE-2025-30693) + [CVE-2025-30695](https://nvd.nist.gov/vuln/detail/CVE-2025-30695) + [CVE-2025-30703](https://nvd.nist.gov/vuln/detail/CVE-2025-30703) ### Supporto esteso per RDS di RDS per MySQL versione 5.7.44-RDS.20250213 Il supporto esteso per RDS di RDS per MySQL versione 5.7.44-RDS.20250213 è disponibile. **Bug corretti:** + È stato risolto l’errore di asserzione `result != FTS_INVALID` in InnoDB. + È stato risolto il problema di arresto anomalo e di danneggiamento diffuso degli indici spaziali dopo che l’operazione `ALTER TABLE` ricostruisce la tabella InnoDB con l’algoritmo `INPLACE`. + È stato risolto il problema relativo all’arresto anomalo di `ON DELETE CASCADE` con colonne generate in `innobase_get_computed_value`. + È stato risolto l’errore di asserzione in `row_MySQL_pad_col`. + È stato risolto un problema per cui la DDL online causava il seguente errore: `ERROR 1712 (HY000): Index PRIMARY is corrupted`. + È stato risolto il problema degli arresti anomali in `Item_rollup_sum_switcher::current_arg`. + È stato risolto un problema di mancato svuotamento della cache del database per `DROP USER`. + È stato risolto il problema del sovraccarico del buffer in `my_print_help`. + È stato risolto un problema di InnoDB per cui l’indice `FULLTEXT` limita `FTS_DOC_ID` al valore massimo a 32 bit unsigned. **CVEs risolto:** + [CVE-2025-21497](https://nvd.nist.gov/vuln/detail/CVE-2025-21497) + [CVE-2025-21555](https://nvd.nist.gov/vuln/detail/CVE-2025-21555) + [CVE-2025-21559](https://nvd.nist.gov/vuln/detail/CVE-2025-21559) + [CVE-2025-21490](https://nvd.nist.gov/vuln/detail/CVE-2025-21490) + [CVE-2025-21491](https://nvd.nist.gov/vuln/detail/CVE-2025-21491) + [CVE-2025-21500](https://nvd.nist.gov/vuln/detail/CVE-2025-21500) + [CVE-2025-21501](https://nvd.nist.gov/vuln/detail/CVE-2025-21501) + [CVE-2025-21540](https://nvd.nist.gov/vuln/detail/CVE-2025-21540) + [CVE-2025-21543](https://nvd.nist.gov/vuln/detail/CVE-2025-21543) + [CVE-2025-21520](https://nvd.nist.gov/vuln/detail/CVE-2025-21520) ### Supporto esteso per RDS di RDS per MySQL versione 5.7.44-RDS.20250103 Il supporto esteso per RDS di RDS per MySQL versione 5.7.44-RDS.20250103 è disponibile. **Bug corretti:** + È stato risolto il problema di pulizia FTS che si verificava quando si eliminava e si aggiungeva un indice `FULLTEXT` nella stessa transazione. + Abbiamo ottimizzato i tempi di allocazione della memoria nel client MySQL per prevenire potenziali perdite. + È stato corretto il troncamento dei risultati a 34 byte quando si utilizza l’operatore `UNION`. + Possibile out-of-bounds accesso fisso dovuto `ulong bitmask` al codice di autorizzazione. **CVEs risolto:** + [CVE-2024-21230](https://nvd.nist.gov/vuln/detail/CVE-2024-21230) + [CVE-2024-21201](https://nvd.nist.gov/vuln/detail/CVE-2024-21201) + [CVE-2024-21241](https://nvd.nist.gov/vuln/detail/CVE-2024-21241) + [CVE-2024-21203](https://nvd.nist.gov/vuln/detail/CVE-2024-21203) ### Supporto esteso per RDS di RDS per MySQL versione 5.7.44-RDS.20240808 Il supporto esteso per RDS di RDS per MySQL versione 5.7.44-RDS.20240808 è disponibile. **Bug corretti:** + È stato risolto l’errore di asserzione relativo all’indice delle colonne del dizionario. + È stato risolto il problema per la funzione `is_binlog_cache_empty()`. + Sono stati risolti gli errori `heap-use-after-free` nei file `sql/item.cc`. + Sono stati risolti diversi problemi relativi agli indici spaziali disabilitandoli per le letture `index-only`. + È stato risolto un problema di analisi per il plugin `LOCK_ORDER: CONNECTION_CONTROL`. + È stato risolto il problema dei thread che si bloccavano con il plugin `CONNECTION_CONTROL`. + È stato risolto il problema del mancato aggiornamento di `PSI_THREAD_INFO` per `PREPARED STATEMENTS`. + È stato risolto il problema della doppia elaborazione delle parole di indice FTS con `innodb_optimize_fulltext_only`. **CVEs risolto:** + [CVE-2024-21177](https://nvd.nist.gov/vuln/detail/CVE-2024-21177) ### Supporto esteso per RDS di RDS per MySQL versione 5.7.44-RDS.20240529 Il supporto esteso per RDS di RDS per MySQL versione 5.7.44-RDS.20240529 è disponibile. **Bug corretti:** + È stato risolto l’errore di asserzione `field.cc` implementando `fix_after_pullout`. + È stato risolto un errore del puntatore null durante la restituzione dei metadati al client per determinate query SQL che contenevano parametri dinamici e sottoquery nelle clausole `SELECT`. + Sono stati corretti i risultati errati nell’utilizzo di `GROUP BY` per scansioni deboli di indici o scansioni di intervalli non contigui di un indice. + È stato risolto il problema relativo alla perdita di informazioni GTID sull’arresto anomalo di MySQL durante la persistenza. + È stata risolta una race condition che poteva causare il blocco indefinito di una transazione InnoDB. + È stata risolta una race condition nella pulizia delle informazioni di certificazione della replica di gruppi. + È stato risolto il problema di scansione inversa dell’indice con operazioni simultanee sulle pagine. + È stato risolto un problema di stato di ricerca full-text incoerente in scenari simultanei. + È stato risolto un problema di asserzione con il buffer di modifica durante l’eliminazione delle tabelle. + È stato unificato il comportamento per la chiamata della funzione `deinit` su tutti i tipi di plugin. **CVEs risolto:** + [CVE-2024-20963](https://nvd.nist.gov/vuln/detail/CVE-2024-20963) + [CVE-2024-20993](https://nvd.nist.gov/vuln/detail/CVE-2024-20993) + [CVE-2024-20998](https://nvd.nist.gov/vuln/detail/CVE-2024-20998) + [CVE-2024-21009](https://nvd.nist.gov/vuln/detail/CVE-2024-21009) + [CVE-2024-21054](https://nvd.nist.gov/vuln/detail/CVE-2024-21054) + [CVE-2024-21055](https://nvd.nist.gov/vuln/detail/CVE-2024-21055) + [CVE-2024-21057](https://nvd.nist.gov/vuln/detail/CVE-2024-21057) + [CVE-2024-21062](https://nvd.nist.gov/vuln/detail/CVE-2024-21062) + [CVE-2024-21008](https://nvd.nist.gov/vuln/detail/CVE-2024-21008) + [CVE-2024-21013](https://nvd.nist.gov/vuln/detail/CVE-2024-21013) + [CVE-2024-21047](https://nvd.nist.gov/vuln/detail/CVE-2024-21047) + [CVE-2024-21087](https://nvd.nist.gov/vuln/detail/CVE-2024-21087) + [CVE-2024-21096](https://nvd.nist.gov/vuln/detail/CVE-2024-21096) ### Supporto esteso per RDS di RDS per MySQL versione 5.7.44-RDS.20240408 Il supporto esteso per RDS di RDS per MySQL versione 5.7.44-RDS.20240408 è disponibile. Questa versione contiene patch per quanto segue: CVEs + [CVE-2024-20963](https://nvd.nist.gov/vuln/detail/CVE-2024-20963) ## Utilizzo dell’ambiente di anteprima del database Nel luglio 2023, Oracle ha annunciato un nuovo modello di rilascio per MySQL. Questo modello include due tipi di rilasci: di innovazione e LTS. Amazon RDS rende disponibili i rilasci di innovazione MySQL nell'ambiente di anteprima RDS. Per ulteriori informazioni sui rilasci di innovazione MySQL, consulta [Introducing MySQL Innovation and Long-Term Support (LTS) versions](https://blogs.oracle.com/mysql/post/introducing-mysql-innovation-and-longterm-support-lts-versions). Le istanze database RDS per MySQL nell'ambiente di anteprima del database sono funzionalmente simili alle altre istanze database RDS per MySQL. Non è tuttavia possibile utilizzare l'ambiente di anteprima del database per carichi di lavoro di produzione. Gli ambienti di anteprima presentano le seguenti limitazioni: + Amazon RDS elimina tutte le istanze database 60 giorni dopo la creazione, insieme a eventuali backup e snapshot. + Puoi utilizzare solo lo storage General Purpose (SSD) e Provisioned IOPS (SSD). + Non puoi ricevere assistenza Supporto con le istanze DB. [Puoi invece pubblicare le tue domande nella community di domande e risposte AWS gestita, re:POST.AWS](https://repost.aws/tags/TAsibBK6ZeQYihN9as4S_psg/amazon-relational-database-service) + Non puoi copiare uno snapshot di un'istanza database in un ambiente di produzione. Le seguenti opzioni sono supportate dall'anteprima. + È possibile creare istanze database utilizzando le classi di istanza database db.m6i, db.m6g, db.m5, db.t3, db.r6g e db.r5. Per ulteriori informazioni sulle classi delle istanze RDS, consulta [Classi di istanze DB ](Concepts.DBInstanceClass.md). + È possibile utilizzare distribuzioni Single-AZ e Multi-AZ. + È possibile utilizzare le funzioni di dump e caricamento standard di MySQL per esportare database da o importare database nell'ambiente di anteprima database. ### Funzionalità non supportate nell'ambiente di anteprima del database Le seguenti funzionalità non sono disponibili nell'ambiente di anteprima del database: + Copia di snapshot tra regioni diverse + Repliche di lettura tra regioni diverse + Server proxy per RDS ### Creazione di una nuova istanza database nell'ambiente di anteprima del database È possibile creare un'istanza DB nell'ambiente Database Preview utilizzando Console di gestione AWS, AWS CLI o l'API RDS. #### Console **Per creare un'istanza database nell'ambiente di anteprima del database** 1. Accedi a Console di gestione AWS e apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Scegliere **Dashboard (Pannello di controllo)** nel pannello di navigazione. 1. Nella pagina **Pannello di controllo** individua la sezione **Ambiente di anteprima del database**, come mostrato nell'immagine seguente. ![\[Sezione Ambiente di anteprima del database con link nella console Amazon RDS.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/images/preview-environment-dashboard.png) L'[ambiente di anteprima del database](https://us-east-2.console.aws.amazon.com/rds-preview/home?region=us-east-2#) è accessibile direttamente. Prima di poter procedere, è necessario capire e accettare le limitazioni. ![\[Finestra di dialogo Contratto di servizio ambiente di anteprima del database per accettare le limitazioni.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/images/preview-environment-console.png) 1. Per creare l'istanza database RDS per MySQL, segui la stessa procedura utilizzata per creare qualsiasi istanza database Amazon RDS. Per ulteriori informazioni, consulta la procedura [Console](USER_CreateDBInstance.md#USER_CreateDBInstance.CON) in [Creazione di un'istanza database](USER_CreateDBInstance.md#USER_CreateDBInstance.Creating). #### AWS CLI Per creare un'istanza database nell'ambiente di anteprima del database utilizzando la AWS CLI, usa il seguente endpoint. ``` rds-preview.us-east-2.amazonaws.com ``` Per creare l'istanza database RDS per MySQL, segui la stessa procedura utilizzata per creare qualsiasi istanza database Amazon RDS. Per ulteriori informazioni, consulta la procedura [AWS CLI](USER_CreateDBInstance.md#USER_CreateDBInstance.CLI) in [Creazione di un'istanza database](USER_CreateDBInstance.md#USER_CreateDBInstance.Creating). #### API RDS Per creare un'istanza database nell'ambiente di anteprima del database utilizzando l'API RDS, usa il seguente endpoint. ``` rds-preview.us-east-2.amazonaws.com ``` Per creare l'istanza database RDS per MySQL, segui la stessa procedura utilizzata per creare qualsiasi istanza database Amazon RDS. Per ulteriori informazioni, consulta la procedura [API RDS](USER_CreateDBInstance.md#USER_CreateDBInstance.API) in [Creazione di un'istanza database](USER_CreateDBInstance.md#USER_CreateDBInstance.Creating). ## MySQL versione 9.5 nell'ambiente Database Preview La versione 9.5 di MySQL è ora disponibile nell'ambiente Amazon RDS Database Preview. La versione 9.5 di MySQL contiene diversi miglioramenti descritti in [Modifiche](https://dev.mysql.com/doc/relnotes/mysql/9.5/en/news-9-5-0.html) a MySQL 9.5.0. Per informazioni sull’ambiente di anteprima del database, consulta [Utilizzo dell’ambiente di anteprima del database](#mysql-working-with-the-database-preview-environment). Per accedere all'ambiente di anteprima dalla console, selezionare. [https://console.aws.amazon.com/rds-preview/](https://console.aws.amazon.com/rds-preview/) ## MySQL versione 9.4 nell'ambiente Database Preview La versione 9.4 di MySQL è ora disponibile nell'ambiente Amazon RDS Database Preview. La versione 9.4 di MySQL contiene diversi miglioramenti descritti in [Modifiche](https://dev.mysql.com/doc/relnotes/mysql/9.4/en/news-9-4-0.html) a MySQL 9.4.0. Per informazioni sull’ambiente di anteprima del database, consulta [Utilizzo dell’ambiente di anteprima del database](#mysql-working-with-the-database-preview-environment). Per accedere all'ambiente di anteprima dalla console, selezionare. [https://console.aws.amazon.com/rds-preview/](https://console.aws.amazon.com/rds-preview/) ## MySQL versione 9.3 nell’ambiente di anteprima del database MySQL versione 9.3 è ora disponibile nell’ambiente di anteprima del database Amazon RDS. MySQL versione 9.3 contiene diversi miglioramenti, descritti in [Changes in MySQL 9.3.0](https://dev.mysql.com/doc/relnotes/mysql/9.3/en/news-9-3-0.html). Per informazioni sull’ambiente di anteprima del database, consulta [Utilizzo dell’ambiente di anteprima del database](#mysql-working-with-the-database-preview-environment). Per accedere all'ambiente di anteprima dalla console, seleziona. [https://console.aws.amazon.com/rds-preview/](https://console.aws.amazon.com/rds-preview/) ## Versioni obsolete per Amazon RDS for MySQL Le versioni 5.1, 5.5 e 5.6 di Amazon RDS per MySQL sono obsolete. Le versioni 9.1 e 9.2 di Amazon RDS for MySQL sono obsolete nell'ambiente Database Preview. [Per informazioni sulla politica di deprecazione di Amazon RDS per MySQL, consulta Amazon RDS. FAQs](https://aws.amazon.com/rds/faqs/) # Connessione all’istanza database MySQL Prima di eseguire la connessione a un'istanza database che esegue il motore di database di MySQL, devi creare un'istanza database. Per informazioni, consulta [Creazione di un'istanza database Amazon RDS](USER_CreateDBInstance.md). Dopo che Amazon RDS ha fornito l'istanza database, puoi utilizzare una qualsiasi applicazione client o utilità MySQL standard per connetterti all'istanza. Nella stringa di connessione devi specificare l'indirizzo DNS dell'endpoint dell'istanza database come parametro host e specificare il numero di porta dell'endpoint dell'istanza database come parametro port. Per eseguire l'autenticazione all'istanza database RDS puoi utilizzare i metodi di autenticazione dei database MySQL e AWS Identity and Access Management (IAM). + Per istruzioni su come eseguire l'autenticazione a MySQL utilizzando uno dei metodi di autenticazione per MySQL, consulta [ Metodo di autenticazione](https://dev.mysql.com/doc/internals/en/authentication-method.html) nella documentazione di MySQL. + Per informazioni su come eseguire l'autenticazione a MySQL utilizzando l'autenticazione del database IAM, consulta [Autenticazione del database IAM per MariaDB, MySQL e PostgreSQL](UsingWithRDS.IAMDBAuth.md). Puoi eseguire la connessione a un'istanza database MySQL utilizzando strumenti come il cliente della riga di comando MySQL. Per ulteriori informazioni sull'utilizzo del client della riga di comando MySQL, vai alla sezione [mysql - Il client della riga di comando di MySQL](https://dev.mysql.com/doc/refman/8.0/en/mysql.html) nella documentazione di MySQL. Un'applicazione basata su GUI che puoi utilizzare per la connessione è MySQL Workbench. Per ulteriori informazioni, consulta la pagina [Download MySQL Workbench](http://dev.mysql.com/downloads/workbench/). Per informazioni sull'installazione di MySQL (compreso il client della riga di comando MySQL), consulta [Installazione e aggiornamento di MySQL](https://dev.mysql.com/doc/refman/8.0/en/installing.html). Per connettersi a un'istanza DB dall'esterno Amazon VPC, l'istanza DB deve essere accessibile pubblicamente, l'accesso deve essere concesso utilizzando le regole in ingresso del gruppo di sicurezza dell'istanza DB e devono essere soddisfatti altri requisiti. Per ulteriori informazioni, consulta [Impossibile connettersi all'istanza database di Amazon RDS](CHAP_Troubleshooting.md#CHAP_Troubleshooting.Connecting). Puoi utilizzare la crittografia Secure Sockets Layer (SSL) o Transport Layer Security (TLS) sulle connessioni a un'istanza database MySQL. Per informazioni, consultare [Supporto di SSL/TLS per le istanze database MySQL in Amazon RDS](MySQL.Concepts.SSLSupport.md). Se utilizzi l'autenticazione database (IAM) AWS Identity and Access Management, assicurati di utilizzare una connessione SSL/TLS. Per informazioni, consulta [Autenticazione del database IAM per MariaDB, MySQL e PostgreSQL](UsingWithRDS.IAMDBAuth.md). Puoi inoltre connetterti a un'istanza database da un server Web. Per ulteriori informazioni, consulta [Tutorial: creazione di un server Web e un’istanza database Amazon RDS](TUT_WebAppWithRDS.md). **Nota** Per informazioni sulla connessione a un'istanza database MariaDB, consulta [Connessione all’istanza database MariaDB](USER_ConnectToMariaDBInstance.md). Per trovare e connettersi a un’istanza database RDS per MySQL, consulta i seguenti argomenti. **Topics** + [ # Ricerca delle informazioni di connessione per un’istanza database RDS per MySQL ](USER_ConnectToInstance.EndpointAndPort.md) + [ # Installazione del client a riga di comando MySQL ](mysql-install-cli.md) + [ # Connessione dal client a riga di comando MySQL (non crittografato) ](USER_ConnectToInstance.CLI.md) + [ # Connessione da MySQL Workbench ](USER_ConnectToInstance.MySQLWorkbench.md) + [ # Connessione a RDS per MySQL con il driver AWS JDBC, il driver AWS Python e il driver ODBC per MySQL AWS ](MySQL.Connecting.Drivers.md) + [ # Risoluzione dei problemi relativi alle connessioni all'istanza database MySQL ](USER_ConnectToInstance.Troubleshooting.md) # Ricerca delle informazioni di connessione per un’istanza database RDS per MySQL Le informazioni di connessione per un'istanza database includono l'endpoint, la porta e un utente di database valido, ad esempio l'utente master. Si supponga, ad esempio, che un valore endpoint sia `mydb.123456789012.us-east-1.rds.amazonaws.com`. In questo caso, il valore della porta è `3306` e l'utente del database è `admin`. Date queste informazioni, è possibile specificare i seguenti valori in una stringa di connessione: + Per host, nome host o nome DNS, specifica `mydb.123456789012.us-east-1.rds.amazonaws.com`. + Per la porta, specific `3306`. + Per l'utente, specifica `admin`. Per connettersi a un'istanza database, utilizzare qualsiasi client per un motore di database MySQL. Ad esempio, è possibile utilizzare il client a riga di comando MySQL o MySQL Workbench. Per trovare le informazioni di connessione per un'istanza DB, puoi utilizzare il AWS CLI [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html)comando Console di gestione AWS, o l'DBInstancesoperazione Amazon RDS API [Descrivi](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBInstances.html) per elencarne i dettagli. ## Console **Per trovare le informazioni di connessione per un'istanza DB nel Console di gestione AWS** 1. Accedi a Console di gestione AWS e apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Nel riquadro di spostamento scegliere **Database** per visualizzare un elenco delle istanze database. 1. Scegliere il nome dell'istanza database MySQL per visualizzarne i dettagli. 1. Nella scheda **Connectivity & security (Connettività e sicurezza)**, copiare l'endpoint. Annotare anche il numero di porta. L'endpoint e il numero di porta sono necessari per la connessione all'istanza database. ![\[L’endpoint e la porta di un’istanza database nella console Amazon RDS.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/images/endpoint-port.png) 1. Se è necessario trovare il nome utente master, scegliere la scheda **Configurazione** e visualizzare il valore del **nome utente principale** . ## AWS CLI Per trovare le informazioni di connessione per un'istanza DB MySQL utilizzando AWS CLI il, esegui il comando. [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html) Nella chiamata, eseguire una query per l'ID istanza database, l'endpoint, la porta e il nome utente master. Per Linux, macOS o Unix: ``` aws rds describe-db-instances \ --filters "Name=engine,Values=mysql" \ --query "*[].[DBInstanceIdentifier,Endpoint.Address,Endpoint.Port,MasterUsername]" ``` Per Windows: ``` aws rds describe-db-instances ^ --filters "Name=engine,Values=mysql" ^ --query "*[].[DBInstanceIdentifier,Endpoint.Address,Endpoint.Port,MasterUsername]" ``` L'output visualizzato dovrebbe essere simile al seguente. ``` [ [ "mydb1", "mydb1.123456789012.us-east-1.rds.amazonaws.com", 3306, "admin" ], [ "mydb2", "mydb2.123456789012.us-east-1.rds.amazonaws.com", 3306, "admin" ] ] ``` ## API RDS Per trovare le informazioni di connessione per un'istanza DB utilizzando l'API Amazon RDS, chiama l'DBInstancesoperazione [Descrivi](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBInstances.html). Nell'output, individuare i valori per l'indirizzo dell'endpoint, la porta dell'endpoint e il nome utente master. # Installazione del client a riga di comando MySQL La maggior parte delle distribuzioni Linux include il client MariaDB invece del client Oracle MySQL. Per installare il client della linea di comando MySQL su Amazon Linux 2023, esegui il comando seguente: ``` sudo dnf install mariadb105 ``` Per installare il client della linea di comando MySQL su Amazon Linux 2, esegui il comando seguente: ``` sudo yum install mariadb ``` Per installare il client della riga di comando MySQL sulla maggior parte delle distribuzioni Linux basate su DEB, emettere il comando seguente: ``` apt-get install mariadb-client ``` Per controllare la versione del client a riga di comando MySQL, emettere il seguente comando. ``` mysql --version ``` Per leggere la documentazione MySQL per la versione corrente del client, emettere il comando seguente: ``` man mysql ``` # Connessione dal client a riga di comando MySQL (non crittografato) **Importante** Utilizzare una connessione MySQL non crittografata solo quando il client e il server sono nello stesso VPC e la rete è attendibile. Per ulteriori informazioni sull'uso di connessioni crittografate, consulta [Connessione alla tua istanza DB MySQL su Amazon RDS SSL/TLS dal client a riga di comando MySQL (crittografato)](USER_ConnectToInstanceSSL.CLI.md). Per connetterti a un'istanza database utilizzando il client della riga di comando MySQL, inserisci il seguente comando al prompt dei comandi. Per il parametro -h, sostituisci il nome DNS (endpoint) per la tua istanza database. Per il parametro -P, sostituisci la porta per la tua istanza database. Per il parametro -u, sostituire il nome utente di un utente di database valido, ad esempio l'utente master. Immetti la password dell'utente master quando richiesto. ``` mysql -h mysql–instance1.123456789012.us-east-1.rds.amazonaws.com -P 3306 -u mymasteruser -p ``` Dopo aver immesso la password per l'utente, l'output dovrebbe essere analogo a quanto mostrato di seguito. ``` Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 9738 Server version: 8.0.28 Source distribution Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> ``` # Connessione da MySQL Workbench **Per stabilire una connessione da MySQL Workbench** 1. Scaricare e installare MySQL Workbench dalla pagina di [download di MySQL Workbench](http://dev.mysql.com/downloads/workbench/). 1. Aprire MySQL Workbench. ![\[La schermata di benvenuto di MySQL Workbench.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/images/mysql-workbench-main.png) 1. From **Database**, scegliere **Manage Connections (Gestisci connessioni)**. 1. Nella finestra **Manage Server Connections (Gestisci connessioni al server)**, scegliere **New (Nuova)**. 1. Nella finestra **Connect to Database (Connetti a database)**, immettere le informazioni riportate di seguito: + **Stored Connection (Connessione archiviata)** – Immettere un nome per la connessione, ad esempio **MyDB**. + **Hostname (Nome host)** –Immettere l'endpoint dell'istanza database. + **Port (Porta)** – Immettere la porta usata dall'istanza database. + **Nome utente** – Immettere il nome utente di un utente del database valido, come l'utente master. + **Password** – Facoltativamente, scegliere **Store in Vault (Archivia nel vault)**, quindi immettere e salvare la password per l'utente. La finestra è simile a quanto segue: ![\[La finestra Gestisci connessioni server in MySQL Workbench.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/images/mysql-workbench-connect.png) È possibile utilizzare le funzionalità di MySQL Workbench per personalizzare le connessioni. Ad esempio, puoi utilizzare la scheda **SSL** per configurare le connessioni SSL/TLS. Per informazioni sull'uso di MySQL Workbench, consulta la [documentazione di MySQL Workbench](https://dev.mysql.com/doc/workbench/en/). Crittografia delle connessioni client alle istanze database MySQL con SSL/TLS, consulta [Crittografia delle connessioni client con SSL/TLS due istanze database MySQL su Amazon RDS](mysql-ssl-connections.md). 1. Facoltativamente, scegliere **Test Connection (Verifica connessione)** per confermare che la connessione all'istanza database è stata stabilita correttamente. 1. Scegli **Chiudi**. 1. Da **Database**, scegliere **Connect to Database (Connetti al database)**. 1. Da **Stored Connection (Connessione archiviata)**, scegliere la connessione. 1. Scegliere **OK**. # Connessione a RDS per MySQL con il driver AWS JDBC, il driver AWS Python e il driver ODBC per MySQL AWS Connect alle istanze DB RDS for MySQL con il driver AWS JDBC, il driver AWS Python e il driver ODBC per MySQL. AWS Per ulteriori informazioni, consulta i seguenti argomenti. **Topics** + [ ## Connessione a RDS per MySQL con il driver JDBC per Amazon Web Services (AWS) ](#MySQL.Connecting.JDBCDriver) + [ ## Connessione a RDS per MySQL con il driver Python per Amazon Web Services (AWS) ](#MySQL.Connecting.PythonDriver) + [ ## Connessione a RDS per MySQL con il driver ODBC per Amazon Web Services (AWS) per MySQL. ](#USER_ConnectToInstance.ODBCDriverMySQL) ## Connessione a RDS per MySQL con il driver JDBC per Amazon Web Services (AWS) Il driver JDBC per Amazon Web Services (AWS) è progettato come wrapper JDBC avanzato. Tale wrapper è complementare a un driver JDBC esistente e ne estende le funzionalità. Il driver è compatibile direttamente con il driver MySQL della community Connector/J e il driver MariaDB della community. Connector/J Per installare il driver AWS JDBC, aggiungi il file.jar del driver AWS JDBC (che si trova nell'applicazione) e mantieni i riferimenti al rispettivo driver della community. `CLASSPATH` Aggiorna il rispettivo prefisso dell’URL di connessione nel modo seguente: + `jdbc:mysql://` Da a `jdbc:aws-wrapper:mysql://` + `jdbc:mariadb://` Da a `jdbc:aws-wrapper:mariadb://` Per ulteriori informazioni sul driver AWS JDBC e istruzioni complete per il suo utilizzo, consulta l'archivio dei driver [JDBC di Amazon Web Services (AWS)](https://github.com/awslabs/aws-advanced-jdbc-wrapper). GitHub ## Connessione a RDS per MySQL con il driver Python per Amazon Web Services (AWS) Amazon Web Services (AWS) Python Driver è progettato come wrapper Python avanzato. Tale wrapper è complementare al driver open source Psycopg e ne estende le funzionalità. Il driver Python per AWS supporta Python 3.8 e versioni successive. È possibile installare il pacchetto `aws-advanced-python-wrapper` utilizzando il comando `pip`, insieme ai pacchetti open source `psycopg`. Per ulteriori informazioni sul driver AWS Python e istruzioni complete per il suo utilizzo, consulta il repository [Amazon Web Services ()AWS Python](https://github.com/awslabs/aws-advanced-python-wrapper) Driver. GitHub ## Connessione a RDS per MySQL con il driver ODBC per Amazon Web Services (AWS) per MySQL. Il driver AWS ODBC per MySQL è un driver client progettato per l'elevata disponibilità di RDS per MySQL. Il driver può esistere insieme al driver Connector/ODBC MySQL ed è compatibile con gli stessi flussi di lavoro. Per ulteriori informazioni sul driver AWS ODBC per MySQL e istruzioni complete per installarlo e utilizzarlo, consulta l'archivio [Amazon Web Services AWS() ODBC](https://github.com/aws/aws-mysql-odbc) Driver for MySQL. GitHub # Risoluzione dei problemi relativi alle connessioni all'istanza database MySQL Ecco due cause frequenti degli errori di connessione a una nuova istanza database: + L'istanza database è stata creata tramite un gruppo di sicurezza che non autorizza le connessioni dal dispositivo o dall'istanza Amazon EC2 su cui è in esecuzione l'applicazione o l'utilità di MySQL. L'istanza database deve disporre di un gruppo di sicurezza VPC che autorizzi le connessioni. Per ulteriori informazioni, consulta [Amazon VPC e Amazon RDS](USER_VPC.md). Puoi aggiungere o modificare una regola in entrata nel gruppo di sicurezza: per **Source (Origine)**, scegli **My IP (Il mio IP)**. Questo consente l'accesso all'istanza database dall'indirizzo IP rilevato nel browser. + L'istanza database è stata creata utilizzando la porta predefinita 3306 e nell'azienda vi sono regole del firewall che bloccano le connessioni a tale porta dai dispositivi nella rete aziendale. Per correggere l'errore, ricrea l'istanza con una porta diversa. Per ulteriori informazioni sui problemi di connessione, consulta [Impossibile connettersi all'istanza database di Amazon RDS](CHAP_Troubleshooting.md#CHAP_Troubleshooting.Connecting). # Protezione delle connessioni di istanze database MySQL È possibile implementare solide misure di sicurezza per proteggere le istanze database MySQL da accessi non autorizzati e potenziali minacce. I gruppi di sicurezza, la crittografia SSL/TLS e l’autenticazione del database IAM collaborano per creare più livelli di sicurezza della connessione per le istanze database MySQL. Questi controlli di sicurezza aiutano a soddisfare i requisiti di conformità, prevenire violazioni dei dati e mantenere canali di comunicazione sicuri tra applicazioni e database. Puoi proteggere le istanze database MySQL crittografando i dati in transito, limitando l’accesso a intervalli IP specifici e gestendo l’autenticazione degli utenti tramite ruoli IAM anziché password del database. La sicurezza delle istanze database MySQL viene gestita su tre livelli: + AWS Identity and Access Management controlla chi è in grado di eseguire le operazioni di gestione Amazon RDS nelle istanze database. Quando esegui la connessione ad AWS usando le credenziali IAM, il tuo account IAM deve disporre di policy IAM per la concessione delle autorizzazioni richieste per eseguire le operazioni di gestione di Amazon RDS. Per ulteriori informazioni, consulta [Gestione accessi e identità per Amazon RDS](UsingWithRDS.IAM.md). + Quando crei un'istanza database, utilizzi un gruppo di sicurezza VPC per controllare i dispositivi e le istanze Amazon EC2 che possono aprire le connessioni all'endpoint e alla porta dell'istanza database. Queste connessioni possono essere stabilite tramite Secure Sockets Layer (SSL) e Transport Layer Security (TLS). Le regole del firewall aziendale possono inoltre determinare se i dispositivi in esecuzione nell'azienda possono aprire connessioni all'istanza database. + Per autenticare l’accesso e le autorizzazioni per un’istanza database MySQL puoi seguire uno degli approcci riportati di seguito oppure utilizzare una loro combinazione: + Puoi adottare lo stesso approccio utilizzato per un'istanza standalone di MySQL. I comandi come `CREATE USER`, `RENAME USER`, `GRANT`, `REVOKE` e `SET PASSWORD` funzionano esattamente come nei database in locale, modificando direttamente le tabelle dello schema del database. Tuttavia, la modifica diretta delle tabelle dello schema del database non è una procedura consigliata e, a partire dalla versione 8.0.36 di RDS per MySQL, non è supportata. Per ulteriori informazioni, consulta [ Access Control and Account Management](https://dev.mysql.com/doc/refman/8.0/en/access-control.html) nella documentazione MySQL. + Puoi anche utilizzare l'autenticazione database IAM. Questo metodo prevede l'autenticazione nell'istanza database tramite un utente IAM oppure con un ruolo IAM e un token di autenticazione. Il *token di autenticazione* è un valore univoco, generato tramite il processo di firma Signature Version 4. Quando utilizzi l'autenticazione database IAM, puoi utilizzare le stesse credenziali per controllare l'accesso alle risorse AWS e ai database. Per ulteriori informazioni, consulta [Autenticazione del database IAM per MariaDB, MySQL e PostgreSQL](UsingWithRDS.IAMDBAuth.md). + Un'altra opzione è l'autenticazione Kerberos per RDS per MySQL. L'istanza database funziona con AWS Directory Service for Microsoft Active Directory (AWS Managed Microsoft AD) per abilitare l'autenticazione Kerberos. Quando gli utenti si autenticano con un'istanza database MySQL DB unita al dominio trusting, vengono inoltrate le richieste di autenticazione. Le richieste inoltrate vanno alla directory di dominio creata con Directory Service. Per ulteriori informazioni, consulta [Utilizzo dell’autenticazione Kerberos per Amazon RDS per MySQL](mysql-kerberos.md). Quando crei un'istanza database Amazon RDS, l'utente master ha i seguenti privilegi predefiniti: | Versione del motore | Privilegio del sistema | Ruolo di database | | --- | --- | --- | | RDS per MySQL versione 8.4.3 e successive | `GRANT SELECT`, `INSERT`, `UPDATE`, `DELETE`, `CREATE`, `DROP`, `RELOAD`, `PROCESS`, `REFERENCES`,`INDEX`, `ALTER`, `SHOW DATABASES`, `CREATE TEMPORARY TABLES`, `LOCK TABLES`, `EXECUTE`, `REPLICATION SLAVE`, `REPLICATION CLIENT`, `CREATE VIEW`, `SHOW VIEW`, `CREATE ROUTINE`, `ALTER ROUTINE`, `CREATE USER`, `EVENT`, `TRIGGER`, `CREATE ROLE`, `DROP ROLE`, `APPLICATION_PASSWORD_ADMIN`, `FLUSH_OPTIMIZER_COSTS`, `FLUSH_PRIVILEGES`, `FLUSH_STATUS`, `FLUSH_TABLES`, `FLUSH_USER_RESOURCES`, `ROLE_ADMIN`, `SENSITIVE_VARIABLES_OBSERVER`, `SESSION_VARIABLES_ADMIN`, `SET_ANY_DEFINER`, `SHOW_ROUTINE`, `XA_RECOVER_ADMIN` | `rds_superuser_role` Per ulteriori informazioni su `rds_superuser_role`, consulta [Privilegio basato sui ruoli per RDS per MySQL](Appendix.MySQL.CommonDBATasks.privilege-model.md). | | RDS per MySQL versione 8.0.36 e successive | `SELECT`, `INSERT`, `UPDATE`, `DELETE`, `CREATE`, `DROP`, `RELOAD`, `PROCESS`, `REFERENCES`, `INDEX`, `ALTER`, `SHOW DATABASES`, `CREATE TEMPORARY TABLES`, `LOCK TABLES`, `EXECUTE`, `REPLICATION SLAVE`, `REPLICATION CLIENT`, `CREATE VIEW`, `SHOW VIEW`, `CREATE ROUTINE`, `ALTER ROUTINE`, `CREATE USER`, `EVENT`, `TRIGGER`, `CREATE ROLE`, `DROP ROLE`, `APPLICATION_PASSWORD_ADMIN`, `ROLE_ADMIN`, `SET_USER_ID`, `XA_RECOVER_ADMIN` | `rds_superuser_role` Per ulteriori informazioni su `rds_superuser_role`, consulta [Privilegio basato sui ruoli per RDS per MySQL](Appendix.MySQL.CommonDBATasks.privilege-model.md). | | RDS per MySQL versioni precedenti alla 8.0.36 | `SELECT`, `INSERT`, `UPDATE`, `DELETE`, `CREATE`, `DROP`, `RELOAD`, `PROCESS`, `REFERENCES`, `INDEX`, `ALTER`, `SHOW DATABASES`, `CREATE TEMPORARY TABLES`, `LOCK TABLES`, `EXECUTE`, `REPLICATION CLIENT`, `CREATE VIEW`, `SHOW VIEW`, `CREATE ROUTINE`, `ALTER ROUTINE`, `CREATE USER`, `EVENT`, `TRIGGER`, `REPLICATION SLAVE` | Nessuno | **Nota** È possibile eliminare l'utente master nell'istanza database, ma non è consigliato farlo. Per ricreare l’utente master, utilizza l’operazione [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) dell’API RDS o esegui il comando [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) della AWS CLI e specifica una nuova password utente master con il parametro appropriato. Se l'utente master non è presente nell'istanza, viene creato con la password specificata. Per fornire servizi di gestione per ogni istanza database, viene creato l'utente `rdsadmin` al momento della creazione dell'istanza database. I tentativi di rimuovere l'account `rdsadmin`, assegnargli un nuovo nome, modificarne la password o modificarne i privilegi genereranno un errore. Per consentire la gestione dell'istanza database, i comandi standard `kill` e `kill_query` sono stati limitati. Vengono forniti i comandi Amazon RDS `rds_kill` e `rds_kill_query` per permettere di terminare le sessioni utente o le query nelle istanze database. # Convalida della password per RDS per MySQL MySQL offre il plugin `validate_password` per l'ottimizzazione della sicurezza. Il plugin applica le policy delle password utilizzando i parametri nel gruppo di parametri DB per l'istanza database di MySQL. Il plugin è supportato per le istanze database che eseguono MySQL versione 5.7, 8.0 e 8.4. Per ulteriori informazioni sul plugin `validate_password`, consulta [The Password Validation Plugin](https://dev.mysql.com/doc/refman/5.7/en/validate-password.html) nella documentazione di MySQL. **Per abilitare il plugin `validate_password` per un’istanza database MySQL** 1. Connettiti all'istanza database di MySQL ed esegui questo comando. ``` INSTALL PLUGIN validate_password SONAME 'validate_password.so'; ``` 1. Puoi configurare i parametri per il plugin nel gruppo di parametri DB utilizzato dall'istanza database. Per ulteriori informazioni sui parametri, consulta [Password Validation Plugin Options and Variables](https://dev.mysql.com/doc/refman/5.7/en/validate-password-options-variables.html) nella documentazione di MySQL. Per ulteriori informazioni sulla modifica dei parametri di un'istanza database, consulta [Modifica dei parametri in un gruppo di parametri database in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). 1. Riavviare l'istanza database. Dopo aver abilitato il plugin `validate_password`, reimposta le password esistenti affinché soddisfino le nuove policy di convalida. La tua istanza DB MySQL gestisce la convalida delle password per Amazon RDS. Per modificare una password, devi prima inviare una richiesta di aggiornamento della password tramite la Console di gestione AWS, il comando `modify-db-instance` CLI o l'operazione `ModifyDBInstance` API. RDS accetta inizialmente la tua richiesta, anche se la password non soddisfa le tue policy. RDS elabora quindi la richiesta in modo asincrono. Aggiorna la password nell'istanza DB MySQL solo se la password soddisfa le policy definite. Se la password non soddisfa questi criteri, RDS conserva la password esistente e registra un evento di errore. ``` Unable to reset your password. Error information: Password failed to meet validation rules. ``` Per ulteriori informazioni sugli eventi di Amazon RDS, consulta [Utilizzo della notifica degli eventi di Amazon RDS](USER_Events.md). # Crittografia delle connessioni client con SSL/TLS due istanze database MySQL su Amazon RDS Secure Sockets Layer (SSL) è un protocollo standard del settore utilizzato per proteggere connessioni di rete tra client e server. Dopo SSL versione 3.0, il nome è stato modificato in Transport Layer Security (TLS). Amazon RDS supporta la SSL/TLS crittografia per le istanze DB MySQL. L'utilizzo del SSL/TLS, you can encrypt a connection between your application client and your MySQL DB instance. SSL/TLS supporto è disponibile in tutti i casi Regioni AWS per MySQL. Con Amazon RDS, puoi proteggere i dati in transito crittografando le connessioni client alle istanze DB MySQL con la crittografia per le istanze DB MySQL su Amazon SSL/TLS, requiring SSL/TLS for all connections to a MySQL DB instance, and connecting from the MySQL command-line client with SSL/TLS (encrypted). The following sections provide guidance on configuring and utilizing SSL/TLS RDS. **Topics** + [ # Supporto di SSL/TLS per le istanze database MySQL in Amazon RDS ](MySQL.Concepts.SSLSupport.md) + [ # SSL/TLS Richiesta di account utente specifici per un'istanza DB MySQL su Amazon RDS ](mysql-ssl-connections.require-ssl-users.md) + [ # Richiesta SSL/TLS di tutte le connessioni a un'istanza DB MySQL su Amazon RDS ](mysql-ssl-connections.require-ssl.md) + [ # Connessione alla tua istanza DB MySQL su Amazon RDS SSL/TLS dal client a riga di comando MySQL (crittografato) ](USER_ConnectToInstanceSSL.CLI.md) # Supporto di SSL/TLS per le istanze database MySQL in Amazon RDS Amazon RDS crea un SSL/TLS certificato e lo installa sull'istanza DB quando Amazon RDS effettua il provisioning dell'istanza. Questi certificati sono firmati da un'autorità di certificazione. Il SSL/TLS certificato include l'endpoint dell'istanza DB come nome comune (CN) del SSL/TLS certificato per proteggerlo dagli attacchi di spoofing. Un SSL/TLS certificato creato da Amazon RDS è l'entità root affidabile e dovrebbe funzionare nella maggior parte dei casi, ma potrebbe fallire se l'applicazione non accetta catene di certificati. Se l’applicazione non accetta le catene di certificati, potrebbe essere necessario utilizzare un certificato intermedio per la connessione alla Regione AWS. Ad esempio, devi utilizzare un certificato intermedio per connetterti alle AWS GovCloud (US) regioni con SSL/TLS. Per ulteriori informazioni sul download dei certificati, consultare [](UsingWithRDS.SSL.md). Per ulteriori informazioni sull'utilizzo SSL/TLS con MySQL, vedere. [Aggiornamento delle applicazioni per la connessione a istanze DB MySQL utilizzando nuovi certificati SSL/TLS](ssl-certificate-rotation-mysql.md) In MySQL versione 8.0 e precedenti, per proteggere le connessioni Amazon RDS per MySQL utilizza OpenSSL. In MySQL versione 8.4 e successive, Amazon RDS per MySQL utilizza AWS-LC. Il supporto TLS dipende dalla versione MySQL. La tabella seguente mostra il supporto TLS per le versioni di MySQL. | MySQL versione | TLS 1.0 | TLS 1.1 | TLS 1.2 | TLS 1.3 | | --- | --- | --- | --- | --- | | MySQL 8.4 | Non supportata | Non supportato | Supportato | Supportata | | MySQL 8.0 | Non supportata | Non supportato | Supportato | Supportato | | MySQL 5.7 | Supportato | Supportato | Supportata | Non supportata | # SSL/TLS Richiesta di account utente specifici per un'istanza DB MySQL su Amazon RDS Puoi richiedere SSL/TLS la crittografia per connessioni di account utente specifici alle tue istanze DB MySQL su Amazon RDS. La protezione delle informazioni sensibili da accessi o intercettazioni non autorizzati è fondamentale per applicare le policy di sicurezza in tutti gli ambiti in cui sia necessario mantenere la riservatezza dei dati. Per richiedere SSL/TLS connessioni per account utente specifici, utilizza una delle seguenti istruzioni, a seconda della versione di MySQL, per SSL/TLS richiedere connessioni sull'account utente. `encrypted_user` A tale scopo, utilizza la dichiarazione seguente. ``` ALTER USER 'encrypted_user'@'%' REQUIRE SSL; ``` Per ulteriori informazioni sulle SSL/TLS connessioni con MySQL, consulta la sezione [Utilizzo di connessioni crittografate](https://dev.mysql.com/doc/refman/8.0/en/encrypted-connections.html) nella documentazione di MySQL. # Richiesta SSL/TLS di tutte le connessioni a un'istanza DB MySQL su Amazon RDS Puoi far sì che tutte le connessioni utente all'istanza database MySQL utilizzino SSL/TLS mediante il parametro `require_secure_transport`. Per impostazione predefinita, il parametro `require_secure_transport` è impostato su `OFF`. È possibile impostare il `require_secure_transport` parametro su richiesto `ON` SSL/TLS per le connessioni all'istanza DB. Puoi impostare il valore del parametro `require_secure_transport` aggiornando il gruppo di parametri database per l'istanza database. Non è necessario riavviare l'istanza database affinché la modifica abbia effetto. Quando il parametro `require_secure_transport` è impostato su `ON` per un'istanza database, un client di database può connettersi a essa se è in grado di stabilire una connessione crittografata. In caso contrario, viene restituito al client un messaggio di errore simile al seguente: ``` MySQL Error 3159 (HY000): Connections using insecure transport are prohibited while --require_secure_transport=ON. ``` Per informazioni sull'estensione dei parametri consulta [Modifica dei parametri in un gruppo di parametri database in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). Per ulteriori informazioni sul parametro `require_secure_transport`, consulta la [documentazione di MySQL](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_require_secure_transport). # Connessione alla tua istanza DB MySQL su Amazon RDS SSL/TLS dal client a riga di comando MySQL (crittografato) I parametri del programma client `mysql` variano leggermente a seconda della versione di MySQL o MariaDB in uso. Per scoprire quale versione è disponibile, esegui il comando `mysql` con l’opzione `--version`. Nell'esempio seguente, nell'output viene mostrato che il programma client proviene da MariaDB. ``` $ mysql --version mysql Ver 15.1 Distrib 10.5.15-MariaDB, for osx10.15 (x86_64) using readline 5.1 ``` La maggior parte delle distribuzioni Linux, come Amazon Linux, CentOS, SUSE e Debian, hanno sostituito MySQL con MariaDB e la versione `mysql` presente proviene da MariaDB. Per eseguire la connessione all'istanza database utilizzando SSL/TLS, segui questi passaggi: **Per connettersi a un'istanza DB SSL/TLS utilizzando il client a riga di comando MySQL** 1. Scarica un certificato root che funzioni per tutti. Regioni AWS Per ulteriori informazioni sul download dei certificati, consultare [](UsingWithRDS.SSL.md). 1. Per stabilire la connessione a un'istanza database con la crittografia SSL/TLS, utilizza il client a riga di comando MySQL Per il parametro `-h`, sostituisci il nome DNS (endpoint) per l'istanza database. Per il `--ssl-ca` parametro, sostituisci il nome del file del SSL/TLS certificato. Per il parametro `-P`, sostituisci la porta per l'istanza database. Per il parametro `-u`, sostituisci il nome utente di un utente di database valido, ad esempio l'utente master. Immetti la password dell'utente master quando richiesto. L'esempio seguente mostra come avviare il client utilizzando il parametro `--ssl-ca` per il client MySQL 5.7 o versioni successive. ``` mysql -h mysql–instance1.123456789012.us-east-1.rds.amazonaws.com --ssl-ca=global-bundle.pem --ssl-mode=REQUIRED -P 3306 -u myadmin -p ``` Per richiedere che la SSL/TLS connessione verifichi l'endpoint dell'istanza DB rispetto all'endpoint nel SSL/TLS certificato, inserisci il comando seguente: ``` mysql -h mysql–instance1.123456789012.us-east-1.rds.amazonaws.com --ssl-ca=global-bundle.pem --ssl-mode=VERIFY_IDENTITY -P 3306 -u myadmin -p ``` L'esempio seguente mostra come avviare il client utilizzando il parametro `--ssl-ca` con il client MariaDB. ``` mysql -h mysql–instance1.123456789012.us-east-1.rds.amazonaws.com --ssl-ca=global-bundle.pem --ssl -P 3306 -u myadmin -p ``` 1. Immetti la password dell'utente master quando richiesto. Verrà visualizzato un output simile al seguente. ``` Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 9738 Server version: 8.0.28 Source distribution Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> ``` # Aggiornamento delle applicazioni per la connessione a istanze DB MySQL utilizzando nuovi certificati SSL/TLS A partire dal 13 gennaio 2023, Amazon RDS ha pubblicato nuovi certificati dell'autorità di certificazione (CA) per la connessione alle istanze database RDS utilizzando Secure Socket Layer o Transport Layer Security (SSL/TLS). Di seguito sono disponibili le informazioni sull'aggiornamento delle applicazioni per utilizzare i nuovi certificati. Questo argomento può aiutarti a determinare se alcune applicazioni client vengono utilizzate SSL/TLS per connettersi alle istanze DB. In caso affermativo, puoi determinare anche se le applicazioni richiedono la verifica del certificato per la connessione. **Nota** Alcune applicazioni sono configurate per connettersi ai cluster DB MySQL solo se sono in grado di verificare il certificato del server. Per queste applicazioni, è necessario aggiornare gli archivi di trust delle applicazioni client per includere i nuovi certificati CA. Puoi specificare le seguenti modalità SSL: `disabled`, `preferred` e `required`. Quando si utilizza la modalità SSL `preferred` e il certificato CA non esiste o non è aggiornato, la connessione non utilizza SSL e continua a connettersi senza crittografia. Consigliamo di evitare la modalità `preferred`. In modalità `preferred`, se la connessione rileva un certificato non valido, interrompe l'utilizzo della crittografia e procede in modo non crittografato. Dopo aver aggiornato i certificati CA negli archivi di trust delle applicazioni client, puoi ruotare i certificati nelle istanze database. Consigliamo vivamente di testare queste procedure in un ambiente di sviluppo o di gestione temporanea prima di implementarle negli ambienti di produzione. Per ulteriori informazioni sulla rotazione dei certificati, consulta [Rotazione del certificato SSL/TLS](UsingWithRDS.SSL-certificate-rotation.md). Per ulteriori informazioni sul download, consulta [](UsingWithRDS.SSL.md). Per informazioni sull'utilizzo SSL/TLS con le istanze DB MySQL, vedere. [Supporto di SSL/TLS per le istanze database MySQL in Amazon RDS](MySQL.Concepts.SSLSupport.md) **Topics** + [ ## Determinare se un'applicazione si connette all’istanza database MySQL mediante SSL ](#ssl-certificate-rotation-mysql.determining-server) + [ ## Determinare se un client richiede la verifica del certificato per la connessione ](#ssl-certificate-rotation-mysql.determining-client) + [ ## Aggiornare l'archivio di trust delle applicazioni ](#ssl-certificate-rotation-mysql.updating-trust-store) + [ ## Codice Java di esempio per stabilire connessioni SSL ](#ssl-certificate-rotation-mysql.java-example) ## Determinare se un'applicazione si connette all’istanza database MySQL mediante SSL Se utilizzi Amazon RDS per MySQL versione 5.7, 8.0 o 8.4 e lo schema delle prestazioni è abilitato, esegui la query indicata di seguito per verificare se le connessioni utilizzano SSL/TLS. Per informazioni sull'abilitazione dello schema delle prestazioni, consulta l'argomento relativo alla [guida rapida per lo schema delle prestazioni](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-quick-start.html) nella documentazione di MySQL. ``` mysql> SELECT id, user, host, connection_type FROM performance_schema.threads pst INNER JOIN information_schema.processlist isp ON pst.processlist_id = isp.id; ``` In questo output di esempio, puoi vedere che la tua sessione (`admin`) e un'applicazione collegata come `webapp1` stanno entrambe usando SSL. ``` +----+-----------------+------------------+-----------------+ | id | user | host | connection_type | +----+-----------------+------------------+-----------------+ | 8 | admin | 10.0.4.249:42590 | SSL/TLS | | 4 | event_scheduler | localhost | NULL | | 10 | webapp1 | 159.28.1.1:42189 | SSL/TLS | +----+-----------------+------------------+-----------------+ 3 rows in set (0.00 sec) ``` ## Determinare se un client richiede la verifica del certificato per la connessione Puoi verificare se i client JDBC e MySQL richiedono la verifica del certificato per la connessione. ### JDBC L'esempio seguente con Connector/J MySQL 8.0 mostra un modo per verificare le proprietà di connessione JDBC di un'applicazione per determinare se le connessioni riuscite richiedono un certificato valido. Per ulteriori informazioni su tutte le opzioni di connessione JDBC per MySQL, consulta l'argomento relativo alle [proprietà di configurazione](https://dev.mysql.com/doc/connector-j/en/connector-j-reference-configuration-properties.html) nella documentazione di MySQL. Quando si utilizza Connector/J MySQL 8.0, una connessione SSL richiede la verifica rispetto al certificato del server DB se le proprietà della connessione `sslMode` sono impostate su `VERIFY_IDENTITY` o, come nell'`VERIFY_CA`esempio seguente. ``` Properties properties = new Properties(); properties.setProperty("sslMode", "VERIFY_IDENTITY"); properties.put("user", DB_USER); properties.put("password", DB_PASSWORD); ``` **Nota** Se utilizzi MySQL Java Connector v5.1.38 o successivo oppure MySQL Java Connector v8.0.9 o successivo per connetterti ai tuoi database, anche se non hai configurato esplicitamente le tue applicazioni da SSL/TLS utilizzare per la connessione ai database, questi driver client vengono utilizzati per impostazione predefinita, eseguono una verifica parziale del certificato e non riescono a connettersi se il certificato del server del database è scaduto. SSL/TLS. In addition, when using SSL/TLS ### MySQL I seguenti esempi con il client MySQL mostrano due modi per verificare la connessione MySQL di uno script per determinare se le connessioni riuscite richiedono un certificato valido. Per ulteriori informazioni su tutte le opzioni di connessione con il client MySQL, consulta l'argomento relativo alla [configurazione lato client delle connessioni crittografate](https://dev.mysql.com/doc/refman/8.0/en/using-encrypted-connections.html#using-encrypted-connections-client-side-configuration) nella documentazione di MySQL. Quando utilizzi il client MySQL 5.7 e versioni successive, la connessione SSL richiede la verifica del certificato CA del server se per l’opzione `--ssl-mode` viene specificato `VERIFY_CA` o `VERIFY_IDENTITY`, come nell’esempio seguente. ``` mysql -h mysql-database.rds.amazonaws.com -uadmin -ppassword --ssl-ca=/tmp/ssl-cert.pem --ssl-mode=VERIFY_CA ``` ## Aggiornare l'archivio di trust delle applicazioni Per informazioni sull'aggiornamento dell'archivio attendibilità per le applicazioni MySQL, consulta l'argomento relativo all'[installazione dei certificati SSL](https://dev.mysql.com/doc/mysql-monitor/8.0/en/mem-ssl-installation.html) nella documentazione di MySQL. Per ulteriori informazioni sul download del certificato root, consulta [](UsingWithRDS.SSL.md). Per gli script di esempio che importano i certificati, consulta [Script di esempio per l'importazione di certificati nel tuo archivio di trust](UsingWithRDS.SSL-certificate-rotation.md#UsingWithRDS.SSL-certificate-rotation-sample-script). **Nota** Quando aggiorni l'archivio di trust puoi conservare i certificati meno recenti oltre ad aggiungere i nuovi certificati. Se utilizzi il driver mysql JDBC in un'applicazione, imposta le seguenti proprietà nell'applicazione. ``` System.setProperty("javax.net.ssl.trustStore", certs); System.setProperty("javax.net.ssl.trustStorePassword", "password"); ``` Quando avvii l'applicazione, imposta le seguenti proprietà. ``` java -Djavax.net.ssl.trustStore=/path_to_trust_store/MyTruststore.jks -Djavax.net.ssl.trustStorePassword=my_trust_store_password com.companyName.MyApplication ``` **Nota** Specifica una password diversa dal prompt mostrato qui come best practice per la sicurezza. ## Codice Java di esempio per stabilire connessioni SSL L'esempio di codice seguente mostra come configurare la connessione SSL che convalida il certificato del server utilizzando JDBC. ``` public class MySQLSSLTest { private static final String DB_USER = "username"; private static final String DB_PASSWORD = "password"; // This trust store has only the prod root ca. private static final String TRUST_STORE_FILE_PATH = "file-path-to-trust-store"; private static final String TRUST_STORE_PASS = "trust-store-password"; public static void test(String[] args) throws Exception { Class.forName("com.mysql.jdbc.Driver"); System.setProperty("javax.net.ssl.trustStore", TRUST_STORE_FILE_PATH); System.setProperty("javax.net.ssl.trustStorePassword", TRUST_STORE_PASS); Properties properties = new Properties(); properties.setProperty("sslMode", "VERIFY_IDENTITY"); properties.put("user", DB_USER); properties.put("password", DB_PASSWORD); Connection connection = null; Statement stmt = null; ResultSet rs = null; try { connection = DriverManager.getConnection("jdbc:mysql://mydatabase.123456789012.us-east-1.rds.amazonaws.com:3306",properties); stmt = connection.createStatement(); rs=stmt.executeQuery("SELECT 1 from dual"); } finally { if (rs != null) { try { rs.close(); } catch (SQLException e) { } } if (stmt != null) { try { stmt.close(); } catch (SQLException e) { } } if (connection != null) { try { connection.close(); } catch (SQLException e) { e.printStackTrace(); } } } return; } } ``` **Importante** Dopo aver stabilito che le connessioni al database utilizzano SSL/TLS e aggiornato l'archivio attendibile delle applicazioni, è possibile aggiornare il database per utilizzare i certificati rds-ca-rsa 2048-g1. Per istruzioni, consulta la fase 3 in [Aggiornamento del certificato CA modificando l’istanza database o il cluster di database](UsingWithRDS.SSL-certificate-rotation.md#UsingWithRDS.SSL-certificate-rotation-updating). Specifica una password diversa dal prompt mostrato qui come best practice per la sicurezza. # Utilizzo dell’autenticazione Kerberos per Amazon RDS per MySQL Puoi utilizzare Autenticazione Kerberos per autenticare gli utenti quando si connettono all'istanza database MySQL. L'istanza DB funziona con AWS Directory Service for Microsoft Active Directory (AWS Managed Microsoft AD) per abilitare l'autenticazione Kerberos. Quando gli utenti si autenticano con un'istanza database MySQL DB unita al dominio trusting, vengono inoltrate le richieste di autenticazione. Le richieste inoltrate vanno alla directory del dominio con cui crei. Directory Service Mantenere tutte le credenziali nella stessa directory consente di ridurre il tempo e l'impegno. Con questo approccio, è disponibile una posizione centralizzata per archiviare e gestire le credenziali per più istanze database. L'uso di una directory può inoltre migliorare il profilo di sicurezza complessivo. ## Disponibilità di regioni e versioni Il supporto varia a seconda delle versioni specifiche di ciascun motore di database e a seconda delle Regioni AWS. Per ulteriori informazioni sulla disponibilità di versioni e regioni per Amazon RDS con autenticazione Kerberos, consulta [Regioni e motori di database supportati per l’autenticazione Kerberos in Amazon RDS](Concepts.RDS_Fea_Regions_DB-eng.Feature.KerberosAuthentication.md). ## Panoramica della configurazione dell'autenticazione Kerberos per istanze database MySQL Per configurare l'autenticazione Kerberos per un'istanza database MySQL, completa le seguenti fasi generali, descritte in dettaglio più avanti: 1. Usa AWS Managed Microsoft AD per creare una AWS Managed Microsoft AD directory. È possibile utilizzare il Console di gestione AWSAWS CLI, il o il Directory Service per creare la directory. Per ulteriori informazioni su questa operazione, consulta [Creare la AWS Managed Microsoft AD directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_getting_started_create_directory.html) nella *Guida all'AWS Directory Serviceamministrazione*. 1. Crea un ruolo AWS Identity and Access Management (IAM) che utilizzi la policy IAM gestita`AmazonRDSDirectoryServiceAccess`. Il ruolo consente ad Amazon RDS di effettuare chiamate alla tua directory. Affinché il ruolo consenta l'accesso, l'endpoint AWS Security Token Service (AWS STS) deve essere attivato nel campo Regione AWS per il tuo AWS account. AWS STSGli endpoint sono tutti Regioni AWS attivi per impostazione predefinita e puoi utilizzarli senza ulteriori azioni. *Per ulteriori informazioni, consulta [Attivazione e disattivazione AWS STSRegione AWS in un](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html#sts-regions-activate-deactivate) capitolo della IAM User Guide.* 1. Crea e configura gli utenti nella AWS Managed Microsoft AD directory utilizzando gli strumenti di Microsoft Active Directory. Per ulteriori informazioni sulla creazione di utenti in Active Directory, vedere [Gestire utenti e gruppi in Microsoft AD AWS gestito](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_manage_users_groups.html) nella *Guida all'AWS Directory Serviceamministrazione*. 1. Creazione o modifica di un'istanza database MySQL. Se si utilizza l'interfaccia a riga di comando (CLI) o l'API RDS nella richiesta di creazione, specificare un identificatore di dominio con il parametro `Domain`. Utilizzare l'identificatore `d-*` generato al momento della creazione della directory e il nome del ruolo creato. Se si modifica un'istanza database MySQL esistente per utilizzare l'autenticazione Kerberos, impostare i parametri di dominio e ruolo IAM per l'istanza database. Individuare l'istanza database nello stesso VPC della directory di dominio. 1. Utilizza le credenziali dell'utente master Amazon RDS per connetterti all'istanza database MySQL. Crea l'utente in MySQL utilizzando la clausola `CREATE USER` `IDENTIFIED WITH 'auth_pam'`. Gli utenti creati in questo modo possono accedere all'istanza database MySQL utilizzando l'autenticazione Kerberos. ## Configurazione dell'autenticazione Kerberos per istanze database MySQL Si utilizza AWS Managed Microsoft AD per configurare l'autenticazione Kerberos per un'istanza DB MySQL. Per configurare l'autenticazione Kerberos, completa la procedura seguente. ### Passaggio 1: creare una directory utilizzando AWS Managed Microsoft AD Directory Servicecrea una Active Directory completamente gestita nel AWS cloud. Quando crei una AWS Managed Microsoft AD directory, Directory Service crea due controller di dominio e server DNS (Domain Name System) per tuo conto. I server di directory vengono creati in sottoreti diverse in un VPC. Questa ridondanza assicura che la directory rimanga accessibile anche se si verifica un errore. Quando crei una AWS Managed Microsoft AD directory, Directory Service esegue le seguenti attività per tuo conto: + Configura una Active Directory all'interno del VPC. + Crea un account amministratore della directory con nome utente Admin e la password specificata. Puoi utilizzare questo account per gestire le directory. **Nota** Assicurati di salvare questa password. Directory Servicenon la memorizza. È possibile reimpostarla ma non recuperarla. + Crea un gruppo di sicurezza per i controller della directory. Quando si avvia unAWS Managed Microsoft AD, AWS crea un'unità organizzativa (OU) che contiene tutti gli oggetti della directory. Questa unità organizzativa ha lo stesso nome NetBIOS che hai digitato al momento della creazione della directory e si trova nella radice del dominio. La radice del dominio è di proprietà e gestita daAWS. L'account amministratore creato con la AWS Managed Microsoft AD directory dispone delle autorizzazioni per le attività amministrative più comuni dell'unità organizzativa: + Creazione, aggiornamento o eliminazione di utenti + Aggiungi risorse al dominio, come file server o server di stampa, e assegna le autorizzazioni per tali risorse a utenti dell'unità organizzativa + Crea contenitori aggiuntivi OUs e + Delega dell'autorità + Ripristino degli oggetti eliminati dal cestino di Active Directory + Esegui i PowerShell moduli Windows AD e DNS sul servizio Web Active Directory L'account Admin dispone inoltre dei diritti per eseguire le seguenti attività estese a tutto il dominio: + gestione delle configurazioni DNS (aggiunta, eliminazione o aggiornamento di record, zone e server d'inoltro); + visualizzazione di log di eventi DNS; + visualizzazione di log di eventi di sicurezza. **Per creare una directory con AWS Managed Microsoft AD** 1. Accedi a Console di gestione AWS e apri la Directory Service console all'indirizzo [https://console.aws.amazon.com/directoryservicev2/](https://console.aws.amazon.com/directoryservicev2/). 1. Nel riquadro di navigazione, seleziona **Directories (Directory)** e quindi **Set up directory (Configura la directory)**. 1. Scegli **AWS Managed Microsoft AD**. AWS Managed Microsoft ADè l'unica opzione attualmente utilizzabile con Amazon RDS. 1. Immettere le seguenti informazioni: **Nome DNS directory** Il nome completo della directory, ad esempio **corp.example.com**. **Nome NetBIOS della directory** Nome breve per la directory, ad esempio **CORP**. **Descrizione della directory** (Opzionale) Una descrizione della directory. **Password amministratore** La password dell'amministratore della directory. Con il processo di creazione della directory viene generato un account amministratore con il nome utente Admin e questa password. La password dell'amministratore della directory e non può includere il termine "admin". La password distingue tra maiuscole e minuscole e la lunghezza deve essere compresa tra 8 e 64 caratteri. Deve anche contenere un carattere di almeno tre delle seguenti quattro categorie: + Lettere minuscole (a–z) + Lettere maiuscole (A–Z) + Numeri (0–9) + Caratteri non alfanumerici (\$1\$1@\$1\$1%^&\$1\$1-\$1=`\$1\$1()\$1\$1[]:;"'<>,.?/) **Confirm password (Conferma password)** La password dell'amministratore digitata nuovamente. 1. Scegli **Next (Successivo)**. 1. Immettere le seguenti informazioni nella sezione **Networking (Rete)** e quindi scegliere **Next (Avanti)**: **VPC** VPC per la directory. Crea l'istanza database MySQL in questo stesso VPC. **Sottoreti** Sottoreti per i server di directory. Le due sottoreti devono trovarsi in diverse zone di disponibilità. 1. Esaminare le informazioni relative alla directory e apportare eventuali modifiche. Quando le informazioni sono corrette, scegli **Create Directory (Crea directory)**. ![\[La finestra Review & create durante la creazione della directory nella Directory Service console.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/images/WinAuth2.png) Per creare la directory sono necessari alcuni minuti. Una volta creata correttamente la directory, il valore **Status (Stato)** viene modificato in **Active (Attivo)**. Per consultare le informazioni sulla directory, selezionare il nome della directory nell'elenco di directory. Prendere nota del valore di **Directory ID (ID directory)** perché sarà necessario quando si crea o si modifica l'istanza database MySQL. ![\[La sezione dei dettagli della directory con l'ID della directory nella Directory Service console.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/images/WinAuth3.png) ### Fase 2: creazione del ruolo IAM per l'utilizzo da parte di Amazon RDS Affinché Amazon RDS possa Directory Service chiamarti, è necessario un ruolo IAM che utilizzi la policy `AmazonRDSDirectoryServiceAccess` IAM gestita. Questo ruolo permette ad Amazon RDS di effettuare chiamate alla Directory Service. Quando un'istanza DB viene creata utilizzando Console di gestione AWS e l'utente della console dispone dell'`iam:CreateRole`autorizzazione, la console crea questo ruolo automaticamente. In questo caso, il nome del ruolo è `rds-directoryservice-kerberos-access-role`. In caso contrario, è necessario creare manualmente il ruolo IAM. Quando crei questo ruolo IAM`Directory Service`, scegli e allega la policy AWS gestita `AmazonRDSDirectoryServiceAccess` ad esso. Per ulteriori informazioni sulla creazione di ruoli IAM per un servizio, consulta [Creating a role to delegate permissions to an AWS service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) nella *IAM User* Guide. **Nota** Il ruolo IAM utilizzato per l'autenticazione Windows per RDS per SQL Server non può essere utilizzato per RDS per MySQL. Facoltativamente, puoi creare policy con le autorizzazioni richieste anziché utilizzare la policy IAM gestita `AmazonRDSDirectoryServiceAccess`. In questo caso, il ruolo IAM deve avere la seguente policy di attendibilità IAM. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "", "Effect": "Allow", "Principal": { "Service": [ "directoryservice.rds.amazonaws.com", "rds.amazonaws.com" ] }, "Action": "sts:AssumeRole" } ] } ``` ------ Il ruolo deve anche disporre della seguente policy del ruolo IAM. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": [ "ds:DescribeDirectories", "ds:AuthorizeApplication", "ds:UnauthorizeApplication", "ds:GetAuthorizedApplicationDetails" ], "Effect": "Allow", "Resource": "*" } ] } ``` ------ ### Fase 3: creazione e configurazione di utenti È possibile creare utenti con lo strumento Utenti Active Directory e computer. Questo strumento fa parte degli strumenti Active Directory Domain Services e Active Directory Lightweight Directory Services. Gli utenti possono essere individui singoli o entità che hanno accesso alla tua directory. Per creare utenti in una Directory Service directory, devi essere connesso a un' EC2 istanza Amazon basata su Microsoft Windows. Questa istanza deve essere un membro della Directory Service directory ed essere connessa come utente con privilegi per creare utenti. Per ulteriori informazioni, consulta [Gestione di utenti e gruppi in AWS Managed Microsoft AD](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/creating_ad_users_and_groups.html) nella *AWS Directory Service - Guida di amministrazione*. ### Fase 4: creazione o modifica di un'istanza database MySQL Creazione o modifica di un'istanza database MySQL per l'utilizzo con la directory. Puoi utilizzare la console, CLI o l'API RDS per associare un'istanza database a una directory. Questa operazione può essere eseguita in uno dei seguenti modi: + [Crea una nuova istanza DB MySQL utilizzando la console, il comando [ create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)CLI o l'operazione Create RDS API. DBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) Per istruzioni, consulta [Creazione di un'istanza database Amazon RDS](USER_CreateDBInstance.md). + [Modifica un'istanza DB MySQL esistente utilizzando la console, il comando [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)CLI o l'operazione Modify RDS API. DBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) Per istruzioni, consulta [Modifica di un'istanza database Amazon RDS](Overview.DBInstance.Modifying.md). + [Ripristina un'istanza DB MySQL da un'istantanea del DB utilizzando la console, il comando CLI [ restore-db-instance-from-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html) o l'operazione dell'API Restore From RDS. DBInstance DBSnapshot](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html) Per istruzioni, consulta [Ripristino in un’istanza database](USER_RestoreFromSnapshot.md). + [Ripristina un'istanza DB MySQL utilizzando la console, il comando [ restore-db-instance-to- point-in-time](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html) CLI o l'operazione Restore RDS API. point-in-time DBInstance ToPointInTime](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceToPointInTime.html) Per istruzioni, consulta [Ripristino di un’istanza database a un punto temporale specifico per Amazon RDS](USER_PIT.md). L'autenticazione Kerberos è supportata solo per istanze database MySQL in un VPC. L'istanza database Oracle può trovarsi nello stesso VPC della directory o in un VPC diverso. L'istanza database deve utilizzare un gruppo di sicurezza che accetta traffico in uscita all'interno del VPC della directory, in modo che l'istanza database possa comunicare con la directory. Quando utilizzi la console per creare, modificare o ripristinare un'istanza database, scegli **Password e autenticazione Kerberos** nella sezione **Autenticazione database**. Scegli **Browse Directory (Sfoglia directory)** quindi seleziona la directory oppure scegli **Create a new directory (Crea una nuova directory)**. ![\[Sezione Autenticazione database con l’opzione Autenticazione di password e Kerberos selezionata nella console Amazon RDS.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/images/kerberos-authentication.png) Quando utilizzi l'API AWS CLI o RDS, associa un'istanza DB a una directory. Per consentire all'istanza database di utilizzare la directory del dominio che hai creato, sono necessari i seguenti parametri: + Per il parametro `--domain`, utilizza l'identificatore di dominio (identificatore "d-\$1") generato durante la creazione della directory. + Per il parametro `--domain-iam-role-name`, utilizza il ruolo creato che utilizza la policy IAM gestita `AmazonRDSDirectoryServiceAccess`. Ad esempio, il comando CLI seguente modifica un'istanza database per utilizzare una directory. Per Linux, macOS o Unix: ``` aws rds modify-db-instance \ --db-instance-identifier mydbinstance \ --domain d-ID \ --domain-iam-role-name role-name ``` Per Windows: ``` aws rds modify-db-instance ^ --db-instance-identifier mydbinstance ^ --domain d-ID ^ --domain-iam-role-name role-name ``` **Importante** Se modifichi un'istanza database per abilitare l'autenticazione Kerberos, riavvia l'istanza database dopo aver apportato la modifica. ### Fase 5: creazione di login MySQL di autenticazione Kerberos Usa le credenziali dell'utente master Amazon RDS per eseguire la connessione all'istanza database MySQL come con qualunque altra istanza database. L'istanza DB viene aggiunta al AWS Managed Microsoft AD dominio. Pertanto, puoi effettuare il provisioning di login e utenti MySQL da utenti Active Directory nel dominio. Le autorizzazioni del database vengono gestite tramite autorizzazioni MySQL standard concesse e revocate da questi accessi. È possibile consentire a un utente di Active Directory di autenticarsi con MySQL. Per fare ciò, utilizzare innanzitutto le credenziali utente master Amazon RDS per connettersi all'istanza database MySQL come con qualsiasi altra istanza database. Dopo aver effettuato l’accesso, creare un utente autenticato esternamente con PAM (Pluggable Authentication Modules) in MySQL eseguendo questo comando. Sostituire `testuser` con il nome utente. ``` CREATE USER 'testuser'@'%' IDENTIFIED WITH 'auth_pam'; ``` Gli utenti (persone e applicazioni) del dominio possono ora connettersi all'istanza database da un computer client associato al dominio utilizzando l'autenticazione Kerberos. **Importante** Consigliamo vivamente ai client di utilizzare SSL/TLS le connessioni quando utilizzano l'autenticazione PAM. Se non utilizzano SSL/TLS connessioni, in alcuni casi la password potrebbe essere inviata come testo non crittografato. Per richiedere una connessione SSL/TLS crittografata per il tuo utente AD, esegui il comando seguente e sostituiscilo `testuser` con il nome utente: ``` ALTER USER 'testuser'@'%' REQUIRE SSL; ``` Per ulteriori informazioni, consulta [Supporto di SSL/TLS per le istanze database MySQL in Amazon RDS](MySQL.Concepts.SSLSupport.md). ## Gestione di un'istanza database in un dominio Puoi utilizzare la CLI o l'API RDS per gestire l'istanza database e la sua relazione con Active Directory gestita. Ad esempio, è possibile associare un'autenticazione di Active Directory per Kerberos e annullare l'associazione di una Active Directory per disabilitare l'autenticazione Kerberos. Puoi anche spostare un'istanza database affinché venga autenticata esternamente da una Microsoft Active Directory a un'altra. Ad esempio, puoi utilizzare l'API Amazon RDS per effettuare quanto segue: + Per tentare di attivare nuovamente l'autenticazione Kerberos per un'appartenenza non riuscita, utilizzare l'operazione API `ModifyDBInstance` e specificare l'ID della directory dell'appartenenza corrente. + Per aggiornare il nome del ruolo IAM dell'appartenenza, utilizza l'operazione API `ModifyDBInstance` e specifica l'ID della directory dell'appartenenza corrente e il nuovo ruolo IAM. + Per disabilitare l'autenticazione Kerberos in un'istanza database, utilizzare l'operazione API `ModifyDBInstance` e specificare `none` come parametro di dominio. + Per spostare un'istanza database da un dominio a un altro, utilizza l'operazione API `ModifyDBInstance` e specifica l'identificatore di dominio del nuovo dominio come parametro del dominio. + Per elencare l'appartenenza per ogni istanza database, utilizzare l'operazione API `DescribeDBInstances`. ### Appartenenza al dominio Quando l'istanza database viene creata o modificata diventa membro del dominio. È possibile visualizzare lo stato dell'appartenenza al dominio per l'istanza DB eseguendo il comando [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html)CLI. Lo stato dell'istanza di database può essere uno dei seguenti: + `kerberos-enabled`: l'autenticazione Kerberos è abilitata nell'istanza database. + `enabling-kerberos`— AWS sta abilitando l'autenticazione Kerberos su questa istanza DB. + `pending-enable-kerberos`: l'abilitazione dell'autenticazione Kerberos è in sospeso su questa istanza database. + `pending-maintenance-enable-kerberos`— AWS tenterà di abilitare l'autenticazione Kerberos sull'istanza DB durante la successiva finestra di manutenzione pianificata. + `pending-disable-kerberos`: la disabilitazione dell'autenticazione Kerberos è in sospeso su questa istanza database. + `pending-maintenance-disable-kerberos`— AWS tenterà di disabilitare l'autenticazione Kerberos sull'istanza DB durante la successiva finestra di manutenzione programmata. + `enable-kerberos-failed` - Un problema di configurazione ha impedito a AWS di abilitare l'autenticazione Kerberos sull'istanza database. Verifica e correggi la configurazione prima di eseguire nuovamente il comando di modifica dell'istanza database. + `disabling-kerberos`— AWS sta disabilitando l'autenticazione Kerberos su questa istanza DB. Una richiesta per abilitare l'autenticazione Kerberos potrebbe non andare a buon fine a causa di un problema di connettività di rete o un ruolo IAM non corretto. Ad esempio, si supponga di creare un'istanza database o di modificare un'istanza database esistente e il tentativo di attivare l'autenticazione Kerberos non riesce. In questo caso, eseguire nuovamente il comando di modifica o modificare l'istanza database appena creata per l'aggiunta al dominio. ## Connessione a MySQL con l'autenticazione Kerberos Per connetterti a MySQL con l'autenticazione Kerberos, è necessario accedere utilizzando il tipo di autenticazione Kerberos. Per creare un utente di database a cui è possibile connettersi utilizzando l'autenticazione Kerberos, utilizzare una clausola `IDENTIFIED WITH` sull'istruzione `CREATE USER`. Per istruzioni, consulta [Fase 5: creazione di login MySQL di autenticazione Kerberos](#mysql-kerberos-setting-up.create-logins). Per evitare errori, utilizzare il client `mysql` MariaDB. È possibile scaricare il software MariaDB all'indirizzo [https://downloads.mariadb.org/](https://downloads.mariadb.org/). Al prompt dei comandi, connettersi a uno degli endpoint associati all'istanza database MySQL. Seguire le procedure generali descritte in [Connessione all’istanza database MySQL](USER_ConnectToInstance.md). Quando viene richiesta la password, immettere la password Kerberos associata al nome utente. ## Ripristino di un'istanza database MySQL e aggiunta a un dominio È possibile ripristinare uno snapshot DB o completare un point-in-time ripristino per un'istanza DB MySQL e quindi aggiungerla a un dominio. Dopo aver ripristinato l'istanza database, modificarla utilizzando il processo illustrato in [Fase 4: creazione o modifica di un'istanza database MySQL](#mysql-kerberos-setting-up.create-modify) per aggiungere l'istanza database a un dominio. ## Limitazioni MySQL per l'autenticazione Kerberos Le seguenti limitazioni si applicano all'autenticazione Kerberos per MySQL: + È supportato solo unAWS Managed Microsoft AD. Tuttavia, puoi aggiungere le istanze database RDS per MySQL a domini Managed Microsoft AD condivisi di proprietà di account diversi nella stessa Regione AWS. + È necessario riavviare l'istanza database dopo aver abilitato la caratteristica. + La lunghezza del nome di dominio non può essere superiore a 61 caratteri. + Non è possibile abilitare contemporaneamente l'autenticazione Kerberos e l'autenticazione IAM. Scegli un metodo di autenticazione o l'altro per l'istanza database MySQL. + Non modificare la porta dell'istanza database dopo aver abilitato la caratteristica. + Non utilizzare l'autenticazione Kerberos con le repliche di lettura. + Se è attivato l'aggiornamento automatico della versione secondaria per un'istanza database MySQL che utilizza l'autenticazione Kerberos, è necessario disattivare l'autenticazione Kerberos e riattivarla dopo un aggiornamento automatico. Per maggiori informazioni sull’aggiornamento automatico di una versione minore, consulta [Aggiornamenti automatici a versioni secondarie per RDS per MySQL](USER_UpgradeDBInstance.MySQL.Minor.md). + Per eliminare un'istanza database con questa caratteristica abilitata, disabilitare prima la caratteristica. A tale scopo, eseguire il comando CLI `modify-db-instance` per l’istanza database e specificare `none` per il parametro `--domain`. Se si utilizza l'interfaccia a riga di comando (CLI) o l'API RDS per eliminare un'istanza database con questa caratteristica attivata, prevedere un ritardo. + RDS per MySQL non supporta l’autenticazione Kerberos in un trust tra foreste tra Active Directory on-premises o in hosting autonomo e AWS Managed Microsoft AD. # Prestazioni delle query migliorate per RDS per MySQL con Amazon RDS Optimized Reads Puoi ottenere un'elaborazione delle query più rapida per RDS per MySQL con Amazon RDS Optimized Reads. Un'istanza database RDS per MySQL o un cluster database multi-AZ che utilizza la funzionalità Letture ottimizzate per Amazon RDS può ottenere un'elaborazione delle query fino a due volte più veloce rispetto a un'istanza o un cluster database che non lo utilizza. **Topics** + [ ## Panoramica di RDS Optimized Reads ](#rds-optimized-reads-overview) + [ ## Casi d'uso per RDS Optimized Reads ](#rds-optimized-reads-use-cases) + [ ## Best practice per RDS Optimized Reads ](#rds-optimized-reads-best-practices) + [ ## Utilizzo di RDS Optimized Reads ](#rds-optimized-reads-using) + [ ## Monitoraggio delle istanze database che utilizzano RDS Optimized Reads ](#rds-optimized-reads-monitoring) + [ ## Limitazioni per RDS Optimized Reads ](#rds-optimized-reads-limitations) ## Panoramica di RDS Optimized Reads Quando si utilizza un'istanza database RDS per MySQL o un cluster database multi-AZ con la funzionalità Letture ottimizzate per Amazon RDS attivata, si otterranno prestazioni di query più rapide tramite l'uso di un archivio dell'istanza. Un *archivio istanze* fornisce uno storage temporaneo di livello per l'istanza database o il cluster database multi-AZ. L'archiviazione è basata su unità di memoria a stato solido (SSD) NVMe (Non-Volatile Memory Express) fisicamente collegata al server host. Questa archiviazione è ottimizzata per bassa latenza, prestazioni I/O casuali elevate e velocità di trasmissione effettiva di lettura sequenziale elevata. La funzionalità Letture ottimizzate per Amazon RDS è attivata per impostazione predefinita quando un'istanza database o un cluster database multi-AZ utilizza una classe di istanza database con un archivio dell'istanza, ad esempio db.m5d o db.m6gd. Con RDS Optimized Reads, alcuni oggetti temporanei vengono archiviati nell'archivio dell'istanza. Questi oggetti temporanei includono file temporanei interni, tabelle temporanee interne su disco, file di mappe in memoria e file di cache di log binario (binlog). Per ulteriori informazioni sull'archivio dell'istanza, consulta [Instance store Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html) nella *Guida per l'utente di Amazon Elastic Compute Cloud per istanze Linux*. I carichi di lavoro che generano gli oggetti temporanei in MySQL per l'elaborazione delle query possono sfruttare l'archivio dell'istanza per elaborare più rapidamente le query. Questo tipo di carico di lavoro include query che coinvolgono ordinamenti, aggregazioni di hash, join a carico elevato, espressioni di tabella comuni (CTE) e query su colonne non indicizzate. Questi volumi dell'archivio dell'istanza forniscono operazioni IOPS e prestazioni più elevate, indipendentemente dalle configurazioni utilizzate per l'archivio persistente di Amazon EBS. Poiché RDS Optimized Reads trasferisce le operazioni sugli oggetti temporanei all'archivio dell'istanza, le operazioni di input/output al secondo (IOPS) o la velocità di trasmissione effettiva dell'archivio persistente (Amazon EBS) possono ora essere utilizzate per le operazioni su oggetti persistenti. Queste includono le normali operazioni di lettura e scrittura dei file di dati e le operazioni del motore in background, come lo svuotamento e l'unione di inserimenti di buffer. **Nota** Gli snapshot RDS manuali e automatici contengono solo i file del motore per gli oggetti persistenti. Gli oggetti temporanei creati nell'archivio dell'istanza non sono inclusi negli snapshot RDS. ## Casi d'uso per RDS Optimized Reads Se hai carichi di lavoro che si basano pesantemente sugli oggetti temporanei, come tabelle o file interni, per l'esecuzione delle query, puoi trarre vantaggio dall'attivazione di RDS Optimized Reads. I seguenti casi d'uso sono candidati per RDS Optimized Reads: + Applicazioni che eseguono query analitiche con espressioni di tabella comuni (CTE) complesse, tabelle derivate e operazioni di raggruppamento + Repliche di lettura che generano un intenso traffico di lettura con query non ottimizzate + Applicazioni che eseguono query di report on demand o dinamiche che includono operazioni complesse, ad esempio query con le clausole `GROUP BY` e `ORDER BY` + Carichi di lavoro che utilizzano tabelle temporanee interne per l'elaborazione delle query È possibile monitorare la variabile di stato del motore `created_tmp_disk_tables` per determinare il numero di tabelle temporanee basate su disco create nell'istanza database. + Applicazioni che creano tabelle temporanee di grandi dimensioni, direttamente o tramite procedure, per archiviare risultati intermedi + Query di database che eseguono il raggruppamento o l'ordinamento di colonne non indicizzate ## Best practice per RDS Optimized Reads Usa le seguenti best practice per RDS Optimized Reads: + Aggiungi la logica dei tentativi per le query di sola lettura, nel caso in cui non riescano perché l'archivio dell'istanza è completo durante l'esecuzione. + Monitora lo spazio di archiviazione disponibile nell'archivio dell'istanza con la metrica CloudWatch `FreeLocalStorage`. Se l'archivio dell'istanza sta raggiungendo il limite a causa del carico di lavoro dell'istanza database, modifica l'istanza database in modo da utilizzare una classe di istanza database più grande. + Se l'istanza database o il cluster database multi-AZ ha memoria sufficiente ma raggiunge comunque il limite di archiviazione dell'archivio dell'istanza, aumentare il valore `binlog_cache_size` per mantenere in memoria le voci binlog specifiche della sessione. Questa configurazione impedisce di scrivere le voci binlog in file di cache binlog temporanei memorizzati su disco. Il parametro `binlog_cache_size` è specifico della sessione. É possibile modificare il valore per ogni nuova sessione. L'impostazione di questo parametro può aumentare l'utilizzo della memoria dell'istanza database durante i picchi di carico di lavoro. Pertanto, è consigliabile aumentare il valore del parametro in base al modello di carico di lavoro dell'applicazione e alla memoria disponibile nell'istanza database. + Per MySQL 8.0 e versioni precedenti, utilizza il valore `MIXED` predefinito per il parametro `binlog_format`. A seconda della dimensione delle transazioni, l'impostazione `binlog_format` su `ROW` può comportare la creazione di file di cache binlog di grandi dimensioni nell'archivio dell'istanza. Per MySQL 8.4 e versioni successive, utilizza il valore `ROW` predefinito per il parametro `binlog_format`. + Imposta il parametro [internal\$1tmp\$1mem\$1storage\$1engine](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_internal_tmp_mem_storage_engine) su `TempTable` e il parametro [temptable\$1max\$1mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap) in modo che corrisponda alla dimensione dello spazio di archiviazione disponibile nell'archivio dell'istanza. + Evita di apportare modifiche in blocco in una singola transazione. Questi tipi di transazioni possono generare file di cache binlog di grandi dimensioni nell'archivio dell'istanza e possono causare problemi quando l'archivio dell'istanza è pieno. Prendi in considerazione la suddivisione delle scritture in transazioni più piccole per ridurre al minimo l'uso dello spazio di archiviazione per i file di cache binlog. + Usa il valore predefinito `ABORT_SERVER` per il parametro `binlog_error_action`. In questo modo si evitano problemi con i log binari sulle istanze database con i backup abilitati. ## Utilizzo di RDS Optimized Reads L'istanza database utilizza automaticamente la funzionalità Letture ottimizzate per Amazon RDS quando si effettua il provisioning di un'istanza database RDS per MySQL con una delle seguente classi di istanza database in un'implementazione di istanza database single-AZ o multi-AZ oppure in un'implementazione di cluster database multi-AZ: Per attivare RDS Optimized Reads, procedi in uno dei seguenti modi: + Creare un'istanza database o un cluster database multi-AZ RDS per MySQL utilizzando una di queste classi di istanza database. Per ulteriori informazioni, consulta [Creazione di un'istanza database Amazon RDS](USER_CreateDBInstance.md). + Modificare un'istanza database o un cluster database multi-AZ RDS per MySQL esistente per utilizzare una di queste classi di istanza database. Per ulteriori informazioni, consulta [Modifica di un'istanza database Amazon RDS](Overview.DBInstance.Modifying.md). La funzionalità Letture ottimizzate per Amazon RDS è disponibile in tutte le Regioni AWS RDS in cui sono supportate una o più delle classi di istanza database con spazio di archiviazione SSD NVMe locale. Per informazioni sulle classi di istanza database, consulta [Classi di istanze DB ](Concepts.DBInstanceClass.md). La disponibilità della classe di istanze DB è diversa nelle varie Regioni AWS. Per determinare se una classe di istanza DB è supportata in una Regione AWS specifica, consulta [Determinazione del supporto della classe di istanze DB in Regioni AWS](Concepts.DBInstanceClass.RegionSupport.md). Se non si desidera utilizzare la funzionalità Letture ottimizzate per Amazon RDS, modificare l'istanza database o il cluster database multi-AZ in modo che non utilizzi una classe di istanza database che supporti la funzionalità. ## Monitoraggio delle istanze database che utilizzano RDS Optimized Reads Puoi monitorare le istanze database che utilizzano RDS Optimized Reads con le seguenti metriche di CloudWatch: + `FreeLocalStorage` + `ReadIOPSLocalStorage` + `ReadLatencyLocalStorage` + `ReadThroughputLocalStorage` + `WriteIOPSLocalStorage` + `WriteLatencyLocalStorage` + `WriteThroughputLocalStorage` Queste metriche forniscono dati sullo spazio di archiviazione dell'archivio dell'istanza, sulle operazioni IOPS e sulla velocità di trasmissione effettiva disponibili. Per ulteriori informazioni su questi parametri, consulta [Parametri a CloudWatch livello di istanza Amazon per Amazon RDS](rds-metrics.md#rds-cw-metrics-instance). ## Limitazioni per RDS Optimized Reads Le seguenti limitazioni si applicano a RDS Optimized Reads: + RDS Optimized Reads è supportato per le seguenti versioni: + RDS per MySQL versione 8.0.28 e versioni principali e secondarie successive Per ulteriori informazioni sulle versioni di RDS per MySQL, consulta [Versioni di MySQL in Amazon RDS](MySQL.Concepts.VersionMgmt.md). + Non è possibile modificare la posizione degli oggetti temporanei nell'archivio persistente (Amazon EBS) nelle classi di istanza database che supportano RDS Optimized Reads. + Quando i log binari sono abilitati su un'istanza database, la dimensione massima della transazione è limitata alla dimensione dell'archivio dell'istanza. In MySQL, qualsiasi sessione che richiede più spazio di archiviazione rispetto al valore `binlog_cache_size` scrive le modifiche della transazione nei file di cache binlog temporanei, che vengono creati nell'archivio dell'istanza. + Le transazioni possono non riuscire quando l'archivio dell'istanza è pieno. # Prestazioni di scrittura migliorate con Scritture ottimizzate per Amazon RDS per MySQL Puoi migliorare le prestazioni delle transazioni di scrittura con Scritture ottimizzate per RDS per MySQL. Quando il database RDS per MySQL utilizza RDS Optimized Writes, può raggiungere una velocità di trasmissione effettiva delle transazioni di scrittura fino a due volte superiore. **Topics** + [ ## Panoramica di RDS Optimized Writes ](#rds-optimized-writes-overview) + [ ## Utilizzo di RDS Optimized Writes ](#rds-optimized-writes-using) + [ ## Abilitazione delle scritture ottimizzate per RDS in un database esistente ](#rds-optimized-writes-modify-enable) + [ ## Limitazioni per RDS Optimized Writes ](#rds-optimized-writes-limitations) ## Panoramica di RDS Optimized Writes Quando attivi Scritture ottimizzate per RDS, i database RDS per MySQL scrivono solo una volta, quando trasferiscono i dati nell'archiviazione durevole senza la necessità del buffer di doppia scrittura. I database continuano a fornire le protezioni delle proprietà ACID per le transazioni di database affidabili, insieme alle prestazioni migliorate. I database relazionali, come MySQL, forniscono le *proprietà ACID* di atomicità, consistenza, isolamento e durabilità per le transazioni di database affidabili. Per fornire queste proprietà, MySQL utilizza un'area di archiviazione di dati chiamata *buffer di doppia scrittura* che impedisce gli errori di scrittura parziale della pagina. Questi errori si verificano nel caso di un guasto hardware mentre il database sta aggiornando una pagina, ad esempio in caso di interruzione dell'alimentazione. Un database MySQL può rilevare le scritture parziali della pagina e recuperarle con una copia della pagina nel buffer di doppia scrittura. Sebbene questa tecnica fornisca protezione, comporta anche operazioni di scrittura aggiuntive. Per ulteriori informazioni sul buffer di doppia scrittura MySQL, consulta [Doublewrite Buffer](https://dev.mysql.com/doc/refman/8.0/en/innodb-doublewrite-buffer.html) (Buffer di doppia scrittura) nella documentazione di MySQL. Quando attivi RDS Optimized Writes, i database RDS per MySQL scrivono una sola volta, quando trasferiscono i dati nell'archiviazione durevole senza usare il buffer di doppia scrittura. RDS Optimized Writes è utile se esegui carichi di lavoro intensivi in scrittura sui database RDS per MySQL. Esempi di database con carichi di lavoro intensivi in scrittura includono quelli che supportano pagamenti digitali, trading finanziario e applicazioni di gioco. Questi database vengono eseguiti su classi di istanze DB che utilizzano il sistema AWS Nitro. Grazie alla configurazione hardware di questi sistemi, il database può scrivere pagine da 16 KiB direttamente su file di dati in modo affidabile e durevole in un solo passaggio. Il sistema AWS Nitro rende possibili le scritture ottimizzate per RDS. Puoi impostare il nuovo parametro di database `rds.optimized_writes` per controllare la funzionalità RDS Optimized Writes per i database RDS per MySQL. Accedi a questo parametro nei gruppi di parametri database di RDS per MySQL versione 8.0 e RDS per MySQL versione 8.4. Imposta il parametro su uno dei seguenti valori: + `AUTO` - Attiva RDS Optimized Writes se la funzionalità è supportata dal database. In caso contrario, disattiva RDS Optimized Writes. Questa è l'impostazione di default. + `OFF` - Disattiva RDS Optimized Writes anche la funzionalità è supportata dal database. Se disponi di un database esistente con una versione del motore, una classe di istanza DB, and/or file system format that doesn't support RDS Optimized Writes, you can enable the feature by creating a blue/green una distribuzione. Per ulteriori informazioni, consulta [Abilitazione delle scritture ottimizzate per RDS in un database esistente](#rds-optimized-writes-modify-enable). Se si esegue la migrazione di un database RDS per MySQL configurato per utilizzare RDS Optimized Writes in una classe di istanza database che non supporta la funzionalità, RDS disattiva automaticamente RDS Optimized Writes per il database. Quando la funzionalità RDS Optimized Writes è disattivata, il database utilizza il buffer di doppia scrittura MySQL. Per determinare se un database RDS per MySQL utilizza RDS Optimized Writes, osserva il valore corrente del parametro `innodb_doublewrite` per il database. Se il database utilizza RDS Optimized Writes, questo parametro è impostato su `FALSE` (`0`). ## Utilizzo di RDS Optimized Writes Puoi attivare RDS Optimized Writes quando crei un database RDS for MySQL con la console RDS, o l'API RDS. AWS CLI La funzionalità RDS Optimized Writes viene attivata automaticamente quando si verificano entrambe le seguenti condizioni durante la creazione del database: + Si specificano una versione del motore di database e una classe di istanza database che supportano RDS Optimized Writes. + RDS Optimized Writes è supportato per RDS per MySQL versione 8.0.30 e successive. Per ulteriori informazioni sulle versioni di RDS per MySQL, consulta [Versioni di MySQL in Amazon RDS](MySQL.Concepts.VersionMgmt.md). + La funzionalità RDS Optimized Writes è supportata per i database RDS per MySQL che utilizzano le seguenti classi di istanza database: + db.m7i + db.m7g + db.m6g + db.m6gd + db.m6i + db.m5 + db.m5d + db.r7i + db.r7g + db.r6g + db.r6gd + db.r6i + db.r5 + db.r5b + db.r5d + db.x2idn + db.x2iedn Per informazioni sulle classi di istanza database, consulta [Classi di istanze DB ](Concepts.DBInstanceClass.md). La disponibilità delle classi di istanze DB è diversa per. Regioni AWS Per determinare se una classe di istanza DB è supportata in una determinata istanza Regione AWS, consulta[Determinazione del supporto della classe di istanze DB in Regioni AWS](Concepts.DBInstanceClass.RegionSupport.md). Per aggiornare il database a una classe di istanza DB che supporti RDS Optimized Writes, puoi creare una blue/green distribuzione. Per ulteriori informazioni, consulta [Abilitazione delle scritture ottimizzate per RDS in un database esistente](#rds-optimized-writes-modify-enable). + Nel gruppo di parametri associato al database, il parametro `rds.optimized_writes` è impostato su `AUTO`. Nei gruppi di parametri predefiniti, questo parametro è sempre impostato su `AUTO`. Se vuoi utilizzare una versione del motore di database e una classe di istanza database che supportino Scritture ottimizzate per Amazon RDS, senza usare questa funzionalità, specifica un gruppo di parametri personalizzato durante la creazione del database. In questo gruppo di parametri, imposta il parametro `rds.optimized_writes` su `OFF`. Se si desidera che il database utilizzi RDS Optimized Writes in un secondo momento, è possibile impostare il parametro su `AUTO` per attivarlo. Per informazioni sull'utilizzo dei gruppi di parametri personalizzati e sull'impostazione dei parametri, consulta [Gruppi di parametri per Amazon RDS](USER_WorkingWithParamGroups.md). Per informazioni sulla creazione di un'istanza database, consulta [Creazione di un'istanza database Amazon RDS](USER_CreateDBInstance.md). ### Console Quando usi la console RDS per creare un database RDS per MySQL, puoi filtrare le versioni del motore di database e le classi di istanza database che supportano RDS Optimized Writes. Dopo aver attivato i filtri, puoi scegliere tra le versioni del motore di database e le classi di istanza database disponibili. Per scegliere una versione del motore di database che supporti RDS Optimized Writes, filtra le versioni del motore di database RDS per MySQL che supportano la funzionalità in **Engine version** (Versione del motore), quindi scegli una versione. ![\[La sezione Opzioni motore con il filtro Scritture ottimizzate per Amazon RDS attivato per Versione motore.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/images/rds-optimized-writes-version-filter.png) Nella sezione **Instance configuration** (Configurazione dell'istanza), filtra le classi di istanza database che supportano RDS Optimized Writes, quindi scegli una classe di istanza database. ![\[La sezione Configurazione dell’istanza con il filtro Scritture ottimizzate per Amazon RDS attivato per Classe dell’istanza DB.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/images/rds-optimized-writes-class-filter.png) Dopo aver effettuato queste selezioni, puoi scegliere altre impostazioni che soddisfano i tuoi requisiti e completare la creazione del database RDS per MySQL con la console. ### AWS CLI Per creare un'istanza DB utilizzando AWS CLI, esegui il [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)comando. Assicurati che i valori `--engine-version` e `--db-instance-class` supportino RDS Optimized Writes. Inoltre, assicurati che il gruppo di parametri associato all'istanza database abbia il parametro `rds.optimized_writes` impostato su `AUTO`. Questo esempio associa il gruppo di parametri predefinito all'istanza database. **Example Creazione di un'istanza database che utilizza RDS Optimized Writes** Per Linux, macOS o Unix: ``` 1. aws rds create-db-instance \ 2. --db-instance-identifier mydbinstance \ 3. --engine mysql \ 4. --engine-version 8.0.30 \ 5. --db-instance-class db.r5b.large \ 6. --manage-master-user-password \ 7. --master-username admin \ 8. --allocated-storage 200 ``` Per Windows: ``` 1. aws rds create-db-instance ^ 2. --db-instance-identifier mydbinstance ^ 3. --engine mysql ^ 4. --engine-version 8.0.30 ^ 5. --db-instance-class db.r5b.large ^ 6. --manage-master-user-password ^ 7. --master-username admin ^ 8. --allocated-storage 200 ``` ### API RDS È possibile creare un'istanza DB utilizzando l'DBInstanceoperazione [Create](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html). Quando utilizzi questa operazione, assicurati che i valori `EngineVersion` e `DBInstanceClass` supportino RDS Optimized Writes. Inoltre, assicurati che il gruppo di parametri associato all'istanza database abbia il parametro `rds.optimized_writes` impostato su `AUTO`. ## Abilitazione delle scritture ottimizzate per RDS in un database esistente Per modificare un database RDS per MySQL esistente per attivare Scritture ottimizzate per RDS, il database deve essere stato creato con una versione del motore di database e una classe di istanza database supportate. Inoltre, il database deve essere stato creato *dopo* il rilascio di Scritture ottimizzate per RDS del 27 novembre 2022, poiché la configurazione del file system sottostante richiesta è incompatibile con quella dei database creati prima del rilascio. Se queste condizioni sono soddisfatte, è possibile attivare Scritture ottimizzate per RDS impostando il parametro `rds.optimized_writes` su `AUTO`. Se il database *non* è stato creato con una versione del motore, una classe di istanza o una configurazione del file system supportata, è possibile utilizzare RDS Blue/Green Deployments per migrare a una configurazione supportata. Durante la creazione della blue/green distribuzione, procedi come segue: + Seleziona **Abilita le scritture ottimizzate sul database verde**, quindi specifica una versione del motore e una classe di istanza database che supportano e scritture ottimizzate RDS. Per l'elenco delle versioni di motore e delle classi di istanza supportate, consulta [Utilizzo di RDS Optimized Writes](#rds-optimized-writes-using). + In **Archiviazione** scegli **Aggiorna la configurazione del file system di archiviazione**. Questa opzione aggiorna il database a una configurazione del file system sottostante compatibile. Quando crei la blue/green distribuzione, se il `rds.optimized_writes` parametro è impostato su`AUTO`, RDS Optimized Writes verrà abilitato automaticamente nell'ambiente verde. È quindi possibile passare alla blue/green distribuzione, il che promuove l'ambiente verde come nuovo ambiente di produzione. Per ulteriori informazioni, consulta [Creazione di una blue/green distribuzione in Amazon RDS ](blue-green-deployments-creating.md). ## Limitazioni per RDS Optimized Writes Quando si ripristina un database RDS per MySQL da uno snapshot, è possibile attivare Scritture ottimizzate per RDS per il database solo se si verificano tutte le seguenti condizioni: + Lo snapshot è stato creato da un database che supporta RDS Optimized Writes. + Lo snapshot è stato creato da un database creato *dopo* il rilascio della funzionalità Scritture ottimizzate per Amazon RDS. + Lo snapshot è stato ripristinato in un database che supporta RDS Optimized Writes. + Il database ripristinato è associato a un gruppo di parametri con il parametro `rds.optimized_writes` impostato su `AUTO`. # Aggiornamenti del motore di database RDS per MySQL Quando Amazon RDS supporta una nuova versione di un motore di database, puoi effettuare l’aggiornamento delle istanze database alla nuova versione. Sono disponibili due tipi di aggiornamenti per i database MySQL: quelli a una versione principale e quelli a una versione secondaria. **Aggiornamenti a versioni principali** Gli *aggiornamenti di versione principali* possono contenere modifiche al database non compatibili con le versioni precedenti delle applicazioni esistenti. Ne risulta che è necessario eseguire manualmente gli aggiornamenti a versioni principali per le proprie istanze database. Puoi avviare manualmente un aggiornamento a una versione principale modificando l’istanza database. Prima di eseguire un aggiornamento a una versione principale, si consiglia di seguire le istruzioni presenti in [Aggiornamenti a versioni principali per RDS per MySQL](USER_UpgradeDBInstance.MySQL.Major.md). Per gli aggiornamenti a versioni principali delle implementazioni di istanze database Multi-AZ, Amazon RDS aggiorna contemporaneamente le repliche primarie e quelle di standby. L’istanza database potrebbe non essere disponibile fino al completamento dell’aggiornamento. Per gli aggiornamenti a versioni principali delle implementazioni di cluster di database Multi-AZ, Amazon RDS aggiorna le istanze che fanno parte del cluster una alla volta. È possibile ridurre al minimo i tempi di inattività necessari per l'aggiornamento di una versione principale utilizzando una blue/green distribuzione. Per ulteriori informazioni, consulta [Utilizzo di Amazon RDS Blue/Green Aurora Deployments per gli aggiornamenti del database](blue-green-deployments.md). **Aggiornamenti a versioni secondarie** *Gli aggiornamenti a versioni secondarie* includono solo modifiche compatibili con le versioni precedenti delle applicazioni esistenti. Puoi avviare un aggiornamento a una versione secondaria manualmente modificando la tua istanza database. In alternativa, è possibile abilitare l’opzione **Aggiornamento automatico versione secondaria** durante la creazione o la modifica di un’istanza database. Ciò significa che l’istanza database viene automaticamente aggiornata dopo che Amazon RDS testa e approva la nuova versione. Per informazioni sull’esecuzione di un aggiornamento, consulta [Aggiornamento della versione del motore di di un'istanza database](USER_UpgradeDBInstance.Upgrading.md). Quando esegui l’aggiornamento a una versione secondaria di un cluster di database Multi-AZ, Amazon RDS aggiorna le istanze database di lettura una alla volta. Successivamente, una delle istanze database di lettura diventa la nuova istanza database di scrittura. Amazon RDS aggiorna quindi la vecchia istanza di scrittura (che ora è un’istanza di lettura). Il tempo di inattività per un aggiornamento a una versione secondaria di un’implementazione di un’*istanza* database Multi-AZ può durare diversi minuti. I cluster di database Multi-AZ in genere riducono i tempi di inattività degli aggiornamenti a versioni secondarie a circa 35 secondi. Se si utilizza Server proxy per RDS, il tempo di inattività si può ridurre ulteriormente fino a un secondo o meno. Per ulteriori informazioni, consulta [Proxy Amazon RDS ](rds-proxy.md). [In alternativa, è possibile utilizzare un proxy di database open source come [ProxySQL](https://aws.amazon.com/blogs/database/achieve-one-second-or-less-of-downtime-with-proxysql-when-upgrading-amazon-rds-multi-az-deployments-with-two-readable-standbys/) o Advanced JDBC [PgBouncer](https://aws.amazon.com/blogs/database/fast-switchovers-with-pgbouncer-on-amazon-rds-multi-az-deployments-with-two-readable-standbys-for-postgresql/)Wrapper Driver.AWS](https://aws.amazon.com/blogs/database/achieve-one-second-or-less-downtime-with-the-advanced-jdbc-wrapper-driver-when-upgrading-amazon-rds-multi-az-db-clusters/) Amazon RDS supporta anche la politica di implementazione degli aggiornamenti per gestire gli aggiornamenti automatici delle versioni secondarie su più risorse di database e. Account AWS Per ulteriori informazioni, consulta [Utilizzo della politica di implementazione degli AWS Organizations aggiornamenti per gli aggiornamenti automatici delle versioni secondarie](RDS.Maintenance.AMVU.UpgradeRollout.md). Se la tua istanza database MySQL sta utilizzando repliche di lettura, dovrai aggiornare tutte le repliche di lettura prima di aggiornare l’istanza di origine. **Topics** + [ ## Considerazioni relative agli aggiornamenti di MySQL ](#USER_UpgradeDBInstance.MySQL.Considerations) + [ ## Individuazione di destinazioni di aggiornamento valide ](#USER_UpgradeDBInstance.MySQL.FindingTargets) + [ # Numeri di versione di MySQL ](USER_UpgradeDBInstance.MySQL.VersionID.md) + [ # Numeri di versione RDS in RDS per MySQL ](USER_UpgradeDBInstance.MySQL.rds.version.md) + [ # Aggiornamenti a versioni principali per RDS per MySQL ](USER_UpgradeDBInstance.MySQL.Major.md) + [ # Test di un aggiornamento di RDS per MySQL ](USER_UpgradeDBInstance.MySQL.UpgradeTesting.md) + [ ## Aggiornamento di un'istanza database MySQL ](#USER_UpgradeDBInstance.MySQL.Upgrading) + [ # Aggiornamenti automatici a versioni secondarie per RDS per MySQL ](USER_UpgradeDBInstance.MySQL.Minor.md) + [ # Utilizzo di una replica di lettura per ridurre i tempi di inattività durante l’aggiornamento di un database RDS per MySQL ](USER_UpgradeDBInstance.MySQL.ReducedDowntime.md) + [ # Monitoraggio degli aggiornamenti del motore RDS per MySQL con eventi ](USER_UpgradeDBInstance.MySQL.Monitoring.md) ## Considerazioni relative agli aggiornamenti di MySQL Durante il processo di aggiornamento, Amazon RDS acquisisce due o più istantanee DB. Amazon RDS richiede fino a due istantanee dell'istanza database *prima di apportare modifiche* all'aggiornamento. Se l'aggiornamento non funziona per i database, puoi ripristinare una di queste istantanee per creare un'istanza database che esegue la versione precedente. Amazon RDS acquisisce un'altra istantanea dell'istanza database al termine dell'aggiornamento. Amazon RDS acquisisce queste istantanee indipendentemente dal fatto che AWS Backup gestisca o meno i backup per l'istanza DB. **Nota** Amazon RDS acquisisce gli snapshot DB solo se hai impostato il periodo di retention dei backup per l’istanza database su un valore maggiore di 0. Per cambiare il periodo di retention dei backup, consulta [Modifica di un'istanza database Amazon RDS](Overview.DBInstance.Modifying.md). Al termine dell'aggiornamento, non puoi ripristinare la versione precedente del motore di database. Se desideri tornare alla versione precedente, ripristina il primo snapshot DB acquisito per creare una nuova istanza database. Puoi controllare quando eseguire l'aggiornamento dell'istanza database a una nuova versione supportata da Amazon RDS. Questo livello di controllo ti consente di mantenere la compatibilità con versioni di database specifiche e testare le nuove versioni con l'applicazione prima di distribuirle in produzione. Puoi aggiornare le versioni quando più appropriato in base alla tua pianificazione. Se la tua istanza database utilizza una replica di lettura, devi aggiornare tutte le repliche di lettura prima di aggiornare l’istanza di origine. ## Individuazione di destinazioni di aggiornamento valide Quando si utilizza Console di gestione AWS per aggiornare un'istanza DB, mostra gli obiettivi di aggiornamento validi per l'istanza DB. È inoltre possibile eseguire il AWS CLI comando seguente per identificare gli obiettivi di aggiornamento validi per un'istanza DB: Per Linux, macOS o Unix: ``` aws rds describe-db-engine-versions \ --engine mysql \ --engine-version version_number \ --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text ``` Per Windows: ``` aws rds describe-db-engine-versions ^ --engine mysql ^ --engine-version version_number ^ --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text ``` Ad esempio, per identificare gli obiettivi di aggiornamento validi per un'istanza DB MySQL versione 8.0.28, esegui il comando seguente: AWS CLI Per Linux, macOS o Unix: ``` aws rds describe-db-engine-versions \ --engine mysql \ --engine-version 8.0.28 \ --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text ``` Per Windows: ``` aws rds describe-db-engine-versions ^ --engine mysql ^ --engine-version 8.0.28 ^ --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text ``` # Numeri di versione di MySQL La sequenza di numerazione delle versioni per il motore di database RDS per MySQL è indicata come *principale.secondaria.patch.AAAAMMGG* o *principale.secondaria.patch*, ad esempio 8.0.33.R2.20231201 o 5.7.44. Il formato utilizzato dipende dalla versione del motore MySQL. Per informazioni sulla numerazione delle versioni del supporto esteso per RDS, consulta [Denominazione delle versioni nell’ambito del supporto esteso per Amazon RDS](extended-support-versions.md#extended-support-naming). **principale** Il numero di versione principale è costituito dal numero intero e dalla prima parte frazionaria del numero di versione, ad esempio 8.0. Un aggiornamento a una versione principale incrementa la parte principale del numero di versione. Ad esempio, un aggiornamento da *5.7*.44 a 8.0.33 è un aggiornamento della versione principale, in cui *5.7* e *8.0* sono i numeri delle versioni principali. **secondaria** Il numero di versione secondaria è la terza parte del numero di versione, ad esempio il numero 33 in 8.0.33. **patch** La patch è la quarta parte del numero di versione, ad esempio R2 in 8.0.33.R2. Una versione della patch di RDS include importanti correzioni di bug aggiunte a una versione secondaria dopo il rilascio. **AAAAMMGG** La data è la quinta parte del numero di versione, ad esempio 20231201 in 8.0.33.R2.20231201. Una versione con data di RDS è una patch di sicurezza che include importanti correzioni di sicurezza aggiunte a una versione secondaria dopo il rilascio, senza includere correzioni che potrebbero modificare il comportamento del motore. La tabella seguente spiega lo schema di denominazione per RDS per MySQL versione 8.4. | Versione secondaria 8.4 | Schema di denominazione | | --- | --- | | ≥ 3 | Le nuove istanze database utilizzano *principale.secondaria.patch.AAMMGG*, ad esempio 8.4.3.R2.20241201. Le istanze database esistenti potrebbero utilizzare *principale.secondaria.patch*, ad esempio 8.4.3.R2, fino al successivo aggiornamento a una versione principale o secondaria. | La tabella seguente spiega lo schema di denominazione per RDS per MySQL versione 8.0. | Versione secondaria 8.0 | Schema di denominazione | | --- | --- | | ≥ 33 | Le nuove istanze database utilizzano *principale.secondaria.patch.AAMMGG*, ad esempio 8.0.33.R2.20231201. Le istanze database esistenti potrebbero utilizzare *principale.secondaria.patch*, ad esempio 8.0.33.R2, fino al successivo aggiornamento a una versione principale o secondaria. | | < 33 | Le istanze database esistenti utilizzano *principale.secondaria.patch*, ad esempio 8.0.32.R2. | La tabella seguente spiega lo schema di denominazione per RDS per MySQL versione 5.7. | Versione secondaria 5.7 | Schema di denominazione | | --- | --- | | ≥ 42 | Le nuove istanze database utilizzano *principale.secondaria.patch.AAMMGG*, ad esempio 5.7.42.R2.20231201. Le istanze database esistenti potrebbero utilizzare *principale.secondaria.patch*, ad esempio 5.7.42.R2, fino al successivo aggiornamento a una versione principale o secondaria. | # Numeri di versione RDS in RDS per MySQL I numeri di versione RDS utilizzano `major.minor.patch` o lo schema di denominazione `major.minor.patch.YYYYMMDD`. Le versioni di Amazon RDS Extended Support utilizzano lo schema di denominazione delle versioni *minor-RDS.YYYYMMDD* secondarie. Una versione della patch di RDS include importanti correzioni di bug aggiunte a una versione secondaria dopo il rilascio. Una versione con data RDS (*YYYYMMDD*) è una patch di sicurezza. Una patch di sicurezza non include correzioni che potrebbero modificare il comportamento del motore. Per informazioni sulla numerazione delle versioni del supporto esteso per RDS, consulta [Denominazione delle versioni nell’ambito del supporto esteso per Amazon RDS](extended-support-versions.md#extended-support-naming). Puoi trovare il numero di versione RDS del tuo database RDS per MySQL con la seguente query SQL: ``` mysql> select mysql.rds_version(); ``` Ad esempio, l’esecuzione di una query su un database RDS per MySQL 8.0.34 restituisce il seguente output: ``` +---------------------+ | mysql.rds_version() | +---------------------+ | 8.0.34.R2.20231201 | +---------------------+ 1 row in set (0.01 sec) ``` # Aggiornamenti a versioni principali per RDS per MySQL Amazon RDS supporta i seguenti aggiornamenti in loco per le versioni principali del motore di database MySQL: + Da MySQL 5.7 a MySQL 8.0 + Da MySQL 8.0 a MySQL 8.4 **Nota** Puoi creare istanze database MySQL versione 5.7, 8.0 e 8.4 con classi di istanze database della generazione corrente e dell’ultima generazione In alcuni casi, potresti voler aggiornare un’istanza database in esecuzione su una classe di istanza database di generazione precedente in un’istanza database con versione del motore MySQL superiore. In questi casi, modifica innanzitutto l'istanza database per utilizzare una classe di istanza database di ultima generazione o generazione corrente. Dopo aver effettuato questa operazione, puoi modificare l’istanza database affinché utilizzi la versione del motore di database MySQL con versione successiva. Per informazioni sulle classi di istanza database Amazon RDS, consulta [Classi di istanze DB ](Concepts.DBInstanceClass.md). **Topics** + [ ## Panoramica degli aggiornamenti di una versione principale di MySQL ](#USER_UpgradeDBInstance.MySQL.Major.Overview) + [ ## Controlli preliminari per gli aggiornamenti ](#USER_UpgradeDBInstance.MySQL.Prechecks) + [ ## Rollback dopo il mancato aggiornamento ](#USER_UpgradeDBInstance.MySQL.Major.RollbackAfterFailure) ## Panoramica degli aggiornamenti di una versione principale di MySQL Gli aggiornamenti a versioni principali possono contenere modifiche al database non compatibili con le versioni precedenti delle applicazioni esistenti. Di conseguenza, Amazon RDS non applica automaticamente gli aggiornamenti di versioni principale; devi modificare l'istanza database manualmente. Ti raccomandiamo di eseguire un test approfondito di qualsiasi aggiornamento prima di applicarlo alle istanze di produzione. Per eseguire un aggiornamento a una versione principale, esegui prima gli aggiornamenti del sistema operativo disponibili. Al termine degli aggiornamenti del sistema operativo, esegui l’aggiornamento a ogni versione principale: da 5.7 a 8.0 e quindi da 8.0 a 8.4. Per informazioni sull’aggiornamento di un cluster di database Multi-AZ RDS per MySQL, consulta [Aggiornamento della versione del motore di un cluster di database Multi-AZ per Amazon RDS](multi-az-db-clusters-upgrading.md). Le istanze database MySQL create prima del 24 aprile 2014 indicano la disponibilità di un aggiornamento del sistema operativo fino a quando l'aggiornamento non viene applicato. Per ulteriori informazioni sugli aggiornamenti del sistema operativo, consulta [Applicazione degli aggiornamenti a un di istanze DB](USER_UpgradeDBInstance.Maintenance.md#USER_UpgradeDBInstance.OSUpgrades). Durante un aggiornamento della versione principale di MySQL, Amazon RDS esegue il file binario `mysql_upgrade` di MySQL per aggiornare le tabelle, se necessario. Amazon RDS svuota inoltre le tabelle `slow_log` e `general_log` durante un aggiornamento della versione principale. Per conservare le informazioni di log, salva il contenuto dei log prima dell'aggiornamento di versione principale. Gli aggiornamenti di versione principale di MySQL sono in genere completati nel giro di 10 minuti. Alcuni aggiornamenti possono richiedere più tempo a causa della dimensione della classe di istanza database o perché l'istanza non segue determinate linee guida operative descritte in [Best practice per Amazon RDS](CHAP_BestPractices.md). Se aggiorni un'istanza database dalla console di Amazon RDS, lo stato dell'istanza database indica quando l'aggiornamento è terminato. Se esegui l'aggiornamento utilizzando AWS Command Line Interface (AWS CLI), usa il [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html)comando e controlla il `Status` valore. ## Controlli preliminari per gli aggiornamenti Amazon RDS esegue controlli preliminari prima dell’aggiornamento per verificare eventuali incompatibilità. Queste incompatibilità variano in base alla versione di MySQL a cui viene eseguito l’aggiornamento. I controlli preliminari comprendono alcuni controlli inclusi in MySQL e alcuni che sono stati creati specificamente dal team Amazon RDS. Per informazioni sui controlli preliminari forniti da MySQL, consultare [Utility di controllo aggiornamenti](https://dev.mysql.com/doc/mysql-shell/8.4/en/mysql-shell-utilities-upgrade.html). I controlli preliminari vengono eseguiti prima dell'arresto dell'istanza database per l'aggiornamento, il che significa che non generano alcun tempo di inattività durante l'esecuzione. Se i controlli preliminari rilevano un'incompatibilità, Amazon RDS annulla automaticamente l'aggiornamento prima che l'istanza database venga arrestata. Amazon RDS genera anche un evento per l'incompatibilità. Per ulteriori informazioni sugli eventi di Amazon RDS, consulta [Utilizzo della notifica degli eventi di Amazon RDS](USER_Events.md). Amazon RDS memorizza le informazioni dettagliate su ciascuna incompatibilità nel file di log `PrePatchCompatibility.log`. Nella maggior parte dei casi, la voce di log include un collegamento alla documentazione MySQL utile per correggere l'incompatibilità. Per ulteriori informazioni sulla visualizzazione dei file di log, consultare [Visualizzazione ed elenco dei file di log del database](USER_LogAccess.Procedural.Viewing.md). A causa della natura dei controlli preliminari, questi analizzano gli oggetti nel database. Questa analisi comporta il consumo di risorse e incrementa il tempo di completamento dell'aggiornamento. **Topics** + [ ### Controlli preliminari per aggiornamenti da MySQL 8.0 a 8.4 ](#USER_UpgradeDBInstance.MySQL.80to84Prechecks) + [ ### Controlli preliminari per aggiornamenti da MySQL 5.7 a 8.0 ](#USER_UpgradeDBInstance.MySQL.57to80Prechecks) ### Controlli preliminari per aggiornamenti da MySQL 8.0 a 8.4 MySQL 8.4 include una serie di incompatibilità con MySQL 8.0. Queste incompatibilità possono causare problemi durante l’aggiornamento da MySQL 8.0 a MySQL 8.4. Pertanto, potrebbe essere necessaria una specifica preparazione del database affinché l’aggiornamento possa concludersi correttamente. Di seguito è riportato un elenco generale di queste incompatibilità: + Non devono essere presenti tabelle che utilizzano tipi di dati o funzioni obsolete. + I trigger non devono avere un definer mancante o vuoto oppure un contesto di creazione non valido. + Non devono essere presenti violazioni di parole chiave o parole riservate. Alcune parole chiave, che non erano riservate in precedenza, possono essere riservate in MySQL 8.4. Per ulteriori informazioni, consulta [Keywords and Reserved Words](https://dev.mysql.com/doc/refman/8.4/en/keywords.html) nella documentazione MySQL. + Nel database di sistema MySQL `mysql` 8.0 non devono esserci tabelle con lo stesso nome di una tabella utilizzata dal dizionario dati MySQL 8.4. + Non devono esistere modalità SQL obsolete definite nell’impostazione della variabile di sistema `sql_mode`. + Non devono essere presenti tabelle o stored procedure con singoli elementi di colonna `ENUM` o `SET` la cui lunghezza è superiore a 255 caratteri o 1020 byte. + L’installazione MySQL 8.0 non deve utilizzare funzionalità che non sono supportate in MySQL 8.4. Per ulteriori informazioni, consulta [Funzionalità rimosse in MySQL 8.4 nella documentazione di MySQL](https://dev.mysql.com/doc/refman/8.4/en/mysql-nutshell.html#mysql-nutshell-removals). + Non devono essere presenti nomi di vincoli della chiave più lunghi di 64 caratteri. + Per un supporto Unicode migliorato, consulta le informazioni riportate di seguito: + Valuta la conversione di oggetti che utilizzano il set di caratteri `utf8mb3` per utilizzare il set di caratteri `utf8mb4`. Il set di caratteri `utf8mb3` è obsoleto. + Valuta l’utilizzo di `utf8mb4` per i riferimenti al set di caratteri anziché `utf8`, perché attualmente `utf8` è un’alias per il set di caratteri `utf8mb3`. Se possibile, modifica innanzitutto `utf8` in `utf8mb4` e poi aggiorna il database. + Poiché i client meno recenti possono ricevere un errore di set di caratteri sconosciuto per `utf8mb3`, aggiorna i client del database prima di aggiornare il database. Per ulteriori informazioni, consulta [ The utf8mb3 Character Set (3-Byte UTF-8 Unicode Encoding)](https://dev.mysql.com/doc/refman/8.4/en/charset-unicode-utf8mb3.html) nella documentazione MySQL. Per modificare i set di caratteri, è possibile eseguire manualmente un backup, un ripristino e una replica del database. Oppure puoi usare Amazon RDS Blue/Green Deployments. Per ulteriori informazioni, consulta [Utilizzo di Amazon RDS Blue/Green Aurora Deployments per gli aggiornamenti del database](blue-green-deployments.md). Quando avvii un aggiornamento da MySQL 8.0 a 8.4, Amazon RDS esegue automaticamente dei controlli preliminari per rilevare queste incompatibilità. Per informazioni sull’aggiornamento a MySQL 8.4, consulta [Upgrading MySQL](https://dev.mysql.com/doc/refman/8.4/en/upgrading.html) nella documentazione di MySQL. Questi controlli preliminari sono obbligatori. Non puoi scegliere di saltarli. I controlli preliminari offrono i seguenti vantaggi: + Ti consentono di evitare tempi di inattività non pianificati durante l'aggiornamento. + Se sono presenti incompatibilità, Amazon RDS impedisce l’aggiornamento e fornisce un log per ottenere informazioni sulle stesse. È quindi possibile utilizzare il registro per preparare il database per l'aggiornamento a MySQL 8.4 riducendo le incompatibilità. Per informazioni dettagliate sulla rimozione di eventuali incompatibilità, consulta [Preparazione dell’installazione per l’aggiornamento](https://dev.mysql.com/doc/refman/8.4/en/upgrade-prerequisites.html) nella documentazione di MySQL. ### Controlli preliminari per aggiornamenti da MySQL 5.7 a 8.0 MySQL 8.0 include un certo numero di incompatibilità con MySQL 5.7. Queste incompatibilità possono causare problemi durante l'aggiornamento da MySQL 5.7 a MySQL 8.0. Pertanto, potrebbe essere necessaria una specifica preparazione del database affinché l’aggiornamento possa concludersi correttamente. Di seguito è riportato un elenco generale di queste incompatibilità: + Non devono essere presenti tabelle che utilizzano tipi di dati o funzioni obsolete. + Non devono esistere file \$1.frm orfani. + I trigger non devono avere un definer mancante o vuoto oppure un contesto di creazione non valido. + Non devono essere presenti tabelle partizionate che utilizzano un motore di storage che non dispone di supporto di partizionamento nativo. + Non devono essere presenti violazioni di parole chiave o parole riservate. Alcune parole chiave, che non erano riservate in precedenza, possono essere riservate in MySQL 8.0. Per ulteriori informazioni, consulta [Keywords and Reserved Words](https://dev.mysql.com/doc/refman/8.0/en/keywords.html) nella documentazione MySQL. + Non devono essere presenti tabelle nel database di sistema MySQL 5.7 `mysql` che hanno lo stesso nome di una tabella utilizzata dal dizionario dati MySQL 8.0. + Non devono esistere modalità SQL obsolete definite nell’impostazione della variabile di sistema `sql_mode`. + Non devono essere presenti tabelle o stored procedure con singoli elementi di colonna `ENUM` o `SET` la cui lunghezza è superiore a 255 caratteri o 1020 byte. + Prima dell'aggiornamento a MySQL 8.0.13 o versioni successive, non devono esistere partizioni di tabella che risiedono in spazi tabelle InnoDB condivisi. + Non devono essere presenti definizioni di query e di programmi archiviati da MySQL 8.0.12 o versione inferiore che utilizzano qualificatori `ASC` o `DESC` per clausole `GROUP BY`. + L'installazione MySQL 5.7 non deve utilizzare caratteristiche che non sono supportate in MySQL 8.0. Per ulteriori informazioni, consulta [ Features Removed in MySQL 8.0](https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html#mysql-nutshell-removals) nella documentazione MySQL. + Non devono essere presenti nomi di vincoli della chiave più lunghi di 64 caratteri. + Per un supporto Unicode migliorato, consulta le informazioni riportate di seguito: + Valuta la conversione di oggetti che utilizzano il set di caratteri `utf8mb3` per utilizzare il set di caratteri `utf8mb4`. Il set di caratteri `utf8mb3` è obsoleto. + Valuta l’utilizzo di `utf8mb4` per i riferimenti al set di caratteri anziché `utf8`, perché attualmente `utf8` è un’alias per il set di caratteri `utf8mb3`. Se possibile, modifica innanzitutto `utf8` in `utf8mb4` e poi aggiorna il database. + Poiché i client meno recenti possono ricevere un errore di set di caratteri sconosciuto per `utf8mb3`, aggiorna i client del database prima di aggiornare il database. Per ulteriori informazioni, consulta [ The utf8mb3 Character Set (3-Byte UTF-8 Unicode Encoding)](https://dev.mysql.com/doc/refman/8.4/en/charset-unicode-utf8mb3.html) nella documentazione MySQL. Per modificare i set di caratteri, è possibile eseguire manualmente un backup, un ripristino e una replica del database. Oppure puoi usare Amazon RDS Blue/Green Deployments. Per ulteriori informazioni, consulta [Utilizzo di Amazon RDS Blue/Green Aurora Deployments per gli aggiornamenti del database](blue-green-deployments.md). Quando avvii un aggiornamento da MySQL 5.7 a 8.0, Amazon RDS esegue automaticamente dei controlli preliminari per rilevare queste incompatibilità. Per informazioni sull'aggiornamento a MySQL 8.0, consulta [Upgrading MySQL](https://dev.mysql.com/doc/refman/8.0/en/upgrading.html) nella documentazione MySQL. Questi controlli preliminari sono obbligatori. Non puoi scegliere di saltarli. I controlli preliminari offrono i seguenti vantaggi: + Ti consentono di evitare tempi di inattività non pianificati durante l'aggiornamento. + Se sono presenti incompatibilità, Amazon RDS impedisce l’aggiornamento e fornisce un log per ottenere informazioni sulle stesse. Puoi quindi utilizzare il log per preparare il database per l'aggiornamento a MySQL 8.0 riducendo le incompatibilità. Per informazioni dettagliate sulla rimozione di incompatibilità, consulta l'argomento relativo alla [preparazione dell'installazione per l'aggiornamento](https://dev.mysql.com/doc/refman/8.0/en/upgrade-prerequisites.html) nella documentazione di MySQL e il post relativo alle [informazioni sull'aggiornamento di MySQL 8.0](https://dev.mysql.com/blog-archive/upgrading-to-mysql-8-0-here-is-what-you-need-to-know/) nel blog di MySQL Server. ## Rollback dopo il mancato aggiornamento Quando si aggiorna un’istanza database da MySQL versione 5.7 a MySQL versione 8.0 oppure da MySQL versione 8.0 a 8.4, l’aggiornamento può non andare a buon fine. In particolare, può fallire se il dizionario dati contiene incompatibilità che non sono state acquisite dai precontrolli. In questo caso, il database non viene avviato correttamente nella nuova versione di MySQL 8.0 o 8.4. A questo punto, Amazon RDS esegue il rollback delle modifiche eseguite per l'aggiornamento. Dopo il rollback, l’istanza database MySQL esegue la versione originale: + MySQL versione 8.0 (per un rollback da MySQL 8.4) + MySQL versione 5.7 (per un rollback da MySQL 8.0) Quando un aggiornamento non riesce e viene eseguito il rollback, Amazon RDS genera un evento con l'ID evento RDS-EVENT-0188. In genere, un aggiornamento non riesce perché ci sono incompatibilità nei metadati tra i database nell'istanza database e la versione di MySQL di destinazione. Quando un aggiornamento non riesce, è possibile visualizzare i dettagli su queste incompatibilità nel file `upgradeFailure.log`. Risolvere le incompatibilità prima di provare a eseguire nuovamente l'aggiornamento. Durante un tentativo di aggiornamento e rollback non riusciti, l'istanza database viene riavviata. Eventuali modifiche dei parametri in sospeso vengono applicate durante il riavvio e persistono dopo il rollback. Per ulteriori informazioni sull'aggiornamento a MySQL 8.0, consulta i seguenti argomenti nella documentazione di MySQL: + [Preparazione dell'installazione per l'aggiornamento](https://dev.mysql.com/doc/refman/8.0/en/upgrade-prerequisites.html) + [ Aggiornamento a MySQL 8.0? Ecco cosa devi sapere…](https://dev.mysql.com/blog-archive/upgrading-to-mysql-8-0-here-is-what-you-need-to-know/) Per ulteriori informazioni sull’aggiornamento a MySQL 8.4, consulta [Preparazione dell’installazione per l’aggiornamento](https://dev.mysql.com/doc/refman/8.4/en/upgrade-prerequisites.html) nella documentazione di MySQL. # Test di un aggiornamento di RDS per MySQL Prima di eseguire l'aggiornamento di una versione principale nell'istanza database, testa a fondo il database per verificarne la compatibilità con la nuova versione. Testa inoltre tutte le applicazioni che accedono al database per verificarne la compatibilità con la nuova versione. È consigliabile utilizzare la procedura seguente. **Per testare un aggiornamento di una versione principale** 1. Esaminare la documentazione dell'aggiornamento per la nuova versione del motore di database per verificare se vi sono problemi di compatibilità che potrebbero interessare il database o le applicazioni: + [Changes in MySQL 5.7 (Modifiche in MySQL 5.7)](http://dev.mysql.com/doc/refman/5.7/en/upgrading-from-previous-series.html) + [Changes in MySQL 8.0 (Modifiche in MySQL 8.0)](http://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html) + [Changes in MySQL 8.4](http://dev.mysql.com/doc/refman/8.4/en/upgrading-from-previous-series.html) 1. Se l'istanza database è un membro di un gruppo di parametri database personalizzato, crea un nuovo gruppo di parametri database con le impostazioni esistenti che sia compatibile con la nuova versione principale. Specifica il nuovo gruppo di parametri database quando aggiorni l'istanza di prova, di modo che il test dell'aggiornamento ne garantisca il corretto funzionamento. Per ulteriori informazioni sulla creazione di un gruppo di parametri database, consulta [Gruppi di parametri per Amazon RDS](USER_WorkingWithParamGroups.md). 1. Creare uno snapshot DB dell'istanza database da aggiornare. Per ulteriori informazioni, consulta [Creazione di uno snapshot del database per un’istanza database Single-AZ per Amazon RDS](USER_CreateSnapshot.md). 1. Ripristinare lo snapshot DB per creare una nuova istanza database di test. Per ulteriori informazioni, consulta [Ripristino in un’istanza database](USER_RestoreFromSnapshot.md). 1. Modificare la nuova istanza database di prova per aggiornarla alla nuova versione, utilizzando uno dei metodi descritti di seguito. Se è stato creato un nuovo gruppo di parametri nel passaggio 2, specificare quel gruppo di parametri. 1. Valutare lo storage utilizzato dall'istanza aggiornata per determinare se l'aggiornamento richiede storage aggiuntivo. 1. Eseguire quanti più test di controllo qualità possibili per l'istanza database aggiornata come necessario per assicurare che il database e l'applicazione funzionino correttamente con la nuova versione. Implementare qualsiasi nuovo test necessario per valutare l'impatto di problemi di compatibilità identificati nella fase 1. Testare tutte le stored procedure e le funzioni. Indirizzare le versioni di test delle applicazioni all'istanza database aggiornata. 1. Se tutti i test vengono superati, eseguire l'aggiornamento nell'istanza database di produzione. Consigliamo di non consentire le operazioni di scrittura sull'istanza database fino alla conferma che tutto funzioni correttamente. ## Aggiornamento di un'istanza database MySQL Per informazioni sull'aggiornamento manuale o automatico di un'istanza database MySQL, consulta [Aggiornamento della versione del motore di di un'istanza database](USER_UpgradeDBInstance.Upgrading.md). # Aggiornamenti automatici a versioni secondarie per RDS per MySQL Se specifichi le seguenti impostazioni durante la creazione o la modifica di un’istanza database, puoi decidere aggiornare automaticamente l’istanza database. + L'impostazione di **aggiornamento automatico della versione secondaria** deve essere attivata. + L’impostazione del **periodo di conservazione del backup** deve essere maggiore di 0. Nella Console di gestione AWS, queste impostazioni si trovano in **Additional configuration** (Configurazione aggiuntiva). L’immagine che segue mostra l’impostazione **Aggiornamento automatico versione secondaria**. ![\[Sezione Manutenzione con l’opzione Abilita aggiornamento automatico versione secondaria selezionata nella console Amazon RDS.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/images/amvu.png) Per ulteriori informazioni su queste impostazioni, consultare [Impostazioni per istanze database](USER_ModifyInstance.Settings.md). Per alcune versioni principali di RDS per MySQL in alcune Regioni AWS, una versione secondaria viene designata da RDS come versione di aggiornamento automatico. Una volta che una versione secondaria è stata testata e approvata da Amazon RDS, l’aggiornamento alla versione secondaria avviene automaticamente nel corso della finestra di manutenzione. RDS non imposta mai automaticamente le nuove release secondarie come versione di aggiornamento automatico. Prima che RDS indichi una versione di aggiornamento automatico più recente, vengono considerati diversi livelli di valutazione, quali: + Problemi di sicurezza noti + Bug nella versione della community di MySQL + Stabilità generale del parco istanze da quando la versione secondaria è stata rilasciata Puoi eseguire il comando AWS CLI seguente per determinare la versione di destinazione dell’aggiornamento secondario automatico corrente per una versione secondaria MySQL specificata in una Regione AWS specifica. Per Linux, macOS o Unix: ``` aws rds describe-db-engine-versions \ --engine mysql \ --engine-version minor_version \ --region region \ --query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" \ --output text ``` Per Windows: ``` aws rds describe-db-engine-versions ^ --engine mysql ^ --engine-version minor_version ^ --region region ^ --query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" ^ --output text ``` Ad esempio, il comando AWS CLI seguente determina la destinazione dell’aggiornamento secondario automatico per MySQL versione secondaria 8.0.11 nella Regione AWS Stati Uniti orientali (Ohio) (us-east-2). Per Linux, macOS o Unix: ``` aws rds describe-db-engine-versions \ --engine mysql \ --engine-version 8.0.11 \ --region us-east-2 \ --query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" \ --output table ``` Per Windows: ``` aws rds describe-db-engine-versions ^ --engine mysql ^ --engine-version 8.0.11 ^ --region us-east-2 ^ --query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" ^ --output table ``` L’output è simile a quello riportato di seguito. ``` ---------------------------------- | DescribeDBEngineVersions | +--------------+-----------------+ | AutoUpgrade | EngineVersion | +--------------+-----------------+ | False | 8.0.15 | | False | 8.0.16 | | False | 8.0.17 | | False | 8.0.19 | | False | 8.0.20 | | False | 8.0.21 | | True | 8.0.23 | | False | 8.0.25 | +--------------+-----------------+ ``` In questo esempio, il valore `AutoUpgrade` è `True` per MySQL versione 8.0.23. Quindi, il target di aggiornamento secondario automatico è MySQL versione 8.0.23, che è evidenziato nell’output. Un'istanza database MySQL viene aggiornata automaticamente durante la finestra di manutenzione se vengono soddisfatti i seguenti criteri: + L'impostazione di **aggiornamento automatico della versione secondaria** deve essere attivata. + L’impostazione del **periodo di conservazione del backup** deve essere maggiore di 0. + L'istanza database esegue una versione motore database minore rispetto a una versione minore automatica dell'aggiornamento corrente. Per ulteriori informazioni, consulta [Aggiornamento automatico della versione secondaria del motore](USER_UpgradeDBInstance.Upgrading.md#USER_UpgradeDBInstance.Upgrading.AutoMinorVersionUpgrades). # Utilizzo di una replica di lettura per ridurre i tempi di inattività durante l’aggiornamento di un database RDS per MySQL Nella maggior parte dei casi, un'implementazione blu/verde è l'opzione migliore per ridurre i tempi di inattività durante l'aggiornamento di un'istanza database MySQL. Per ulteriori informazioni, consulta [Utilizzo di Amazon RDS Blue/Green Aurora Deployments per gli aggiornamenti del database](blue-green-deployments.md). Se non è possibile utilizzare un'implementazione blu/verde e l'istanza database MySQL è attualmente in uso con un'applicazione di produzione, puoi seguire la seguente procedura per aggiornare la versione del database per l'istanza database. Questa procedura permette di ridurre i tempi di indisponibilità dell’applicazione. Utilizzando una replica di lettura, è possibile eseguire la maggior parte dei passaggi di manutenzione in anticipo e ridurre al minimo le modifiche necessarie durante l'interruzione effettiva. Con questa tecnica, è possibile testare e preparare la nuova istanza database senza apportare alcuna modifica all’istanza database esistente. La seguente procedura mostra un esempio di aggiornamento da MySQL versione 5.7 a MySQL versione 8.0. Puoi utilizzare la stessa procedura generale per gli aggiornamenti ad altre versioni principali. Puoi utilizzare la stessa procedura generale per gli aggiornamenti ad altre versioni principali. **Nota** Se esegui l’aggiornamento da MySQL versione 5.7 a MySQL versione 8.0, o da MySQL versione 8.0 a MySQL versione 8.4, completa i controlli preliminari prima di eseguire l’aggiornamento. Per ulteriori informazioni, consultare [Controlli preliminari per aggiornamenti da MySQL 5.7 a 8.0](USER_UpgradeDBInstance.MySQL.Major.md#USER_UpgradeDBInstance.MySQL.57to80Prechecks) e [Controlli preliminari per aggiornamenti da MySQL 8.0 a 8.4](USER_UpgradeDBInstance.MySQL.Major.md#USER_UpgradeDBInstance.MySQL.80to84Prechecks). **Per aggiornare un database MySQL con un'istanza database in uso** 1. Accedi alla Console di gestione AWS e apri la console Amazon RDS all’indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Crea una replica di lettura dell'istanza database MySQL 5.7. Questo processo crea una copia aggiornabile del database. Potrebbero esistere già presenti altre repliche di lettura dell'istanza database. 1. Nella console, seleziona **Database** e quindi l'istanza database da aggiornare. 1. Per **Actions (Operazioni)**, scegliere **Create read replica (Crea replica di lettura)**. 1. Specifica un valore per **Identificativo istanza DB** per la replica di lettura e assicurati che **Classe di istanza database** e altre impostazioni corrispondano all'istanza database MySQL 5.7. 1. Scegliere **Create read replica (Crea replica di lettura)**. 1. (Facoltativo) Una volta creata la replica di lettura e il campo **Stato** riporta **Disponibile**, converti la replica di lettura in una implementazione Multi-AZ e abilita i backup. Per impostazione predefinita, una replica di lettura viene creata con i backup disabilitati. Poiché la replica di lettura diventerà in definitiva l’istanza database di produzione, è opportuno configurare un’implementazione Multi-AZ e abilitare i backup. 1. Nella console, seleziona **Database**, quindi seleziona la replica di lettura appena creata. 1. Scegliere **Modify (Modifica)**. 1. Per **Implementazione Multi-AZ**, seleziona **Crea istanza di standby**. 1. In **Backup Retention Period** (Periodo di conservazione dei backup), seleziona un valore positivo diverso da zero, ad esempio 3 giorni, quindi scegli **Continue** (Continua). 1. In **Scheduling of Modifications (Pianificazione delle modifiche)**, scegliere **Apply immediately (Applica immediatamente)**. 1. Scegliere **Modify DB Instance (Modifica istanza database)**. 1. Quando il campo **Stato** della replica di lettura riporta **Disponibile**, aggiorna la replica di lettura a MySQL 8.0: 1. Nella console, seleziona **Database**, quindi seleziona la replica di lettura appena creata. 1. Scegliere **Modify (Modifica)**. 1. In **Versione motore database** seleziona la versione MySQL 8.0 da aggiornare, quindi scegli **Continua**. 1. In **Scheduling of Modifications (Pianificazione delle modifiche)**, scegliere **Apply immediately (Applica immediatamente)**. 1. Scegliere **Modify DB Instance (Modifica istanza database)** per avviare l’aggiornamento. 1. Al termine dell'aggiornamento, quando il campo **Stato** riporta **Disponibile**, verifica che la replica di lettura aggiornata sia sincronizzata con l'istanza database MySQL 5.7 di origine. Per verificare, connettiti alla replica di lettura ed esegui il comando `SHOW REPLICA STATUS`. Se il campo `Seconds_Behind_Master` vale `0`, la replica è sincronizzata. **Nota** Versioni precedenti di MySQL utilizzate `SHOW SLAVE STATUS` al posto di `SHOW REPLICA STATUS`. Se si utilizza una versione MySQL prima della 8.0.23, utilizzare `SHOW SLAVE STATUS`. 1. (Facoltativo) Crea una replica di lettura della replica di lettura. Se desideri che l'istanza database disponga di una replica di lettura dopo che è stata promossa a un'istanza database autonoma, puoi crearla in questo momento. 1. Nella console, seleziona **Database**, quindi scegli la replica di lettura appena aggiornata. 1. Per **Actions (Operazioni)**, scegliere **Create read replica (Crea replica di lettura)**. 1. Specifica un valore per **Identificativo istanza DB** per la replica di lettura e assicurati che **Classe di istanza database** e altre impostazioni corrispondano all'istanza database MySQL 5.7. 1. Scegliere **Create read replica (Crea replica di lettura)**. 1. (Facoltativo) Configura un gruppo di parametri database personalizzato per la replica di lettura. Se desideri che l'istanza database utilizzi un gruppo di parametri personalizzato dopo che è stato promossa a un'istanza database autonoma, puoi creare il gruppo e associarlo alla replica di lettura. 1. Crea un gruppo di parametri database personalizzato. Per istruzioni, consultare [Creazione di un gruppo di parametri database in Amazon RDS](USER_WorkingWithParamGroups.Creating.md). 1. Modifica i parametri che desideri modificare nel gruppo di parametri database appena creato. Per istruzioni, consultare [Modifica dei parametri in un gruppo di parametri database in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). 1. Nella console seleziona **Database**, quindi scegli la replica di lettura. 1. Scegliere **Modify (Modifica)**. 1. Per il **Gruppo di parametri database**, sceglie il gruppo di parametri database MySQL 8.0 appena creato, quindi scegli **Continua**. 1. In **Scheduling of Modifications (Pianificazione delle modifiche)**, scegliere **Apply immediately (Applica immediatamente)**. 1. Scegliere **Modify DB Instance (Modifica istanza database)** per avviare l’aggiornamento. 1. Converti la replica di lettura MySQL 8.0 in un'istanza DB autonoma. **Importante** Quando promuovi la replica di lettura MySQL 8.0 a un'istanza database autonoma, la replica non sarà più dell'istanza database MySQL 5.7. Ti consigliamo di promuovere la replica di lettura MySQL 8.0 durante una finestra di manutenzione quando l'istanza database MySQL 5.7 di origine è in modalità di sola lettura e tutte le operazioni di scrittura sono sospese. Al termine dell'operazione, è possibile indirizzare le operazioni di scrittura all'istanza database MySQL 8.0 aggiornata per evitare la perdita di qualsiasi operazione di scrittura. Inoltre, prima di promuovere la replica di lettura MySQL 8.0, ti consigliamo di eseguire tutte le operazioni DDL (Data Definition Language) necessarie sulla replica di lettura MySQL 8.0. Un esempio di tale operazione è la creazione degli indici. Questo approccio consente di evitare qualsiasi effetto negativo sulle prestazioni della replica di lettura MySQL 8.0 dopo la promozione. Per promuovere una replica di lettura, utilizzare la procedura seguente. 1. Nella console, seleziona **Database**, quindi scegli la replica di lettura appena aggiornata. 1. In **Actions** (Operazioni), seleziona **Promote** (Promuovi). 1. Scegliere **Yes (Sì)** per abilitare backup automatizzati per l'istanza della replica di lettura. Per ulteriori informazioni, consulta [Introduzione ai backup](USER_WorkingWithAutomatedBackups.md). 1. Scegli **Continue (Continua)**. 1. Selezionare **Promote read replica (Promuovi replica di lettura)**. 1. Ora si dispone di una versione aggiornata del database MySQL. A questo punto, puoi indirizzare le applicazioni alla nuova istanza database MySQL 8.0. # Monitoraggio degli aggiornamenti del motore RDS per MySQL con eventi Quando aggiorni la versione del motore di un database RDS per MySQL, Amazon RDS emette un evento specifico durante ogni fase del processo. Per tenere traccia dello stato di avanzamento di un aggiornamento, puoi visualizzare o iscriverti a questi eventi. Per ulteriori informazioni sugli eventi RDS, consulta[Monitoraggio di eventi Amazon RDS](working-with-events.md). Per informazioni dettagliate su uno specifico evento Amazon RDS che si verifica durante l'aggiornamento del motore, consulta[Categorie di eventi e messaggi di eventi di Amazon RDS ](USER_Events.Messages.md). # Aggiornamento di una versione del motore di snapshot di database MySQL Con Amazon RDS puoi creare uno snapshot DB del volume di storage dell'istanza database MySQL. Quando si crea uno snapshot di database, lo snapshot si basa sulla versione del motore utilizzata dall’istanza database. È possibile aggiornare la versione del motore per gli snapshot di database in uso. In RDS per MySQL, è possibile aggiornare uno snapshot versione 5.7 alla versione 8.0 o uno snapshot versione 8.0 alla versione 8.4. È possibile aggiornare snapshot di database crittografati o non crittografati. Per visualizzare le versioni del motore disponibili per lo snapshot di database di RDS per MySQL, utilizza l’esempio della AWS CLI seguente. ``` aws rds describe-db-engine-versions --engine mysql --include-all --engine-version example-engine-version --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" --output text ``` Se per lo snapshot non viene visualizzato alcun risultato, la versione del motore potrebbe essere obsoleta. Se la versione del motore è obsoleta, si consiglia di eseguire l’aggiornamento alla versione principale più recente oppure a una delle altre destinazioni di aggiornamento disponibili per tale versione. Per ulteriori informazioni, consulta [Opzioni di aggiornamento per snapshot di database con versioni del motore non supportate per RDS per MySQL](mysql-upgrade-snapshot.upgrade-options.md). Dopo aver ripristinato uno snapshot DB aggiornato a una nuova versione del motore, verificare che l'aggiornamento abbia avuto esito positivo. Per maggiori informazioni sull’aggiornamento di una versione principale, consultare [Aggiornamenti del motore di database RDS per MySQL](USER_UpgradeDBInstance.MySQL.md). Per informazioni su come ripristinare uno snapshot DB, consulta [Ripristino in un’istanza database](USER_RestoreFromSnapshot.md). **Nota** Non è possibile aggiornare gli snapshot di database automatizzati creati durante il processo di backup automatico. È possibile aggiornare uno snapshot DB utilizzando Console di gestione AWS AWS CLI, o l'API RDS. ------ #### [ Console ] Per aggiornare una versione del motore di snapshot DB utilizzando il Console di gestione AWS, utilizzare la procedura seguente. **Per aggiornare uno snapshot DB** 1. Accedi a Console di gestione AWS e apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Nel pannello di navigazione, selezionare **Snapshots (Snapshot)**. 1. Scegli la snapshot da usare per l’aggiornamento. 1. Per **Actions (Operazioni)**, scegliere **Upgrade snapshot (Aggiorna snapshot)**. Viene visualizzata la pagina **Upgrade snapshot (Aggiorna snapshot)**. 1. Scegli **New engine version (Nuova versione del motore)** per eseguire l’aggiornamento. 1. Scegliere **Save changes (Salva modifiche)** per aggiornare lo snapshot. Durante il processo di aggiornamento, tutte le operazioni dello snapshot sono disabilitate per lo snapshot database. Inoltre, lo stato dello snapshot di database cambia da **disponibile** a **in aggiornamento**, quindi diventa **attivo** al completamento. Se lo snapshot di database non può essere aggiornato a causa di problemi di corruzione, lo stato diventa **non disponibile**. Non è possibile recuperare lo snapshot quando è in questo stato. **Nota** Se l’aggiornamento dello snapshot fallisce, lo snapshot viene riportato allo stato originario con la versione iniziale. ------ #### [ AWS CLI ] Per aggiornare uno snapshot DB a una nuova versione del motore di database, esegui il AWS CLI [modify-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-snapshot.html)comando. **Opzioni** + `--db-snapshot-identifier` – Identificatore dello snapshot DB da aggiornare. L'identificatore deve essere un Amazon Resource Name (ARN) univoco. Per ulteriori informazioni, consulta [Nomi della risorsa Amazon (ARN) in Amazon RDS](USER_Tagging.ARN.md). + `--engine-version` – Versione del motore a cui aggiornare lo snapshot DB. **Example** Per Linux, macOS o Unix: ``` 1. aws rds modify-db-snapshot \ 2. 3. --db-snapshot-identifier my_db_snapshot \ 4. --engine-version new_version ``` Per Windows: ``` 1. aws rds modify-db-snapshot ^ 2. --db-snapshot-identifier my_db_snapshot ^ 3. --engine-version new_version ``` ------ #### [ Amazon RDS API ] [Per aggiornare uno snapshot DB a una nuova versione del motore di database, chiamate l'operazione RDS API Modify. DBSnapshot](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBSnapshot.html) **Parameters** + `DBSnapshotIdentifier` – Identificatore dello snapshot DB da aggiornare. L'identificatore deve essere un Amazon Resource Name (ARN) univoco. Per ulteriori informazioni, consulta [Nomi della risorsa Amazon (ARN) in Amazon RDS](USER_Tagging.ARN.md). + `EngineVersion` – Versione del motore a cui aggiornare lo snapshot DB. ------ # Opzioni di aggiornamento per snapshot di database con versioni del motore non supportate per RDS per MySQL Nella tabella seguente sono indicate le versioni del motore a cui è possibile eseguire l’aggiornamento da una versione del motore non supportata per gli snapshot di database di RDS per MySQL. **Nota** Per eseguire l’aggiornamento alla versione del motore scelta, potrebbe essere necessario aggiornare lo snapshot di database più di una volta. | Versione del motore di snapshot di database | Versioni del motore disponibili per l’aggiornamento | | --- | --- | | 5,5,8 | 5.5.62, 5.6.51 | | 5,5,12 | 5.5.62, 5.6.51 | | 5,5,20 | 5.5.62, 5.6.51 | | 5,5,23 | 5.5.62, 5.6.51 | | 5.5.25a | 5.5.62, 5.6.51 | | 5,5,27 | 5.5.62, 5.6.51 | | 5,5,31 | 5.5.62, 5.6.51 | | 5,5,33 | 5.5.62, 5.6.51 | | 5,5,37 | 5.5.62, 5.6.51 | | 5,5,38 | 5.5.62, 5.6.51 | | 5,5,40 | 5.5.62, 5.6.51 | | 5.5.40a | 5.5.62, 5.6.51 | | 5.5.40b | 5.5.62, 5.6.51 | | 5,5,41 | 5.5.62, 5.6.51 | | 5,5,42 | 5.5.62, 5.6.51 | | 5.5.59 | 5.5.62, 5.6.51 | | 5,6,12 | 5.6.51, 5.7.44 | | 5,6,13 | 5.6.51, 5.7.44 | | 5,6,17 | 5.6.51, 5.7.44 | | 5,6,19 | 5.6.51, 5.7.44 | | 5.6.19a | 5.6.51, 5.7.44 | | 5.6.19b | 5.6.51, 5.7.44 | | 5,6,21 | 5.6.51, 5.7.44 | | 5.6.21b | 5.6.51, 5.7.44 | | 5,6,22 | 5.6.51, 5.7.44 | | 5,6,23 | 5.6.51, 5.7.44 | | 5,6,27 | 5.6.51, 5.7.44 | | 5.6.27a | 5.6.51, 5.7.44 | | 5,7,10 | 5.7.44, 5.7.44-rds.20240408, 5.7.44-rds.20240529, 5.7.44-rds.20250103, 5.7.44-rds.20250213, 8.0.32, 8.0.33, 8.0.34, 8.0.35, 8.0.36, 8.0.37, 8.0.39, 8.0.40, 8.0.41 | | 5,7,11 | 5.7.44, 5.7.44-rds.20240408, 5.7.44-rds.20240529, 5.7.44-rds.20250103, 5.7.44-rds.20250213, 8.0.32, 8.0.33, 8.0.34, 8.0.35, 8.0.36, 8.0.37, 8.0.39, 8.0.40, 8.0.41 | | 5,7,12 | 5.7.44, 5.7.44-rds.20240408, 5.7.44-rds.20240529, 5.7.44-rds.20250103, 5.7.44-rds.20250213, 8.0.32, 8.0.33, 8.0.34, 8.0.35, 8.0.36, 8.0.37, 8.0.39, 8.0.40, 8.0.41 | # Importazione di dati in un’istanza database Amazon RDS per MySQL Puoi utilizzare diverse tecniche per importare i dati in un'istanza database RDS for MySQL. L’approccio migliore dipende da una serie di fattori: + Origine dei dati + Quantità di dati + Importazione continua o eseguita una sola volta + Durata del tempo di inattività Se stai eseguendo la migrazione di un’applicazione insieme a tutti i suoi dati, la durata del tempo di inattività è un fattore importante da considerare. Nella seguente tabella sono riportate le varie tecniche per importare i dati in un’istanza database RDS per MySQL: | Origine | Quantità di dati | Una volta o continua | Tempo di inattività delle applicazioni | Tecnica | Ulteriori informazioni | | --- | --- | --- | --- | --- | --- | | Database MySQL esistente in locale o su Amazon EC2 | Qualsiasi | Una volta | Medio | Crea un backup del database locale, archivialo in Amazon S3 e quindi ripristina il file di backup in una nuova istanza database Amazon RDS che esegue MySQL. | [Ripristino di un backup in un’istanza database Amazon RDS per MySQL](MySQL.Procedural.Importing.md) | | Database MySQL esistente in locale o su Amazon EC2 | Qualsiasi | Continua | Minima | Configurare la replica utilizzando un database MySQL esistente come origine della replica. | [Configurazione della replica della posizione del file di log binario con un'istanza di origine esterna.](MySQL.Procedural.Importing.External.Repl.md) [Importazione dei dati in un database Amazon RDS per MySQL con tempo di inattività ridotto](mysql-importing-data-reduced-downtime.md) | | Qualsiasi database esistente | Qualsiasi | Una volta o continua | Minima | AWS Database Migration Service Utilizzatelo per migrare il database con tempi di inattività minimi e, per molti motori di database di database, continuare la replica continua. | [Cos'è AWS Database Migration Service](https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html) e [Utilizzo di un database compatibile con MySQL come destinazione per AWS DMS](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Target.MySQL.html) nella *Guida per l’utente di AWS Database Migration Service * | | Istanza database MySQL esistente | Qualsiasi | Una volta o continua | Minima | Creare una replica di lettura per la replica continua. Promuovere la replica di lettura per la creazione una tantum di una nuova istanza database. | [Uso delle repliche di lettura dell'istanza database](USER_ReadRepl.md) | | Database MySQL esistente | Small | Una volta | Medio | Copiare i dati direttamente nell'istanza database MySQL utilizzando un'utilità a riga di comando. | [Importazione di dati da un database MySQL esterno in un’istanza database Amazon RDS per MySQL](mysql-importing-data-external-database.md) | | Dati non salvati in un database esistente | Medium | Una volta | Medio | Creare file flat e importarli con istruzioni LOAD DATA LOCAL INFILE di MySQL. | [Importazione di dati da qualsiasi origine in un’istanza database Amazon RDS per MySQL](mysql-importing-data-any-source.md) | **Nota** Il database di sistema `mysql` contiene le informazioni di autenticazione e autorizzazione necessarie per accedere all'istanza database e ai dati. L'eliminazione, la modifica, la ridenominazione o il troncamento di tabelle, dati o altro contenuto del database `mysql` nell'istanza database può causare un errore e rendere inaccessibili dati e istanza database. In tal caso, è possibile ripristinare l'istanza DB da un'istantanea utilizzando il comando. AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html) È possibile ripristinare l'istanza DB utilizzando il AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html)comando. # Considerazioni sull’importazione di dati per MySQL Il contenuto seguente include informazioni tecniche relative al caricamento dei dati in MySQL. Il contenuto è rivolto a utenti con una buona conoscenza dell’architettura server MySQL. ## Registrazione di log binari L’abilitazione della registrazione di log binari riduce le prestazioni di caricamento dei dati e richiede uno spazio su disco quattro volte superiore rispetto alla registrazione di log disabilitata. Le dimensioni delle transazioni utilizzate per caricare i dati influiscono direttamente sulle prestazioni del sistema e sulle esigenze di spazio su disco – transazioni di grandi dimensioni richiedono un numero maggiore di risorse. ## Dimensioni delle transazioni Le dimensioni delle transazioni influenzano i seguenti aspetti dei caricamenti di dati MySQL: + Consumo di risorse + Utilizzo dello spazio su disco + Processo di ripresa + Tempo di ripristino + Formato di input (file flat o SQL) Questa sezione descrive in che modo le dimensioni della transazione incidono sul log binario e spiega perché sia conveniente disattivare il log binario durante il caricamento di grandi quantità di dati. Per abilitare e disabilitare la registrazione di log binari, impostare il periodo di conservazione dei backup automatici di Amazon RDS. Un valore pari a zero disattiva il log binario, mentre qualsiasi altro valore lo attiva. Per ulteriori informazioni, consulta [Periodo di conservazione dei backup](USER_WorkingWithAutomatedBackups.BackupRetention.md). Questa sezione descrive anche l’impatto delle transazioni di grandi dimensioni in InnoDB nonché i motivi per cui è importante contenere le dimensioni delle transazioni. ### Transazioni di piccole dimensioni Nel caso delle transazioni di piccole dimensioni, i log binari raddoppiano il numero di scritture su disco richieste per il caricamento dei dati. Tale effetto può incidere molto negativamente sulle prestazioni di altre sessioni di database e allungare i tempi richiesti per il caricamento dei dati. La riduzione delle prestazioni dipende in parte dai seguenti fattori: + Velocità di caricamento + Altre attività del database in esecuzione durante il caricamento + Capacità dell’istanza database Amazon RDS I log binari consumano una quantità di spazio su disco approssimativamente pari alla quantità di dati caricati, fino a quando non ne viene effettuato il backup e i dati non vengono rimossi. Amazon RDS attenua il problema grazie a backup frequenti e alla rimozione dei log binari. ### Transazioni di grandi dimensioni Per transazioni di grandi dimensioni, la registrazione di log binari triplica il numero di IOPS e l’utilizzo del disco per i seguenti motivi: + La cache del log binario archivia temporaneamente i dati delle transazioni su disco. + Le dimensioni della cache aumentano in base a quelle della transazione, consumando spazio su disco. + Al termine della transazione (commit o rollback), il sistema copia la cache nel log binario. Il processo crea tre copie dei dati: + Dati originali + Cache su disco + Ultima voce del log binario Ogni operazione di scrittura comporta un I/O aggiuntivo, con un ulteriore impatto sulle prestazioni. Per questo motivo, la registrazione di log binari richiede uno spazio su disco tre volte maggiore rispetto al caso in cui sia disabilitata. Ad esempio, il caricamento di 10 GiB di dati come singola transazione crea tre copie: + 10 GiB per i dati della tabella + 10 GiB per la cache del log binario + 10 GiB per il file di log binario Lo spazio su disco totale richiesto temporaneamente è di 30 GiB. Considerazioni importanti sullo spazio su disco: + Il file di cache persiste fino al termine della sessione o fino alla creazione di un’altra cache da parte di una nuova transazione. + Il log binario rimane attivo fino a quando non ne viene eseguito il backup e può contenere 20 GiB di dati (cache e log) per un periodo prolungato. Se si utilizza `LOAD DATA LOCAL INFILE` per caricare i dati, durante il ripristino viene creata una quarta copia dei dati qualora il database debba essere ripristinato da un backup eseguito prima del caricamento. Durante il recupero, MySQL estrae i dati dal log binario in un file flat. MySQL esegue quindi `LOAD DATA LOCAL INFILE`. In base all’esempio precedente, questo ripristino richiede uno spazio su disco temporaneo totale di 40 GiB o di 10 GiB ciascuno per tabella, cache, log e file locale. Se non sono disponibili almeno 40 GiB di spazio su disco, il ripristino non può essere eseguito. ### Ottimizzazione di carichi di dati di grandi dimensioni Per carichi di dati di grandi dimensioni, disabilitare la registrazione di log binari per ridurre il sovraccarico e i requisiti di spazio su disco. È possibile disabilitare la registrazione di log binari impostando il periodo di conservazione dei backup su 0. Al termine del caricamento, ripristinare il periodo di conservazione dei backup sul valore diverso da zero appropriato. Per ulteriori informazioni, consulta [Modifica di un'istanza database Amazon RDS](Overview.DBInstance.Modifying.md) e [Periodo di conservazione dei backup](USER_ModifyInstance.Settings.md) nella tabella delle impostazioni. **Nota** Non è possibile impostare il periodo di conservazione dei backup su zero se l’istanza database è un’origine per le repliche di lettura. Prima di caricare i dati, è consigliabile creare uno snapshot di database. Per ulteriori informazioni, consulta [Gestione dei backup manuali](USER_ManagingManualBackups.md). ## InnoDB Le seguenti informazioni sulla registrazione di log di undo e sulle opzioni di ripristino prevedono di mantenere ridotte le dimensioni delle transazioni InnoDB per ottimizzare le prestazioni del database. ### Informazioni sulla registrazione di log di undo InnoDB L’annullamento (undo) è un meccanismo della registrazione di log che consente il rollback delle transazioni e supporta il controllo della concorrenza multiversione (MVCC). In MySQL 5.7 e versioni precedenti, i log di undo vengono archiviati nel tablespace del sistema InnoDB (in genere ibdata1) e mantenuti fino a quando il thread di eliminazione non li rimuove. Di conseguenza, le transazioni di caricamento di dati di grandi dimensioni possono causare un aumento significativo delle dimensioni del tablespace del sistema, con un consumo di spazio su disco che non si può recuperare senza ricreare il database da zero. Per tutte le versioni di MySQL, il thread di eliminazione deve attendere la rimozione dei log di undo fino al commit o al rollback della transazione attiva meno recente. Se il database elabora altre transazioni durante il caricamento, anche i relativi log di undo si accumulano e non possono essere rimossi, anche nel caso di commit delle transazioni e in quello in cui nessun’altra transazione richieda log di undo per MVCC. In questa situazione, tutte le transazioni, incluse quelle di sola lettura, rallentano. Il rallentamento si verifica perché tutte le transazioni accedono a tutte le righe modificate da qualsiasi transazione, non solo da quella di caricamento. In effetti, le transazioni devono eseguire la scansione dei log di undo che le transazioni di caricamento di lunga durata hanno impedito di eliminare durante una pulizia dei log di undo stessi. Ciò influisce sulle prestazioni di tutte le operazioni di accesso alle righe modificate. ### Opzioni di ripristino delle transazioni InnoDB Sebbene InnoDB ottimizzi le operazioni di commit, i rollback delle transazioni di grandi dimensioni sono lenti. Per un ripristino più rapido, esegui un point-in-time ripristino o ripristina un'istantanea del DB. Per ulteriori informazioni, consultare [Point-in-time recupero](USER_PIT.md) e [Ripristino in un’istanza database](USER_RestoreFromSnapshot.md). ## Formati di importazione dei dati MySQL supporta due formati di importazione di dati, ovvero file flat e SQL. Consultare le informazioni su ciascun formato per determinare l’opzione migliore per le proprie esigenze. ### File flat Per transazioni di piccole dimensioni, caricare file flat con `LOAD DATA LOCAL INFILE`. Rispetto all’utilizzo di SQL, questo formato di importazione dati può comportare i seguenti vantaggi: + Minor traffico di rete + Riduzione dei costi di trasmissione dei dati + Riduzione del sovraccarico di elaborazione del database + Elaborazione più rapida `LOAD DATA LOCAL INFILE` carica l’intero file flat come un’unica transazione. Mantenere ridotte le dimensioni dei singoli file per ottenere i seguenti vantaggi: + **Capacità di ripristino**: si può tenere facilmente traccia dei file caricati. In caso di problemi durante il caricamento, si può riprendere l’operazione dal punto in cui era stata interrotta. Potrebbe essere necessario trasmettere nuovamente alcuni file ad Amazon RDS, ma nel caso di file di piccole dimensioni la quantità di dati ritrasmessa è minima. + **Caricamento di dati in parallelo**: se si dispone di IOPS e di larghezza di banda della rete sufficienti per caricare un file singolo, il caricamento in parallelo potrebbe consentire di risparmiare tempo. + **Controllo della velocità di caricamento**: se il caricamento dei dati ha un impatto negativo su altri processi, è possibile controllarne la velocità aumentando l’intervallo tra i file. Le transazioni di grandi dimensioni riducono i vantaggi dell’utilizzo di `LOAD DATA LOCAL INFILE` per importare i dati. Se non si riesce a suddividere una grande quantità di dati in file di dimensioni minori, prendere in considerazione l’utilizzo di SQL. ### SQL Rispetto ai file flat, SQL presenta un grande vantaggio perché consente di mantenere ridotte le dimensioni delle transazioni, sebbene i tempi di caricamento siano significativamente più lunghi. Dopo un errore, inoltre, può essere difficile determinare il punto da cui riprendere perché non è possibile riavviare i file mysqldump. In caso di errore durante il caricamento di un file mysqldump, quest’ultimo dovrà essere modificato o sostituito prima che sia possibile riprendere il caricamento. In alternativa, dopo aver corretto la causa dell’errore, è possibile tornare al punto temporale precedente al caricamento e inviare nuovamente il file. Per ulteriori informazioni, consulta [Point-in-time recupero](USER_PIT.md). ## Utilizzo degli snapshot di database di Amazon RDS per i checkpoint di database Se si caricano dati per lunghi periodi, ad esempio ore o giorni, senza registrazione di log binari, utilizzare gli snapshot di database per fornire checkpoint periodici per la sicurezza dei dati. Ogni snapshot di database crea una copia coerente dell’istanza database che funge da punto di ripristino in caso di errori di sistema o di eventi di danneggiamento dei dati. Poiché gli snapshot di database sono veloci, i checkpoint frequenti hanno un impatto minimo sulle prestazioni del caricamento. È possibile eliminare gli snapshot di database precedenti senza influire sulla durabilità o sulle funzionalità di ripristino del database. Per ulteriori informazioni sugli snapshot di database, consulta [Gestione dei backup manuali](USER_ManagingManualBackups.md). ## Riduzione dei tempi di caricamento del database Di seguito sono indicati alcuni suggerimenti per ridurre i tempi di caricamento: + Creare tutti gli indici secondari prima di caricare i dati nei database MySQL. A differenza di altri sistemi di database, quando si aggiungono o si modificano gli indici secondari MySQL ricostruisce l’intera tabella. Questo processo consente di creare una nuova tabella con modifiche agli indici, di copiare tutti i dati e di eliminare la tabella originale. + Caricare i dati in base all’ordine della chiave primaria. Per le tabelle InnoDB, questa operazione può ridurre i tempi di caricamento del 75%-80% e le dimensioni dei file di dati del 50%. + Disabilitare i vincoli di chiave esterna impostando `foreign_key_checks` su `0`. Questa operazione è spesso necessaria per i file flat caricati con `LOAD DATA LOCAL INFILE`. Per qualsiasi carico, la disabilitazione dei controlli di chiave esterna accelera il caricamento dei dati. Dopo aver completato il caricamento, riabilitare i vincoli impostando `foreign_key_checks` su `1` e verificare i dati. + Caricare i dati in parallelo a meno che non si stia raggiungendo il limite di risorse. Per consentire il caricamento simultaneo su più segmenti di tabella, se necessario utilizzare tabelle partizionate. + Per ridurre il sovraccarico di esecuzione SQL, combinare più istruzioni `INSERT` in singole operazioni `INSERT` con più valori. `mysqldump` implementa questa ottimizzazione in modo automatico. + Ridurre le operazioni di I/O dei log InnoDB impostando `innodb_flush_log_at_trx_commit` su `0`. Al termine del caricamento, ripristinare il valore di `innodb_flush_log_at_trx_commit` su `1`. **avvertimento** Se si imposta `innodb_flush_log_at_trx_commit` su `0`, InnoDB cancella i log ogni secondo anziché a ogni commit. Questa impostazione aumenta le prestazioni, ma può comportare il rischio di perdita delle transazioni durante i guasti del sistema. + Se si caricano i dati in un’istanza database che non include repliche di lettura, impostare `sync_binlog` su `0`. Al termine del caricamento, ripristinare il valore di `sync_binlog parameter` su `1`. + Caricare i dati in un’istanza database Single-AZ prima di convertire l’istanza database in un’implementazione Multi-AZ. Se l’istanza database utilizza già un’implementazione Multi-AZ, non è consigliabile passare a un’implementazione Single-AZ per il caricamento dei dati. In tal modo si otterrebbero solo miglioramenti marginali. # Ripristino di un backup in un’istanza database Amazon RDS per MySQL Amazon RDS supporta l’importazione di database MySQL con file di backup. È possibile creare un backup del database, archiviarlo nel file di backup in Amazon S3 e quindi ripristinare il file di backup in una nuova istanza database Amazon RDS che esegue MySQL. Amazon RDS supporta l’importazione di file di backup da Amazon S3 in tutte le Regioni AWS. Lo scenario descritto in questa sezione ripristina un backup di un database locale. Purché il database sia accessibile, è possibile utilizzare questa tecnica per i database in altre posizioni, ad esempio Amazon EC2 o altri servizi cloud. Il seguente diagramma mostra lo scenario supportato. ![\[Importazione di file di backup in MySQL da S3.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/images/MySQL-bak-file.png) Se il database on-premises può rimanere offline durante la creazione, la copia e il ripristino dei file di backup, è consigliabile importare il database in Amazon RDS utilizzando i file di backup. Se il database non può rimanere offline, puoi utilizzare uno dei seguenti metodi: + **Log binari**: per prima cosa, importa i file di backup da Amazon S3 in Amazon RDS, come illustrato in questo argomento. Quindi utilizza la replica di log binari (binlog) per aggiornare il database. Per ulteriori informazioni, consulta [Configurazione della replica della posizione del file di log binario con un'istanza di origine esterna.](MySQL.Procedural.Importing.External.Repl.md). + **AWS Database Migration Service**— Utilizzalo AWS Database Migration Service per migrare il tuo database su Amazon RDS. Per ulteriori informazioni, consulta [Cos'è? AWS Database Migration Service](https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html) ## Panoramica della configurazione per l’importazione di file di backup da Amazon S3 in Amazon RDS Per l’importazione di file di backup da Amazon S3 in Amazon RDS, sono necessari i seguenti componenti: + Un bucket Amazon S3 per archiviare i file di backup. Se hai già un bucket Amazon S3, puoi utilizzarlo. Se non hai un bucket Amazon S3, creane uno nuovo. Per ulteriori informazioni, consulta [Creazione di un bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/CreatingaBucket.html). + Un backup del database locale creato da XtraBackup Percona. Per ulteriori informazioni, consulta [Creazione del backup di database](#MySQL.Procedural.Importing.Backup). + Un ruolo AWS Identity and Access Management (IAM) per consentire ad Amazon RDS di accedere al bucket S3. Se hai già un ruolo IAM, puoi utilizzarlo e collegarvi policy di attendibilità e di autorizzazione. Per ulteriori informazioni, consulta [Creazione di un ruolo IAM manualmente](#MySQL.Procedural.Importing.Enabling.IAM). Se non hai un ruolo IAM, puoi scegliere una di queste due opzioni: + Creare un nuovo ruolo IAM manualmente. Per ulteriori informazioni, consulta [Creazione di un ruolo IAM manualmente](#MySQL.Procedural.Importing.Enabling.IAM). + Impostare la creazione automatica di un ruolo IAM in Amazon RDS. Se desideri che Amazon RDS crei un nuovo ruolo IAM per te, segui la procedura che utilizza la [Importazione di dati da Amazon S3 in una nuova istanza database MySQL](#MySQL.Procedural.Importing.PerformingImport) sezione Console di gestione AWS in. ## Creazione del backup di database Usa il XtraBackup software Percona per creare il tuo backup. Ti consigliamo di utilizzare l'ultima versione di XtraBackup Percona. È possibile installare Percona XtraBackup da [Software Downloads sul sito Web](https://www.percona.com/downloads/) di Percona. **avvertimento** Durante la creazione di un backup del database, XtraBackup potrebbe salvare le credenziali nel file xtrabackup\$1info. Assicurati che l’impostazione `tool_command` nel file xtrabackup\$1info non contenga informazioni sensibili. La XtraBackup versione di Percona che usi dipende dalla versione di MySQL di cui stai eseguendo il backup. + **MySQL 8.4 — Usa la versione** 8.4 di Percona. XtraBackup + **MySQL 8.0 — Usa la versione** 8.0 di Percona. XtraBackup **Nota** Percona XtraBackup 8.0.12 e versioni successive supportano la migrazione di tutte le versioni di MySQL 8.0. Se stai migrando a RDS for MySQL 8.0.32 o versioni successive, devi usare Percona 8.0.12 o versioni successive. XtraBackup + **MySQL** 5.7 — Usa la versione 2.4 di Percona. XtraBackup Puoi usare Percona XtraBackup per creare un backup completo dei file del tuo database MySQL. In alternativa, se utilizzi già Percona XtraBackup per eseguire il backup dei file del database MySQL, puoi caricare le directory e i file di backup completi e incrementali esistenti. Per ulteriori informazioni sul backup del database con Percona, consulta Percona - Documentazione sul sito XtraBackup Web di [ XtraBackup Percona](https://www.percona.com/doc/percona-xtrabackup/LATEST/index.html). ### Creazione di un backup completo con Percona XtraBackup Per creare un backup completo dei file del database MySQL che Amazon RDS può ripristinare da Amazon S3, usa l'utilità Percona (). XtraBackup `xtrabackup` Ad esempio, il comando seguente consente di creare un backup di un database MySQL e memorizzare i file nella cartella `/on-premises/s3-restore/backup`. ``` xtrabackup --backup --user=myuser --password=password --target-dir=/on-premises/s3-restore/backup ``` Se desideri comprimere il backup in un singolo file (che potrai suddividere in seguito, se necessario), puoi salvare il backup in uno dei seguenti formati, a seconda della versione di MySQL: + **Gzip (.gz)**: per MySQL 5.7 e versioni precedenti + **tar (.tar)**: per MySQL 5.7 e versioni precedenti + **Percona xbstream (.xbstream)**: per tutte le versioni di MySQL **Nota** Percona XtraBackup 8.0 e versioni successive supportano solo Percona xbstream per la compressione. **MySQL 5.7 e versioni precedenti** Il comando seguente consente di creare un backup del database MySQL diviso in più file Gzip. Sostituisci i valori con le tue informazioni. ``` xtrabackup --backup --user=my_user --password=password --stream=tar \ --target-dir=/on-premises/s3-restore/backup | gzip - | split -d --bytes=500MB \ - /on-premises/s3-restore/backup/backup.tar.gz ``` **MySQL 5.7 e versioni precedenti** Il comando seguente consente di creare un backup del database MySQL diviso in più file tar. Sostituisci i valori con le tue informazioni. ``` xtrabackup --backup --user=my_user --password=password --stream=tar \ --target-dir=/on-premises/s3-restore/backup | split -d --bytes=500MB \ - /on-premises/s3-restore/backup/backup.tar ``` **Tutte le versioni di MySQL** Il comando seguente consente di creare un backup del database MySQL diviso in più file xbstream. Sostituisci i valori con le tue informazioni. ``` xtrabackup --backup --user=myuser --password=password --stream=xbstream \ --target-dir=/on-premises/s3-restore/backup | split -d --bytes=500MB \ - /on-premises/s3-restore/backup/backup.xbstream ``` **Nota** Se viene visualizzato il seguente errore, è possibile che il problema sia dovuto dalla combinazione di formati di file diversi nel comando: ``` ERROR:/bin/tar: This does not look like a tar archive ``` ### Utilizzo di backup incrementali con Percona XtraBackup Se utilizzi già Percona XtraBackup per eseguire backup completi e incrementali dei file del tuo database MySQL, non è necessario creare un backup completo e caricare i file di backup su Amazon S3. In alternativa, per risparmiare tempo, copia le directory e i file di backup esistenti nel bucket Amazon S3. [Per ulteriori informazioni sulla creazione di backup incrementali utilizzando Percona, consulta Creare un backup incrementale sul sito Web di Percona XtraBackup.](https://docs.percona.com/percona-xtrabackup/LATEST/create-incremental-backup.html) Durante la copia dei file del backup completo e incrementale in un bucket Amazon S3, devi copiare in modo ricorsivo i contenuti della directory di base. Questi contenuti includono sia il backup completo sia tutte le directory e tutti i file del backup incrementale. Questa copia deve mantenere la struttura di directory nel bucket Amazon S3. Amazon RDS esegue l'iterazione di tutti i file e le directory. Amazon RDS utilizza il file `xtrabackup-checkpoints` incluso con ogni backup incrementale per identificare la directory di base e ordinare i backup incrementali in base all’intervallo dei numeri di sequenza di log (LSN). ### Considerazioni sul backup per Percona XtraBackup Amazon RDS consuma i file di backup in base al nome del file. Assegna un nome ai file di backup con l’estensione file appropriata in base al formato. Ad esempio, utilizza `.xbstream` per i file archiviati nel formato Percona xbstream. Amazon RDS consuma i file di backup in ordine alfabetico e anche in ordine numerico naturale. Per assicurarti che i file di backup vengano scritti e denominati nell’ordine corretto, utilizza l’opzione `split` quando invii il comando `xtrabackup`. Amazon RDS non supporta backup parziali creati con Percona. XtraBackup Non puoi utilizzare le opzioni seguenti per creare un backup parziale quando esegui il backup dei file di origine del database: + `--tables` + `--tables-exclude` + `--tables-file` + `--databases` + `--databases-exclude` + `--databases-file` ## Creazione di un ruolo IAM manualmente Se non hai già un ruolo IAM, puoi creane uno nuovo manualmente. Tuttavia, se ripristini il database utilizzando il Console di gestione AWS, ti consigliamo di fare in modo che Amazon RDS crei questo nuovo ruolo IAM per te. A tale scopo, segui la procedura descritta nella sezione [Importazione di dati da Amazon S3 in una nuova istanza database MySQL](#MySQL.Procedural.Importing.PerformingImport). Per creare manualmente un nuovo ruolo IAM per l’importazione del database da Amazon S3, crea un ruolo per delegare le autorizzazioni da Amazon RDS al bucket Amazon S3. Quando crei un ruolo IAM, vengono collegate le policy di attendibilità e autorizzazione. Per importare i file di backup da Amazon S3, utilizza policy di attendibilità e autorizzazione simili agli esempi seguenti. Per ulteriori informazioni sulla creazione del ruolo, consulta [Creazione di un ruolo per delegare le autorizzazioni a](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) un servizio. AWS Le policy di attendibilità e autorizzazione richiedono che venga fornito un Amazon Resource Name (ARN). Per ulteriori informazioni sulla formattazione ARN, consulta [Amazon Resource Names (ARNs) e AWS](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html) service namespaces. **Example policy di attendibilità per l’importazione da Amazon S3** **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AssumeRoleForBackup", "Effect": "Allow", "Principal": { "Service": "rds.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` **Example policy di autorizzazione per l’importazione da Amazon S3 – autorizzazioni dell’utente IAM** Nell'esempio seguente, *iam\$1user\$1id* sostituiscilo con il tuo valore. **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowS3AccessRole", "Effect": "Allow", "Action": "iam:PassRole", "Resource": "arn:aws:iam::111122223333:role/S3Access" } ] } ``` **Example policy di autorizzazione per l’importazione da Amazon S3 – autorizzazioni di ruolo** Nell'esempio seguente, sostituisci *amzn-s3-demo-bucket* e *prefix* con i tuoi valori. **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:ListBucket", "s3:GetBucketLocation" ], "Resource": "arn:aws:s3:::amzn-s3-demo-bucket" }, { "Effect": "Allow", "Action": [ "s3:GetObject" ], "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/prefix*" }, { "Effect": "Allow", "Action": [ "kms:Decrypt" ], "Resource": [ "arn:aws:kms:us-east-1:111122223333:key/key_id*" ] } ] } ``` Se includi un prefisso del nome file, aggiungi l'asterisco (\$1) dopo il prefisso. Se non intendi specificare un prefisso, specifica solo un asterisco. ## Importazione di dati da Amazon S3 in una nuova istanza database MySQL Puoi importare dati da Amazon S3 in una nuova istanza DB MySQL utilizzando l' Console di gestione AWS API, o RDS. AWS CLI ### Console **Per importare dati da Amazon S3 in una nuova istanza database MySQL** 1. Accedi a Console di gestione AWS e apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Nell'angolo in alto a destra della console Amazon RDS, scegli Regione AWS dove vuoi creare la tua istanza DB. Scegli lo Regione AWS stesso bucket Amazon S3 che contiene il backup del database. 1. Nel pannello di navigazione, seleziona **Database**. 1. Seleziona **Ripristina da S3**. Sarà visualizzata la pagina **Crea database ripristinando da S3** . ![\[Pagina Create database by restoring from S3 in cui si specificano i dettagli per il ripristino di un’istanza database da S3.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/images/mys-s3-ingestion.png) 1. Nell’area **S3 source**: 1. Seleziona il **bucket S3** che contiene il backup. 1. (Facoltativo) Per **S3 prefix** inserisci un prefisso del percorso per i file archiviati nel bucket Amazon S3. Se non specifichi un prefisso, Amazon RDS crea l’istanza database utilizzando tutti i file e le cartelle nella cartella root del bucket S3. Se invece specifichi un prefisso, Amazon RDS crea l’istanza database utilizzando i file e le cartelle nel bucket S3 in cui il percorso del file inizia con il prefisso specificato. Ad esempio, supponi di archiviare i file di backup su S3 in una sottocartella denominata backups e di avere più set di file di backup, ciascuno nella rispettiva directory (gzip\$1backup1, gzip\$1backup2 e così via). In questo caso, per eseguire il ripristino dai file nella cartella gzip\$1backup1, specificherai il prefisso backups/gzip\$1backup1. 1. In **Opzioni motore**: 1. Per **Tipo di motore**, seleziona **MySQL**. 1. In **Versione motore di origine**, seleziona la versione MySQL del database di origine. 1. Per **Versione motore**, scegli la versione secondaria predefinita della versione principale di MySQL nella Regione AWS. In Console di gestione AWS, è disponibile solo la versione secondaria predefinita. Al termine dell’importazione, puoi aggiornare l’istanza database. 1. Per il **ruolo IAM**, crea o scegli il ruolo IAM con le policy di attendibilità e di autorizzazione richieste che consentono ad Amazon RDS di accedere al bucket Amazon S3. Eseguire una delle seguenti operazioni: + (Consigliato) Scegliere **Crea nuovo ruolo** e inserire il **nome del ruolo IAM**. Con questa opzione, Amazon RDS crea automaticamente il ruolo con le policy di attendibilità e di autorizzazione. + Scegliere un ruolo IAM esistente. Assicurarsi che il ruolo soddisfi tutti i criteri definiti in [Creazione di un ruolo IAM manualmente](#MySQL.Procedural.Importing.Enabling.IAM). 1. Specifica le informazioni sull'istanza database. Per informazioni su ciascuna impostazione, consulta [Impostazioni per istanze database](USER_CreateDBInstance.Settings.md). **Nota** Assicurati di allocare archiviazione sufficiente per la nuova istanza database in modo che l’operazione di ripristino vada a buon fine. Per consentire automaticamente una crescita futura, in **Configurazione di archiviazione aggiuntiva**, scegli **Abilita il dimensionamento automatico dello storage**. 1. Scegliere impostazioni aggiuntive in base alle esigenze. 1. Scegliere **Create database (Crea database)**. ### AWS CLI Per importare dati da Amazon S3 in una nuova istanza DB MySQL utilizzando il AWS CLI, esegui il comando [restore-db-instance-from-s3](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-s3.html) con le seguenti opzioni. Per informazioni su ciascuna impostazione, consulta [Impostazioni per istanze database](USER_CreateDBInstance.Settings.md). **Nota** Assicurati di allocare archiviazione sufficiente per la nuova istanza database in modo che l’operazione di ripristino vada a buon fine. Per abilitare il dimensionamento automatico dell’archiviazione e consentire automaticamente una crescita futura, utilizza l’opzione `--max-allocated-storage`. + `--allocated-storage` + `--db-instance-identifier` + `--db-instance-class` + `--engine` + `--master-username` + `--manage-master-user-password` + `--s3-bucket-name` + `--s3-ingestion-role-arn` + `--s3-prefix` + `--source-engine` + `--source-engine-version` **Example** Per Linux, macOS o Unix: ``` 1. aws rds restore-db-instance-from-s3 \ 2. --allocated-storage 250 \ 3. --db-instance-identifier my_identifier \ 4. --db-instance-class db.m5.large \ 5. --engine mysql \ 6. --master-username admin \ 7. --manage-master-user-password \ 8. --s3-bucket-name amzn-s3-demo-bucket \ 9. --s3-ingestion-role-arn arn:aws:iam::account-number:role/rolename \ 10. --s3-prefix bucket_prefix \ 11. --source-engine my_sql \ 12. --source-engine-version 8.0.32 \ 13. --max-allocated-storage 1000 ``` Per Windows: ``` 1. aws rds restore-db-instance-from-s3 ^ 2. --allocated-storage 250 ^ 3. --db-instance-identifier my_identifier ^ 4. --db-instance-class db.m5.large ^ 5. --engine mysql ^ 6. --master-username admin ^ 7. --manage-master-user-password ^ 8. --s3-bucket-name amzn-s3-demo-bucket ^ 9. --s3-ingestion-role-arn arn:aws:iam::account-number:role/rolename ^ 10. --s3-prefix bucket_prefix ^ 11. --source-engine mysql ^ 12. --source-engine-version 8.0.32 ^ 13. --max-allocated-storage 1000 ``` ### API RDS [Per importare dati da Amazon S3 in una nuova istanza DB MySQL utilizzando l'API Amazon RDS, chiama l'operazione Restore fromS3. DBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromS3.html) ## Considerazioni e limitazioni per l’importazione di file di backup in Amazon RDS da Amazon S3 Le seguenti considerazioni e limitazioni si applicano all’importazione di file di backup da Amazon S3 in un’istanza database RDS per MySQL: + È possibile eseguire la migrazione dei dati solo in una nuova istanza database e non in una già esistente. + È necessario utilizzare Percona XtraBackup per eseguire il backup dei dati su Amazon S3. Per ulteriori informazioni, consulta [Creazione del backup di database](#MySQL.Procedural.Importing.Backup). + Il bucket Amazon S3 e l’istanza database RDS per MySQL devono trovarsi nella stessa Regione AWS. + Non è possibile eseguire il ripristino dalle seguenti origini: + Esportazione di uno snapshot dell’istanza database in Amazon S3. Non è nemmeno possibile eseguire la migrazione dei dati da un’esportazione di uno snapshot dell’istanza database nel bucket Amazon S3. + Un database di origine crittografato. È tuttavia possibile crittografare i dati che vengono migrati. Durante il processo di migrazione puoi anche lasciare i dati non crittografati. + Un database MySQL 5.5 o 5.6. + RDS per MySQL non supporta Percona Server for MySQL come database di origine perché può contenere tabelle `compression_dictionary*` nello `mysql schema`. + RDS per MySQL non supporta la migrazione alle versioni precedenti per le versioni principali o secondarie. Ad esempio, non è possibile eseguire la migrazione da MySQL versione 8.0 a RDS per MySQL 5.7 e nemmeno da MySQL versione 8.0.32 a RDS per MySQL versione 8.0.26. + Amazon RDS non supporta l’importazione nella classe di istanza database db.t2.micro da Amazon S3. È tuttavia possibile eseguire il ripristino in una classe di istanza database diversa e modificare tale classe in seguito. Per ulteriori informazioni sulle classi di istanza, consulta [Specifiche hardware per le classi di istanze DB ](Concepts.DBInstanceClass.Summary.md). + Amazon S3 limita la dimensione del file caricato in un bucket Amazon S3 a 5 TB. Se un file di backup supera i 5 TB, devi dividerlo in file più piccoli. + Amazon RDS limita il numero di file caricati in un bucket Amazon S3 a 1 milione. Se i dati di backup del database, inclusi tutti i backup completi e incrementali, superano 1 milione di file, utilizza un file Gzip (.gz), tar (.tar.gz) o Percona xbstream (.xbstream) per memorizzare i file dei backup completi e incrementali nel bucket Amazon S3. Percona XtraBackup 8.0 supporta solo Percona xbstream per la compressione. + Per fornire servizi di gestione per ogni istanza database, Amazon RDS crea l’utente `rdsadmin` al momento della creazione dell’istanza database. Poiché `rdsamin` è un utente riservato in Amazon RDS, si applicano le seguenti limitazioni: + Amazon RDS non importa le funzioni, le procedure, le viste, gli eventi e i trigger con il definer `'rdsadmin'@'localhost'`. Per ulteriori informazioni, consultare [Oggetti archiviati con ‘rdsadmin’@’localhost’ come definer](#MySQL.Procedural.Importing.StoredObjects) e [Privilegi dell'account utente master](UsingWithRDS.MasterAccounts.md). + Durante la creazione dell’istanza database, Amazon RDS crea un utente master con i privilegi massimi supportati. Durante il ripristino dal backup, Amazon RDS rimuove automaticamente i privilegi non supportati assegnati agli utenti importati. Per identificare gli utenti che potrebbero essere interessati da questo problema, consulta [Account utente con privilegi non supportati](#MySQL.Migrating.ExtMySQL.Prechecks.Users). Per ulteriori informazioni sui privilegi supportati in RDS per MySQL, consulta [Privilegio basato sui ruoli per RDS per MySQL](Appendix.MySQL.CommonDBATasks.privilege-model.md). + Amazon RDS non esegue la migrazione delle tabelle create dall’utente nello schema `mysql`. + Il parametro `innodb_data_file_path` deve essere configurato con un solo file di dati che utilizza il nome di file di dati predefinito `ibdata1:12M:autoextend`. È possibile eseguire la migrazione del database con due file di dati, o con un file di dati con un nome diverso, utilizzando questo metodo. Di seguito sono riportati esempi di nomi di file non consentiti in Amazon RDS: + `innodb_data_file_path=ibdata1:50M` + `ibdata2:50M:autoextend` + `innodb_data_file_path=ibdata01:50M:autoextend` + Non puoi eseguire la migrazione da un database di origine con tabelle definite all'esterno della directory dei dati MySQL predefinita. + La dimensione massima supportata per i backup non compressi che utilizzano questo metodo è limitata a 64 TiB. Per i backup compressi, questo limite è inferiore per tenere conto dei requisiti dello spazio di decompressione. In questi casi, la dimensione massima di backup supportata è `64 TiB - compressed backup size`. Per informazioni sulla dimensione massima del database supportata da Amazon RDS per MySQL, consulta [Storage SSD per scopi generici](CHAP_Storage.md#Concepts.Storage.GeneralSSD) e [Storage SSD Provisioned IOPS](CHAP_Storage.md#USER_PIOPS). + Amazon RDS non supporta l’importazione di MySQL e di altri componenti e plugin esterni. + Amazon RDS non ripristina la totalità dei dati dal database. È consigliabile salvare lo schema del database e i valori relativi ai seguenti elementi dal database di sistema MySQL di origine e quindi aggiungerli all’istanza database RDS per MySQL ripristinata dopo che è stata creata: + Account utenti + Funzioni + Procedure archiviate + Informazioni fuso orario. Le informazioni sul fuso orario vengono caricate dal sistema operativo locale dell’istanza database RDS per MySQL. Per ulteriori informazioni, consulta [Fuso orario locale per le istanze database MySQL](MySQL.Concepts.LocalTimeZone.md). ### Oggetti archiviati con ‘rdsadmin’@’localhost’ come definer Amazon RDS non importa le funzioni, le procedure, le viste, gli eventi e i trigger con `'rdsadmin'@'localhost'` come definer. Puoi usare il seguente script SQL nel database MySQL di origine per elencare gli oggetti archiviati con il definire non supportato. ``` -- This SQL query lists routines with `rdsadmin`@`localhost` as the definer. SELECT ROUTINE_SCHEMA, ROUTINE_NAME FROM information_schema.routines WHERE definer = 'rdsadmin@localhost'; -- This SQL query lists triggers with `rdsadmin`@`localhost` as the definer. SELECT TRIGGER_SCHEMA, TRIGGER_NAME, DEFINER FROM information_schema.triggers WHERE DEFINER = 'rdsadmin@localhost'; -- This SQL query lists events with `rdsadmin`@`localhost` as the definer. SELECT EVENT_SCHEMA, EVENT_NAME FROM information_schema.events WHERE DEFINER = 'rdsadmin@localhost'; -- This SQL query lists views with `rdsadmin`@`localhost` as the definer. SELECT TABLE_SCHEMA, TABLE_NAME FROM information_schema.views WHERE DEFINER = 'rdsadmin@localhost'; ``` ### Account utente con privilegi non supportati Gli account utente con privilegi non supportati da RDS per MySQL vengono importati senza tali privilegi. Per l'elenco dei privilegi supportati, consulta [Privilegio basato sui ruoli per RDS per MySQL](Appendix.MySQL.CommonDBATasks.privilege-model.md). Puoi eseguire la seguente query SQL sul database di origine per elencare gli account utente con privilegi non supportati. ``` SELECT user, host FROM mysql.user WHERE Shutdown_priv = 'y' OR File_priv = 'y' OR Super_priv = 'y' OR Create_tablespace_priv = 'y'; ``` # Importazione di dati da un database MySQL esterno in un’istanza database Amazon RDS per MySQL È possibile importare i dati da un database MySQL esistente in un’istanza database RDS per MySQL. A tale scopo, copia il database con [mysqldump](https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html) e reindirizzalo direttamente nell’istanza database RDS per MySQL. L’utilità a riga di comando `mysqldump` viene spesso utilizzata per creare backup e trasferire dati da un server MySQL a un altro ed è inclusa nel software client MySQL. **Nota** Se si importano o si esportano grandi quantità di dati con un’istanza database MySQL, per rendere più affidabile e più veloce lo spostamento di dati da e verso Amazon RDS è consigliabile utilizzare i file di backup `xtrabackup` e Amazon S3. Per ulteriori informazioni, consulta [Ripristino di un backup in un’istanza database Amazon RDS per MySQL](MySQL.Procedural.Importing.md). Un tipico comando `mysqldump` per spostare dati da un database esterno a un’istanza database Amazon RDS è simile al seguente. Sostituisci i valori con le tue informazioni. ``` mysqldump -u local_user \ --databases database_name \ --single-transaction \ --compress \ --order-by-primary \ --routines=0 \ --triggers=0 \ --events=0 \ -plocal_password | mysql -u RDS_user \ --port=port_number \ --host=host_name \ -pRDS_password ``` **Importante** Assicurati di non lasciare spazi tra l'opzione `-p` e la password immessa. Come best practice per la sicurezza, specifica credenziali diverse dai prompt mostrati nell’esempio. Assicurati di essere a conoscenza dei seguenti suggerimenti e considerazioni: + Escludi gli schemi seguenti dal file di dump: + `sys` + `performance_schema` + `information_schema` Per impostazione predefinita, l'utility `mysqldump` esclude questi schemi. + Se devi migrare utenti e privilegi, prendi in considerazione l'utilizzo di uno strumento che genera il linguaggio di controllo dei dati (DCL) per ricrearli, come l'utilità. [pt-show-grants](https://www.percona.com/doc/percona-toolkit/LATEST/pt-show-grants.html) + L’utente che esegue l'importazione deve avere accesso all'istanza database. Per ulteriori informazioni, consulta [Controllo dell'accesso con i gruppi di sicurezza](Overview.RDSSecurityGroups.md). I parametri utilizzati sono i seguenti: + `-u local_user`: specifica un nome utente. La prima volta che si utilizza questo parametro, specificare il nome di un account utente nel database MySQL locale, identificato dal parametro `--databases`. + `--databases database_name`: specifica il nome del database nell’istanza database MySQL locale da importare in Amazon RDS. + `--single-transaction` – Verifica che tutti i dati caricati dal database locale siano coerenti a un singolo punto temporale. Nel caso in cui vi siano altri processi che modificano i dati mentre `mysqldump` li legge, l'uso di questo parametro aiuta a preservare l'integrità dei dati. + `--compress` – Riduce il consumo della larghezza di banda di rete comprimendo i dati dal database locale prima di inviarli ad Amazon RDS. + `--order-by-primary`: riduce il tempo di caricamento ordinando i dati di ogni tabella in base alla chiave primaria. + `--routines`: parametro utilizzato se nel database da copiare sono presenti routine, ad esempio stored procedure o funzioni. Imposta il parametro su `0` per escludere le routine durante il processo di importazione. Successivamente, ricrea manualmente le routine nel database Amazon RDS. + `--triggers`: parametro utilizzato se nel database da copiare sono presenti trigger. Imposta il parametro su `0` per escludere i trigger durante il processo di importazione. Successivamente, ricrea manualmente i trigger nel database Amazon RDS. + `--events`: parametro utilizzato se nel database da copiare sono presenti eventi. Imposta il parametro su `0` per escludere gli eventi durante il processo di importazione. Successivamente, ricrea manualmente gli eventi nel database Amazon RDS. + `-plocal_password` – Specifica una password. La prima volta che si utilizza questo parametro, specificare la password per l’account utente identificato dal primo parametro `-u`. + `-u RDS_user`: specifica un nome utente. La seconda volta che si utilizza questo parametro, specificare il nome di un account utente nel database predefinito per l’istanza database MySQL identificata dal parametro `--host`. + `--port port_number`: specifica la porta per l’istanza database MySQL. Il valore predefinito è 3306, che può essere modificato al momento della creazione dell’istanza database. + `--host host_name` – Specifica il nome del sistema dei nomi di dominio (DNS) dall'endpoint dell'istanza database Amazon RDS, ad esempio `myinstance.123456789012.us-east-1.rds.amazonaws.com`. Il valore dell’endpoint è disponibile nei dettagli dell’istanza database nella console Amazon RDS. + `-pRDS_password` – Specifica una password. La seconda volta che usi questo parametro, devi specificare la password per l'account utente identificato dal secondo parametro `-u`. Eventuali procedure, trigger, funzioni o eventi devono essere creati manualmente nel database Amazon RDS. Se il database da copiare dovesse contenere questi tipi di oggetti, dovrai escluderli al momento di eseguire `mysqldump`. A tale scopo, includi i parametri seguenti con il comando `mysqldump`: + `--routines=0` + `--triggers=0` + `--events=0` **Esempio** Di seguito il database di esempio `world` viene copiato nell’host locale in un’istanza database RDS per MySQL. Sostituisci i valori con le tue informazioni. Per Linux, macOS o Unix: ``` sudo mysqldump -u local_user \ --databases world \ --single-transaction \ --compress \ --order-by-primary \ --routines=0 \ --triggers=0 \ --events=0 \ -plocal_password | mysql -u rds_user \ --port=3306 \ --host=my_instance.123456789012.us-east-1.rds.amazonaws.com \ -pRDS_password ``` Per Windows: Apri un prompt dei comandi facendo clic con il pulsante destro del mouse su **Prompt dei comandi** del menu dei programmi di Windows e selezionando **Esegui come amministratore** ed esegui il comando seguente. Sostituisci i valori con le tue informazioni. ``` mysqldump -u local_user ^ --databases world ^ --single-transaction ^ --compress ^ --order-by-primary ^ --routines=0 ^ --triggers=0 ^ --events=0 ^ -plocal_password | mysql -u RDS_user ^ --port=3306 ^ --host=my_instance.123456789012.us-east-1.rds.amazonaws.com ^ -pRDS_password ``` **Nota** Come best practice per la sicurezza, specifica credenziali diverse dai prompt mostrati nell’esempio. # Importazione dei dati in un database Amazon RDS per MySQL con tempo di inattività ridotto In alcuni casi, potrebbe essere necessario importare dati da un database MySQL esterno che supporti un’applicazione attiva per un’istanza database RDS per MySQL oppure per un cluster di database MySQL Multi-AZ. Usa la seguente procedura per ridurre l'impatto sulla disponibilità delle applicazioni. Questa procedura può risultare utile anche quando utilizzi un database di dimensioni particolarmente elevate. Ti consente inoltre di ridurre i costi dell'importazione diminuendo la quantità di dati trasmessi in rete ad AWS. Con questa procedura trasferisci una copia dei dati del database in un'istanza Amazon EC2 e li importi in un nuovo database Amazon RDS. Utilizza quindi la replica per portare il database Amazon RDS up-to-date con la tua istanza esterna attiva, prima di reindirizzare l'applicazione al database Amazon RDS. Configurare la replica in base alle coordinate del log binario. **Nota** Per importare i dati in un’istanza database RDS per MySQL, se lo scenario supporta questo approccio si consiglia di spostare dati da e verso Amazon RDS usando i file di backup e Amazon S3. Per ulteriori informazioni, consulta [Ripristino di un backup in un’istanza database Amazon RDS per MySQL](MySQL.Procedural.Importing.md). Il diagramma seguente mostra l’importazione di un database MySQL esterno in un database MySQL in Amazon RDS. ![\[Flusso di lavoro che mostra l’importazione di un database MySQL esterno in un database MySQL in Amazon RDS.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/images/MigrateMySQLToRDS_1.png) ## Attività 1: creazione di una copia del database esistente Il primo passaggio da eseguire nella migrazione di grandi quantità di dati in un database RDS per MySQL riducendo al minimo il tempo di inattività consiste nella creazione di una copia dei dati di origine. Il diagramma seguente mostra la creazione di un backup del database MySQL. ![\[Flusso di lavoro che mostra la creazione di un backup del database MySQL.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/images/MigrateMySQLToRDS_2.png) Puoi utilizzare l'utility `mysqldump` per creare un backup del database in formato SQL o come testo delimitato. Si consiglia di eseguire un test con ciascun formato, fuori dall’ambiente di produzione, per capire quale metodo consenta di ridurre maggiormente il tempo di esecuzione di `mysqldump`. Si consiglia anche di valutare le prestazioni di `mysqldump` e i vantaggi offerti dal caricamento nel formato con testo delimitato. Un backup eseguito con testo delimitato crea un file di testo separato da tabulazioni per ciascuna tabella eliminata. Per ridurre il tempo di importazione del database, puoi caricare questi file in parallelo con il comando `LOAD DATA LOCAL INFILE`. Per ulteriori informazioni, consulta [Fase 5: Caricamento dei dati](mysql-importing-data-any-source.md#mysql-importing-data-any-source-load-data) nella procedura Importazione di dati da qualsiasi origine. Prima di iniziare l’operazione di backup, imposta le opzioni di replica nel database MySQL da copiare in Amazon RDS. Le opzioni di replica includono l’attivazione del log binario e l’impostazione di un ID server univoco. L'impostazione di tali opzioni porta il server ad avviare la registrazione delle transazioni del database e lo prepara per diventare l'istanza di replica di origine in una fase successiva del processo. Assicurati di essere a conoscenza dei seguenti suggerimenti e considerazioni: + Utilizzare l'opzione `--single-transaction` con `mysqldump` perché esegue il dump di uno stato coerente del database. Per garantire un file di dump valido, non eseguire istruzioni DDL (Data Definition Language) durante l'esecuzione di `mysqldump`. È possibile pianificare una finestra di manutenzione per queste operazioni. + Escludi gli schemi seguenti dal file di dump: + `sys` + `performance_schema` + `information_schema` Per impostazione predefinita, l'utility `mysqldump` esclude questi schemi. + Se devi migrare utenti e privilegi, prendi in considerazione l'utilizzo di uno strumento che genera il linguaggio di controllo dei dati (DCL) per ricrearli, come l'utilità. [pt-show-grants](https://www.percona.com/doc/percona-toolkit/LATEST/pt-show-grants.html) ### Per impostare le opzioni di autenticazione 1. Modificare il file `my.cnf`. Il file si trova in genere in `/etc`. ``` sudo vi /etc/my.cnf ``` Aggiungere le opzioni `log_bin` e `server_id` alla sezione `[mysqld]`. L'opzione `log_bin` fornisce un identificatore di nome file per i file di log binari. L'opzione `server_id` fornisce un identificatore univoco per il server in relazioni master-replica. L’esempio seguente mostra la sezione `[mysqld]` aggiornata di un file `my.cnf`: ``` [mysqld] log-bin=mysql-bin server-id=1 ``` Per ulteriori informazioni, consulta [Setting the Replication Source Configuration](https://dev.mysql.com/doc/refman/8.4/en/replication-howto-masterbaseconfig.html) nella documentazione MySQL. 1. Per la replica con un cluster di database Multi-AZ, imposta `ENFORCE_GTID_CONSISTENCY` e il parametro `GTID_MODE` su `ON`. ``` mysql> SET @@GLOBAL.ENFORCE_GTID_CONSISTENCY = ON; ``` ``` mysql> SET @@GLOBAL.GTID_MODE = ON; ``` Queste impostazioni non sono necessarie per la replica con un'istanza database. 1. Riavvia il servizio `mysql`. ``` sudo service mysqld restart ``` ### Per creare una copia di backup del database esistente 1. Creare un backup dei dati con l'utility `mysqldump`, specificando SQL o testo delimitato. Per MySQL 8.0.25 e versioni precedenti, specifica `--master-data=2` per creare un file di backup da utilizzare per avviare la replica tra i server. Per MySQL 8.0.26 e versioni successive, specifica `--source-data=2` per creare un file di backup da utilizzare per avviare la replica tra i server. Per ulteriori informazioni, consulta [mysqldump – A Database Backup Program](https://dev.mysql.com/doc/refman/8.4/en/mysqldump.html) nella documentazione MySQL. Per migliorare le prestazioni e garantire l’integrità dei dati, utilizza le opzioni `--order-by-primary` e `--single-transaction` per `mysqldump`. Per non includere il database del sistema MySQL nel backup, non utilizzare l’opzione `--all-databases` con `mysqldump`. Per ulteriori informazioni, consulta [Creating a Data Snapshot Using mysqldump](https://dev.mysql.com/doc/mysql-replication-excerpt/8.0/en/replication-howto-mysqldump.html) nella documentazione MySQL. Se necessario, utilizza `chmod` per avere la certezza che sia possibile scrivere nella directory in cui viene creato il file di backup. **Importante** In Windows, eseguire la finestra di comando come amministratore. + Per generare un output SQL, utilizza il comando seguente: Per Linux, macOS o Unix: ``` sudo mysqldump \ --databases database_name \ --master-data=2 \ --single-transaction \ --order-by-primary \ -r backup.sql \ -u local_user \ -ppassword ``` **Nota** Come best practice per la sicurezza, specifica credenziali diverse dai prompt mostrati nell’esempio. Per Windows: ``` mysqldump ^ --databases database_name ^ --master-data=2 ^ --single-transaction ^ --order-by-primary ^ -r backup.sql ^ -u local_user ^ -ppassword ``` **Nota** Come best practice per la sicurezza, specifica credenziali diverse dai prompt mostrati nell’esempio. + Per generare un output in testo delimitato, utilizza il comando seguente: Per Linux, macOS o Unix: ``` sudo mysqldump \ --tab=target_directory \ --fields-terminated-by ',' \ --fields-enclosed-by '"' \ --lines-terminated-by 0x0d0a \ database_name \ --master-data=2 \ --single-transaction \ --order-by-primary \ -ppassword ``` Per Windows: ``` mysqldump ^ --tab=target_directory ^ --fields-terminated-by "," ^ --fields-enclosed-by """ ^ --lines-terminated-by 0x0d0a ^ database_name ^ --master-data=2 ^ --single-transaction ^ --order-by-primary ^ -ppassword ``` **Nota** Come best practice per la sicurezza, specifica credenziali diverse dai prompt mostrati nell’esempio. Eventuali procedure, trigger, funzioni o eventi devono essere creati manualmente nel database Amazon RDS. Se il database da copiare dovesse contenere questi tipi di oggetti, dovrai escluderli al momento di eseguire `mysqldump`. A tale scopo, includi gli argomenti seguenti con il comando `mysqldump`: `--routines=0` `--triggers=0` `--events=0` Per MySQL 8.0.22 e versioni precedenti, quando si `mysqldump` esegue e si specifica il formato con testo delimitato, viene restituito un commento `CHANGE MASTER TO`. Tale commento contiene il nome e la posizione del file log principale. Per MySQL 8.0.23 e versioni successive, quando si esegue `mysqldump` nel formato con testo delimitato, viene restituito un commento `CHANGE REPLICATION SOURCE TO`. Tale commento contiene il nome e la posizione del file di log di origine. Se l’istanza esterna è diversa da MySQL 8.0.23 e versioni successive, annota i valori per `MASTER_LOG_FILE` e `MASTER_LOG_POS`. Questi valori sono necessari durante l'impostazione della replica. L’output seguente viene restituito per MySQL 8.0.22 e versioni precedenti: ``` -- Position to start replication or point-in-time recovery from -- -- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.000031', MASTER_LOG_POS=107; ``` L’output seguente viene restituito per MySQL 8.0.23 e versioni successive: ``` -- Position to start replication or point-in-time recovery from -- -- CHANGE SOURCE TO SOURCE_LOG_FILE='mysql-bin-changelog.000031', SOURCE_LOG_POS=107; ``` Per MySQL 8.0.22 e versioni precedenti, se si utilizza il formato SQL è possibile ottenere il nome e la posizione del file di log principale nel commento `CHANGE MASTER TO` nel file di backup. Per MySQL 8.0.23 e versioni successive, se si utilizza il formato SQL è possibile ottenere il nome e la posizione del file di log principale nel commento `CHANGE REPLICATION SOURCE TO` nel file di backup. 1. Comprimi i dati copiati per ridurre la quantità di risorse di rete necessarie per copiare i dati nell'istanza database Amazon RDS. Annota la dimensione del file di backup. Questa informazione è necessaria per determinare le dimensioni dell'istanza Amazon EC2 da creare. Al termine, comprimere il file di backup con GZIP o un'altra utility simile. + Per comprimere un output SQL, utilizza il comando seguente: ``` gzip backup.sql ``` + Per comprimere un output in testo delimitato, utilizza il comando seguente: ``` tar -zcvf backup.tar.gz target_directory ``` ## Attività 2: creazione di un’istanza Amazon EC2 e copia del database compresso La copia del file di backup del database compresso in un'istanza Amazon EC2 richiede una quantità di risorse di rete inferiore rispetto alla copia diretta di dati non compressi da un'istanza database a un'altra. Quando i dati sono presenti in Amazon EC2, è possibile copiarli direttamente nell’istanza database MySQL in uso. Per risparmiare sul costo delle risorse di rete, l'istanza Amazon EC2 deve essere la Regione AWS stessa dell'istanza Amazon RDS DB. Se l’istanza Amazon EC2 si trova nella stessa Regione AWS del database Amazon RDS, è minore anche la latenza di rete durante l’importazione. Il seguente diagramma mostra la copia del backup del database in un’istanza Amazon EC2. ![\[Flusso di lavoro che mostra la copia del backup del database in un’istanza Amazon EC2.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/images/MigrateMySQLToRDS_3.png) ### Per creare un'istanza Amazon EC2 e copiare i dati 1. Nel luogo in Regione AWS cui prevedi di creare il database Amazon RDS, crea un cloud privato virtuale (VPC), un gruppo di sicurezza VPC e una sottorete VPC. Verificare che le regole in entrata del gruppo di sicurezza VPC consentano agli indirizzi IP necessari per l'applicazione di connettersi ad AWS. È possibile specificare un intervallo di indirizzi IP, ad esempio `203.0.113.0/24`, oppure un altro gruppo di sicurezza VPC. Puoi utilizzare la [console Amazon VPC](https://console.aws.amazon.com/vpc) per creare e gestire VPCs sottoreti e gruppi di sicurezza. Per ulteriori informazioni, consulta [Nozioni di base su Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html#getting-started) nella *Guida per l’utente di Amazon Virtual Private Cloud*. 1. Apri la [console Amazon EC2](https://console.aws.amazon.com/ec2) e scegli di contenere sia Regione AWS l'istanza Amazon EC2 che il database Amazon RDS. Avviare un'istanza di Amazon EC2 utilizzando il VPC, la sottorete e il gruppo di sicurezza creati nella fase 1. Assicurarsi di selezionare un tipo di istanza con spazio di storage sufficiente per il file di backup del database decompresso. Per informazioni sulle istanze Amazon EC2, consulta [Nozioni di base su Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html) nella *Guida per l’utente di Amazon Elastic Compute Cloud*. 1. Per connetterti al database Amazon RDS dall'istanza Amazon EC2, modifica il gruppo di sicurezza VPC. Aggiungere una regola in entrata specificando l'indirizzo IP privato e l'istanza EC2. L'indirizzo IP privato è indicato nella scheda **Details (Dettagli)** del riquadro **Instance (Istanza)** della finestra della console EC2. Per modificare il gruppo di sicurezza VPC e aggiungere una regola in entrata, selezionare **Security Groups (Gruppi di sicurezza)** nel riquadro di navigazione della console di EC2, selezionare il gruppo di sicurezza e aggiungere una regola in entrata per MySQL/Aurora specificando l'indirizzo IP privato dell'istanza EC2. Per ulteriori informazioni sull’aggiunta di una regola in entrata a un gruppo di sicurezza VPC, consulta [Regole del gruppo di sicurezza](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html) nella *Guida per l’utente di Amazon Virtual Private Cloud*. 1. Copiare il file compresso con il backup del database dal sistema locale all'istanza Amazon EC2. Se necessario, utilizza `chmod` per ottenere l’autorizzazione di scrittura per la directory di destinazione dell’istanza Amazon EC2. Il file può essere copiato con `scp` oppure con un client Secure Shell (SSH). Di seguito è riportato un comando `scp` di esempio: ``` scp -r -i key pair.pem backup.sql.gz ec2-user@EC2 DNS:/target_directory/backup.sql.gz ``` **Importante** Quando si copiano dati sensibili, utilizzare un protocollo di trasferimento di rete sicuro. 1. Eseguire la connessione all'istanza Amazon EC2 e installare gli ultimi aggiornamenti e gli strumenti del clien MySQL mediante i seguenti comandi: ``` sudo yum update -y sudo yum install mysql -y ``` Per ulteriori informazioni, consulta [Connessione all’istanza](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html#ec2-connect-to-instance-linux) per le istanze Linux nella *Guida per l’utente di Amazon Elastic Compute Cloud*. **Importante** Questo esempio installa il client MySQL su una Amazon Machine Image (AMI) per una distribuzione Amazon Linux. L’esempio non si applica all’installazione del client MySQL su una distribuzione diversa, come Ubuntu o Red Hat Enterprise Linux. Per informazioni sull’installazione di MySQL, consulta [Installing MySQL](https://dev.mysql.com/doc/refman/8.4/en/installing.html) nella documentazione MySQL. 1. Durante la connessione all'istanza Amazon EC2 decomprimere il file di backup del database. I comandi seguenti sono esempi. + Per decomprimere l'output SQL, utilizzare il comando seguente: ``` gzip backup.sql.gz -d ``` + Per decomprimere un output in testo delimitato, utilizzare il comando seguente: ``` tar xzvf backup.tar.gz ``` ## Attività 3: creazione di un database MySQL e importazione dei dati dall’istanza Amazon EC2 La creazione di un’istanza database RDS per MySQL o di un cluster di database Multi-AZ RDS per MySQL nella stessa Regione AWS dell’istanza Amazon EC2 consente di importare il file di backup del database da Amazon EC2 più velocemente rispetto a Internet. Il seguente diagramma mostra l’importazione del backup da un’istanza Amazon EC2 in un database MySQL. ![\[Flusso di lavoro che mostra l’importazione del backup dall’istanza EC2 nel database MySQL.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/images/MigrateMySQLToRDS_4.png) ### Per creare un database MySQL e importare i dati 1. Determina la classe di istanza database e la quantità di spazio di archiviazione necessaria per supportare il carico di lavoro previsto per il database Amazon RDS. Come parte di questo processo, è necessario valutare la quantità di spazio richiesta e la capacità di elaborazione per le procedure di caricamento dati. Valuta anche gli elementi necessari per gestire il carico di lavoro di produzione. È possibile produrre una stima sulla base delle dimensioni e delle risorse del database MySQL di origine. Per ulteriori informazioni, consulta [Classi di istanze DB ](Concepts.DBInstanceClass.md). 1. Crea un'istanza DB o un cluster DB Multi-AZ nel contenitore Regione AWS che contiene la tua istanza Amazon EC2. Per creare un cluster di database Multi-AZ RDS per MySQL, segui le istruzioni in [Creazione di un cluster di database Multi-AZ per Amazon RDS](create-multi-az-db-cluster.md). Per creare un’istanza database RDS per MySQL, segui le istruzioni in [Creazione di un'istanza database Amazon RDS](USER_CreateDBInstance.md) e attieniti alle seguenti linee guida: + Specifica una versione del motore di database compatibile con l’istanza database di origine. + Specifica lo stesso cloud privato virtuale (VPC) e lo stesso gruppo di sicurezza VPC dell'istanza Amazon EC2. Questo approccio garantisce che l’istanza Amazon EC2 e l’istanza Amazon RDS siano visibili una all’altra in rete. Assicurati che l'istanza database sia accessibile pubblicamente. Per impostare la replica con il database di origine, come descritto in una sezione seguente, l’istanza database deve essere accessibile pubblicamente. + Non configurare più zone di disponibilità, retention dei backup o repliche di lettura fino a quando non è stato importato il backup del database. Al termine dell'importazione, puoi configurare le varie zone di disponibilità e la conservazione dei backup per l'istanza di produzione. 1. Esamina le opzioni di configurazione predefinite per il database Amazon RDS. Se il gruppo di parametri predefinito per il database non include le opzioni di configurazione desiderate, cercane uno che le contenga oppure crea un gruppo di parametri nuovo. Per ulteriori informazioni sulla creazione di un gruppo di parametri, consulta [Gruppi di parametri per Amazon RDS](USER_WorkingWithParamGroups.md). 1. Connettiti al nuovo database Amazon RDS come utente master. Crea gli utenti necessari per supportare gli amministratori, le applicazioni e i servizi che devono accedere all’istanza database. Il nome host per il database Amazon RDS corrisponde al valore di **Endpoint** per l’istanza database senza il numero di porta, ad esempio `mysampledb.123456789012.us-west-2.rds.amazonaws.com`. Il valore dell’endpoint è disponibile nei dettagli del database nella console Amazon RDS. 1. Esegui la connessione all'istanza Amazon EC2. Per ulteriori informazioni, consulta [Connessione all’istanza](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html#ec2-connect-to-instance-linux) per le istanze Linux nella *Guida per l’utente di Amazon Elastic Compute Cloud*. 1. Connettiti al database Amazon RDS come host remoto dall'istanza Amazon EC2 usando il comando `mysql`. Il comando seguente è un esempio: ``` mysql -h host_name -P 3306 -u db_master_user -p ``` *host\$1name*È l'endpoint del database Amazon RDS. 1. Al prompt `mysql`, esegui il comando `source` e passa il nome del file di dump del database. Il comando carica i dati nell’istanza database Amazon RDS. + Per il formato SQL, utilizza il comando seguente: ``` mysql> source backup.sql; ``` + Per il formato con testo delimitato, crea innanzitutto il database se non utilizzi il database predefinito creato al momento dell’impostazione del database Amazon RDS, ``` mysql> create database database_name; mysql> use database_name; ``` quindi crea le tabelle ``` mysql> source table1.sql mysql> source table2.sql etc... ``` e infine importa i dati. ``` mysql> LOAD DATA LOCAL INFILE 'table1.txt' INTO TABLE table1 FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '0x0d0a'; mysql> LOAD DATA LOCAL INFILE 'table2.txt' INTO TABLE table2 FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '0x0d0a'; etc... ``` Per migliorare le prestazioni, puoi eseguire queste operazioni in parallelo da più connessioni, in modo che tutte le tabelle vengano create e caricate contemporaneamente. **Nota** Se nel dump iniziale della tabella sono state utilizzate opzioni di formattazione dati con `mysqldump`, è necessario utilizzare le stesse opzioni con `LOAD DATA LOCAL INFILE` per assicurare una corretta interpretazione del contenuto del file di dati. 1. Esegui una semplice query `SELECT` in una o due tabelle del database importato, per verificare che l’operazione sia stata eseguita correttamente. Se non hai più bisogno dell'istanza Amazon EC2 utilizzata in questa procedura, interrompi l'istanza EC2 per ridurre l'utilizzo delle risorse. AWS Per terminare un’istanza EC2, consulta [Terminare un’istanza](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html#terminating-instances-console) nella *Guida per l’utente di Amazon Elastic Compute Cloud*. ## Attività 4: replica dei dati dal database esterno al nuovo database Amazon RDS È probabile che il database di origine sia stato aggiornato durante la copia e il trasferimento dei dati nel database MySQL. Pertanto, puoi utilizzare la replica per portare il database copiato con il database up-to-date di origine. ![\[Flusso di lavoro che mostra la replica dei dati dal database MySQL esterno al database in Amazon RDS.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/images/MigrateMySQLToRDS_5.png) Le autorizzazioni necessarie per avviare la replica in un database Amazon RDS sono limitate e non disponibili per l’utente master di Amazon RDS. Per questo motivo, utilizza la stored procedure Amazon RDS appropriata per la versione principale del motore: + [mysql\$1rds\$1set\$1external\$1master (RDS per MySQL versioni principali 8.0 e precedenti)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) + [mysql.rds\$1set\$1external\$1source (RDS per MySQL versioni principali 8.4 e successive)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source) + [mysql.rds\$1set\$1external\$1master\$1gtid](mysql_rds_set_external_master_gtid.md) per configurare la replica e [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) per avviarla ### Per avviare la replica Nell’Attività 1, [quando si impostano le opzioni di replica](#mysql-importing-data-reduced-downtime-set-replication-options) si attiva la registrazione di log binari e si imposta un ID server univoco per il database di origine. Ora è possibile impostare il database Amazon RDS come replica, utilizzando il database attivo come istanza di replica di origine. 1. Nella console Amazon RDS aggiungi l’indirizzo IP del server che ospita il database di origine al gruppo di sicurezza VPC per il database Amazon RDS. Per ulteriori informazioni sui gruppi di sicurezza VPC, consulta [Configurazione delle regole per i gruppi di sicurezza](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-security-group-rules.html) nella *Guida per l’utente di Amazon Virtual Private Cloud*. Potrebbe essere necessario configurare anche la rete locale per consentire le connessioni dall’indirizzo IP del database Amazon RDS, in modo da comunicare con l’istanza di origine. Per individuare l’indirizzo IP del database Amazon RDS, utilizza il comando `host`: ``` host host_name ``` *host\$1name*È il nome DNS dell'endpoint del database Amazon RDS, ad esempio. `myinstance.123456789012.us-east-1.rds.amazonaws.com` Il valore dell’endpoint è disponibile nei dettagli dell’istanza database nella console Amazon RDS. 1. Utilizzando il client scelto, eseguire la connessione all'istanza di origine e creare un utente da utilizzare per la replica. Questo account viene utilizzato unicamente per la replica e deve essere limitato al dominio personale per aumentare la sicurezza. Il comando seguente è un esempio: ``` CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password'; ``` **Nota** Specifica credenziali diverse dai prompt mostrati qui come best practice per la sicurezza. 1. Per l'istanza di origine, concedere i privilegi `REPLICATION CLIENT` e `REPLICATION SLAVE` all'utente di replica. Per concedere ad esempio i privilegi `REPLICATION CLIENT` e `REPLICATION SLAVE` su tutti i database per l'utente "`repl_user`" del proprio dominio, eseguire questo comando: ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com'; ``` 1. Definisci il database Amazon RDS come replica. Connettiti al database Amazon RDS come utente master e identifica il database di origine come istanza di replica di origine con la stored procedure di Amazon RDS appropriata: + [mysql\$1rds\$1set\$1external\$1master (RDS per MySQL versioni principali 8.0 e precedenti)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) + [mysql.rds\$1set\$1external\$1source (RDS per MySQL versioni principali 8.4 e successive)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source) Se si dispone di un file di backup in formato SQL, utilizza il nome e la posizione del file di log principale, recuperati nella fase 4. Se invece è stato utilizzato il formato con testo delimitato, usa il nome e la posizione determinati al momento di creare i file di backup. I comandi seguenti sono esempi: **MySQL 8.4 e versioni successive** ``` CALL mysql.rds_set_external_source ('myserver.mydomain.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 1); ``` **MySQL 8.0 e versioni precedenti** ``` CALL mysql.rds_set_external_master ('myserver.mydomain.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 1); ``` **Nota** Specifica credenziali diverse dai prompt mostrati qui come best practice per la sicurezza. 1. Nel database Amazon RDS, per avviare la replica esegui questo comando che utilizza la stored procedure [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication): ``` CALL mysql.rds_start_replication; ``` 1. Nel database Amazon RDS esegui il comando [SHOW REPLICA STATUS](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html) per determinare quando la replica è aggiornata con l’istanza di replica di origine. I risultati del comando `SHOW REPLICA STATUS` includono il campo `Seconds_Behind_Master`. Quando il campo `Seconds_Behind_Master` restituisce 0, la replica è aggiornata con l’istanza di replica di origine. **Nota** Versioni precedenti di MySQL utilizzate `SHOW SLAVE STATUS` al posto di `SHOW REPLICA STATUS`. Se si utilizza una versione MySQL prima della 8.0.23, utilizzare `SHOW SLAVE STATUS`. 1. Dopo aver aggiornato il database Amazon RDS, attiva i backup automatici per ripristinare il database, qualora sia necessario. È possibile attivare o modificare i backup automatici per il database Amazon RDS tramite la [console Amazon RDS](https://console.aws.amazon.com/rds/). Per ulteriori informazioni, consulta [Introduzione ai backup](USER_WorkingWithAutomatedBackups.md). ## Attività 5: reindirizzamento di un’applicazione attiva all’istanza Amazon RDS Dopo aver aggiornato il database MySQL con l’istanza di replica di origine, è possibile aggiornare l’applicazione attiva per utilizzare l’istanza Amazon RDS. ![\[Flusso di lavoro che mostra l’arresto della replica e l’indirizzamento dell’applicazione attiva al database in Amazon RDS.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/images/MigrateMySQLToRDS_6.png) ### Per reindirizzare l’applicazione attiva al database MySQL e arrestare la replica 1. Per aggiungere il gruppo di sicurezza VPC per il database Amazon RDS, aggiungi l’indirizzo IP del server che ospita l’applicazione. Per ulteriori informazioni sui gruppi di sicurezza VPC, consulta [Configurazione delle regole per i gruppi di sicurezza](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-security-group-rules.html) nella *Guida per l’utente di Amazon Virtual Private Cloud*. 1. Verifica che il risultato del campo `Seconds_Behind_Master` nel comando [SHOW REPLICA STATUS](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html) sia 0, indicazione che la replica è aggiornata con l’istanza di replica di origine. ``` SHOW REPLICA STATUS; ``` **Nota** Versioni precedenti di MySQL utilizzate `SHOW SLAVE STATUS` al posto di `SHOW REPLICA STATUS`. Se si utilizza una versione MySQL prima della 8.0.23, utilizzare `SHOW SLAVE STATUS`. 1. Chiudere tutte le connessioni all'origine quando le loro transazioni sono complete. 1. Aggiorna l'applicazione per usare il database Amazon RDS. In genere, l'aggiornamento prevede la modifica delle impostazioni di connessione per identificare il nome host e la porta del database Amazon RDS, l'account utente e la password per eseguire la connessione e il database da utilizzare. 1. Effettua la connessione all'istanza database. Per un cluster database multi-AZ, connettiti all'istanza database di scrittura. 1. Arresta la replica per l’istanza Amazon RDS eseguendo questo comando che utilizza la stored procedure [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication): ``` CALL mysql.rds_stop_replication; ``` 1. Reimposta la configurazione della replica in modo che l’istanza non venga più identificata come replica utilizzando la stored procedure Amazon RDS appropriata nel database Amazon RDS: + [mysql\$1rds\$1reset\$1external\$1master (RDS per MySQL versioni principali 8.0 e precedenti)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_master) + [mysql.rds\$1reset\$1external\$1source (RDS per MySQL versioni principali 8.4 e successive)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_source) **MySQL 8.4 e versioni successive** ``` CALL mysql.rds_reset_external_source; ``` **MySQL 8.0 e versioni precedenti** ``` CALL mysql.rds_reset_external_master; ``` 1. Attivare le caratteristiche aggiuntive di Amazon RDS, quali il supporto Multi-AZ e le repliche di lettura. Per ulteriori informazioni, consultare [Configurazione e gestione di un’implementazione Multi-AZ per Amazon RDS](Concepts.MultiAZ.md) e [Uso delle repliche di lettura dell'istanza database](USER_ReadRepl.md). # Importazione di dati da qualsiasi origine in un’istanza database Amazon RDS per MySQL Amazon RDS consente di migrare dati di MySQL esistenti da qualsiasi origine a un’istanza database RDS per MySQL. È possibile trasferire dati da database on-premises, altri provider cloud o istanze database RDS per MySQL esistenti all’istanza database RDS per MySQL di destinazione. La funzionalità permette di consolidare i database, implementare soluzioni di disaster recovery o eseguire il passaggio da database autogestiti. Gli scenari più comuni includono il passaggio da server MySQL in hosting autonomo a istanze database Amazon RDS completamente gestite, il consolidamento di più database MySQL in una singola istanza database o la creazione di ambienti di test con dati di produzione. Le seguenti sezioni forniscono step-by-step istruzioni per importare i dati MySQL utilizzando metodi `mysqldump` come file di backup o replica. ## Fase 1: Creazione di file flat contenenti i dati da caricare Per salvare i dati da caricare, utilizza un formato comune, come ad esempio valori separati da virgola (CSV). Ciascuna tabella deve possedere il proprio file. Non è possibile combinare i dati di più tabelle nello stesso file. Devi fornire a ciascun file lo stesso nome della tabella corrispondente. Il file può avere qualsiasi estensione. Ad esempio, se il nome della tabella è `sales`, il nome del file potrebbe essere `sales.csv` o `sales.txt`. Se possibile, ordina i dati in base alla chiave primaria della tabella da caricare. In questo modo i tempi di caricamento risultano significativamente più rapidi e si riduce il consumo di spazio su disco. La velocità e l'efficienza di questa procedura dipende dalla capacità di mantenere contenute le dimensioni dei file. Se le dimensioni di un qualsiasi file (non compresso) superano 1 GiB, suddividilo in più file da caricare separatamente. Nei sistemi di tipo Unix (incluso Linux), puoi utilizzare il comando `split`. Ad esempio, il comando seguente divide il file `sales.csv` in vari file con dimensioni inferiori a 1 GiB. Le divisioni vengono effettuate solo sulle interruzioni di riga (-C 1024m). I nomi dei nuovi file includono suffissi numerici crescenti. Il comando seguente genera file con nomi come `sales.part_00` e `sales.part_01`. ``` split -C 1024m -d sales.csv sales.part_ ``` Utility simili sono disponibili anche per altri sistemi operativi. È possibile archiviare i file flat ovunque. Tuttavia, quando si caricano i dati nella [Fase 5](#mysql-importing-data-any-source-load-data), è necessario invocare la shell `mysql` dalla stessa posizione in cui si trovano i file o utilizzare il percorso assoluto dei file quando si esegue `LOAD DATA LOCAL INFILE`. ## Fase 2: arrestare le applicazioni che accedono all’istanza database di destinazione Prima di avviare il caricamento di grandi quantità di dati, arresta le attività di tutte le applicazioni che accedono all’istanza database in cui intendi eseguire il caricamento. Questa operazione è particolarmente consigliata se le altre sessioni modificano le tabelle caricate o quelle di riferimento. In questo modo, puoi ridurre i rischi di violazione dei vincoli e ottimizzare le prestazioni durante il caricamento. Inoltre, diventa possibile ripristinare l'istanza database al punto immediatamente precedente il caricamento, senza perdere le modifiche apportate dai processi che non sono coinvolti nell'operazione di caricamento. Ovviamente, ci sono casi in cui l'esecuzione di questa operazione risulta impossibile o poco pratica. Se puoi evitare che alcune applicazioni accedano all'istanza database prima del caricamento, prendi tutte le misure necessarie per assicurare la disponibilità e l'integrità dei dati. Tali misure dipendono in larga parte dal tipo specifico di utilizzo e dai requisiti del sito. ## Fase 3: Creazione di una snapshot DB Se desideri caricare i dati in una nuova istanza database priva di dati, puoi ignorare questa parte. In caso contrario, si consiglia di creare snapshot di database dell’istanza database di destinazione Amazon RDS immediatamente prima e dopo il caricamento dei dati. Gli snapshot di database di Amazon RDS sono backup completi dell’istanza database che consentono di ripristinarla in uno stato noto. Quando si avvia uno snapshot DB, I/O le operazioni sull'istanza DB vengono momentaneamente sospese durante il backup del database. Creando una snapshot DB immediatamente prima di caricare i dati ti consente di ripristinare il database allo stato precedente il caricamento, se fosse necessario. Una snapshot DB ottenuta immediatamente dopo il caricamento consente di non dover caricare nuovamente i dati in caso di problemi. È inoltre possibile utilizzare gli snapshot di database dopo il caricamento per importare dati in nuove istanze database. L'esempio seguente esegue il AWS CLI [create-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-snapshot.html)comando per creare uno snapshot DB dell'`AcmeRDS`istanza e assegnare allo snapshot DB l'identificatore. `"preload"` Per Linux, macOS o Unix: ``` aws rds create-db-snapshot \ --db-instance-identifier AcmeRDS \ --db-snapshot-identifier preload ``` Per Windows: ``` aws rds create-db-snapshot ^ --db-instance-identifier AcmeRDS ^ --db-snapshot-identifier preload ``` Puoi utilizzare anche la funzione di ripristino da snapshot DB per creare istanze database di prova in cui eseguire test o annullare modifiche apportate durante il caricamento. Ricorda che il ripristino di un database da una snapshot DB crea una nuova istanza database che, come tutte le istanze database, possiede un identificatore e un endpoint univoci. Per ripristinare l'istanza database senza modificare l'endpoint, devi innanzitutto eliminare l'istanza database, in modo da poter riutilizzare l'endpoint. Ad esempio, per creare un'istanza database in cui eseguire test di vario tipo, devi assegnare all'istanza database il proprio identificatore. Nell’esempio, l'identificatore è `AcmeRDS-2`". L'esempio si connette all'istanza database utilizzando l'endpoint associato a `AcmeRDS-2`. [Per ulteriori informazioni, vedere -db-snapshot. restore-db-instance-from](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html) Per Linux, macOS o Unix: ``` aws rds restore-db-instance-from-db-snapshot \ --db-instance-identifier AcmeRDS-2 \ --db-snapshot-identifier preload ``` Per Windows: ``` aws rds restore-db-instance-from-db-snapshot ^ --db-instance-identifier AcmeRDS-2 ^ --db-snapshot-identifier preload ``` Per riutilizzare l'endpoint esistente, innanzitutto elimina l'istanza database e fornisci al database ripristinato lo stesso identificatore. Per ulteriori informazioni, consulta [delete-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/delete-db-instance.html). L’esempio seguente crea uno snapshot di database finale dell’istanza database prima di eliminarla. Questo passaggio è facoltativo, ma è consigliato. Per Linux, macOS o Unix: ``` aws rds delete-db-instance \ --db-instance-identifier AcmeRDS \ --final-db-snapshot-identifier AcmeRDS-Final aws rds restore-db-instance-from-db-snapshot \ --db-instance-identifier AcmeRDS \ --db-snapshot-identifier preload ``` Per Windows: ``` aws rds delete-db-instance ^ --db-instance-identifier AcmeRDS ^ --final-db-snapshot-identifier AcmeRDS-Final aws rds restore-db-instance-from-db-snapshot ^ --db-instance-identifier AcmeRDS ^ --db-snapshot-identifier preload ``` ## Fase 4 (facoltativa): disattivare i backup automatici di Amazon RDS **avvertimento** Non disattivare i backup automatici se è necessario eseguire il ripristino. point-in-time La disattivazione dei backup automatici è utile per ottimizzare le prestazioni, ma non è indispensabile per il caricamento dei dati. La disattivazione dei backup automatici comporta l’eliminazione di tutti i backup esistenti. Di conseguenza, dopo aver disattivato i backup automatici, il point-in-time ripristino non è possibile. Gli snapshot DB manuali non sono influenzati dalla disattivazione dei backup automatici. Tutti gli snapshot DB esistenti rimangono disponibili per il ripristino. La disattivazione dei backup automatici velocizza il tempo di caricamento di circa il 25% e riduce la quantità di spazio richiesto. Se devi caricare dati in una nuova istanza database che non contiene altri dati, la disattivazione dei backup rappresenta un'ottima soluzione per velocizzare il caricamento ed evitare di occupare troppo spazio con i backup. Tuttavia, in alcuni casi, potresti pianificare di caricare i dati in un'istanza database che contiene già altri dati. In tal caso, soppesate i vantaggi della disattivazione dei backup rispetto all'impatto della perdita della capacità di esecuzione. point-in-time-recovery Per impostazione predefinita, i backup sono attivati per le istanze database (con un periodo di conservazione di un giorno). Per disabilitare i backup automatici, imposta il periodo di conservazione del backup su zero. Dopo il caricamento potrai riattivare i backup automatici impostando il periodo di conservazione su un valore diverso da zero. Per attivare o disattivare i backup, Amazon RDS arresta l’istanza database e la riavvia in modo da attivare o disattivare la registrazione di log MySQL. Esegui il AWS CLI `modify-db-instance` comando per impostare la conservazione dei backup su zero e applica immediatamente la modifica. Per impostare il periodo di retention su zero è necessario riavviare l'istanza database, quindi prima di continuare dovrai attendere il completamento del riavvio. Per ulteriori informazioni, consulta [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html). Per Linux, macOS o Unix: ``` aws rds modify-db-instance \ --db-instance-identifier AcmeRDS \ --apply-immediately \ --backup-retention-period 0 ``` Per Windows: ``` aws rds modify-db-instance ^ --db-instance-identifier AcmeRDS ^ --apply-immediately ^ --backup-retention-period 0 ``` Puoi controllare lo stato della tua istanza DB con il AWS CLI [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html)comando. Nell’esempio seguente viene visualizzato lo stato dell’istanza database `AcmeRDS`. ``` aws rds describe-db-instances --db-instance-identifier AcmeRDS --query "*[].{DBInstanceStatus:DBInstanceStatus}" ``` Quando lo stato dell’istanza database è `available`, si può passare alla fase successiva. ## Fase 5: Caricamento dei dati Per leggere le righe dai file flat nelle tabelle del database, usa l’istruzione `LOAD DATA LOCAL INFILE` MySQL. **Nota** È necessario invocare la shell `mysql` dalla stessa posizione in cui si trovano i file flat o utilizzare il percorso assoluto dei file quando si esegue `LOAD DATA LOCAL INFILE`. L’esempio seguente mostra come caricare i dati da un file denominato `sales.txt` in una tabella denominata `Sales` nel database: ``` mysql> LOAD DATA LOCAL INFILE 'sales.txt' INTO TABLE Sales FIELDS TERMINATED BY ' ' ENCLOSED BY '' ESCAPED BY '\\'; Query OK, 1 row affected (0.01 sec) Records: 1 Deleted: 0 Skipped: 0 Warnings: 0 ``` Per ulteriori informazioni sull’istruzione `LOAD DATA`, consulta [LOAD DATA Statement](https://dev.mysql.com/doc/refman/8.4/en/load-data.html) nella documentazione MySQL. ## Fase 6: riattivare i backup automatici di Amazon RDS Se nella [Fase 4](#mysql-importing-data-any-source-turn-off-automated-backups) sono stati disattivati, al termine del caricamento riattiva i backup automatici di Amazon RDS impostando il periodo di conservazione del backup sul valore originale. Come indicato nella Fase 4, Amazon RDS riavvia l’istanza database, interrompendo brevemente le attività. L'esempio seguente esegue il AWS CLI [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)comando per attivare i backup automatici per l'istanza `AcmeRDS` DB e impostare il periodo di conservazione su un giorno: Per Linux, macOS o Unix: ``` aws rds modify-db-instance \ --db-instance-identifier AcmeRDS \ --backup-retention-period 1 \ --apply-immediately ``` Per Windows: ``` aws rds modify-db-instance ^ --db-instance-identifier AcmeRDS ^ --backup-retention-period 1 ^ --apply-immediately ``` # Uso della replica MySQL in Amazon RDS Generalmente, per configurare la replica tra le istanze database di Amazon RDS si utilizzano repliche di lettura. Per informazioni generali sulle repliche di lettura, consulta [Uso delle repliche di lettura dell'istanza database](USER_ReadRepl.md). Per informazioni specifiche sull'uso di repliche di lettura in Amazon RDS per MySQL, consulta [Uso delle repliche di lettura MySQL](USER_MySQL.Replication.ReadReplicas.md). È possibile utilizzare gli identificatori di transazione globali (GTIDs) per la replica con RDS for MySQL. Per ulteriori informazioni, consulta [Utilizzo della replica basata su GTID](mysql-replication-gtid.md). Puoi anche configurare la replica tra un'istanza database RDS for MySQL e un'istanza MariaDB o MySQL esterna ad Amazon RDS. Per ulteriori informazioni sulla configurazione della replica con un'origine esterna, consulta [Configurazione della replica della posizione del file di log binario con un'istanza di origine esterna.](MySQL.Procedural.Importing.External.Repl.md). Per qualsiasi opzione di replica, puoi utilizzare la replica basata su riga, basata su istruzioni o quella mista. La replica basata su riga replica solamente le righe modificate che risultano da un'istruzione SQL. La replica basata su istruzioni replica l'intera istruzione SQL. La replica mista utilizza la replica basata su istruzione quando possibile, ma passa alla replica basata su riga quando vengono eseguite le istruzioni SQL che non sono sicure per la replica basata su istruzione. Nella maggior parte dei casi, si consiglia l'utilizzo della replica mista. Il formato di log binario dell'istanza database determina se la replica è basata su riga, su istruzione o è mista. Per informazioni sull'impostazione del formato di log binario, consulta [Configurazione di MySQL RDS per la registrazione binaria MySQL per database Single-AZ](USER_LogAccess.MySQL.BinaryFormat.md). **Nota** Puoi configurare la replica per l'importazione di database da un'istanza MariaDB o MySQL esterna ad Amazon RDS o per l'esportazione di database a tali istanze. Per ulteriori informazioni, consultare [Importazione dei dati in un database Amazon RDS per MySQL con tempo di inattività ridotto](mysql-importing-data-reduced-downtime.md) e [Esportazione di dati da un'istanza database MySQL tramite la replica](MySQL.Procedural.Exporting.NonRDSRepl.md). Dopo aver ripristinato l'istanza DB da un'istantanea o eseguito un point-in-time ripristino, è possibile visualizzare l'ultima posizione del binlog recuperata dal database di origine nella console RDS. In **Log ed eventi**, immettere **Binlog**. La posizione del log binario viene visualizzata in **Note di sistema**. **Topics** + [ # Uso delle repliche di lettura MySQL ](USER_MySQL.Replication.ReadReplicas.md) + [ # Utilizzo della replica basata su GTID ](mysql-replication-gtid.md) + [ # Configurazione della replica della posizione del file di log binario con un'istanza di origine esterna. ](MySQL.Procedural.Importing.External.Repl.md) + [ # Configurazione multi-source-replication per Amazon RDS for MySQL ](mysql-multi-source-replication.md) # Uso delle repliche di lettura MySQL Questa sezione contiene informazioni specifiche sull'utilizzo delle repliche di lettura su RDS per MySQL. Per informazioni generali sulle repliche di lettura e istruzioni su come usarle, consulta [Uso delle repliche di lettura dell'istanza database](USER_ReadRepl.md). Per ulteriori informazioni sulle repliche di lettura MySQL, consulta gli argomenti riportati di seguito. + [Configurazione dei filtri di replica con MySQL](USER_MySQL.Replication.ReadReplicas.ReplicationFilters.md) + [Configurazione della replica ritardata con MySQL](USER_MySQL.Replication.ReadReplicas.DelayReplication.md) + [Aggiornamento di repliche di lettura con MySQL](USER_MySQL.Replication.ReadReplicas.Updates.md) + [Utilizzo di implementazioni Multi-AZ di repliche di lettura con MySQL](USER_MySQL.Replication.ReadReplicas.MultiAZ.md) + [Utilizzo di repliche di lettura a cascata con RDS per MySQL](USER_MySQL.Replication.ReadReplicas.Cascading.md) + [Monitoraggio del ritardo di replica per le repliche di lettura MySQL](USER_MySQL.Replication.ReadReplicas.Monitor.md) + [Avvio e arresto della replica con repliche di lettura MySQL](USER_MySQL.Replication.ReadReplicas.StartStop.md) + [Risoluzione dei problemi relativi a una replica di lettura MySQL](USER_ReadRepl.Troubleshooting.md) ## Configurazione delle repliche di lettura con MySQL Prima di poter utilizzare un'istanza database MySQL come un'origine delle replica, assicurati di abilitare i backup automatici sull'istanza database di origine. A questo scopo, imposta il periodo di retention dei backup su un valore diverso da zero. Questo requisito si applica anche a una replica di lettura che rappresenta l'istanza database di origine per un'altra replica di lettura. I backup automatici vengono solo supportati per le repliche di lettura che eseguono qualsiasi versione di MySQL. Puoi configurare la replica in base alle coordinate del log binario per un'istanza database MySQL. È possibile configurare la replica utilizzando gli ID globali di transazione (GTID) nelle seguenti versioni: + RDS per MySQL versione 5.7.44 e versioni successive alla 5.7 + RDS per MySQL versione 8.0.28 e versioni successive alla 8.0 + RDS per MySQL versione 8.4.3 e versioni successive alla 8.4 Per ulteriori informazioni, consulta [Utilizzo della replica basata su GTID](mysql-replication-gtid.md). È possibile creare fino a 15 repliche di lettura da un'istanza database nella stessa regione. Per un efficace funzionamento della replica, ciascuna replica di lettura dovrebbe avere la stessa quantità di risorse di calcolo e storage dell'istanza database di origine. Se si dimensiona l'istanza database di origine, si devono dimensionare anche le repliche di lettura. RDS per MySQL supporta le repliche di lettura a cascata. Per informazioni su come configurare le repliche di lettura a cascata, consulta [Utilizzo di repliche di lettura a cascata con RDS per MySQL](USER_MySQL.Replication.ReadReplicas.Cascading.md). Puoi eseguire più operazioni di creazione ed eliminazione di repliche di lettura simultanee che fanno riferimento alla stessa istanza database di origine. Quando esegui queste operazioni, rimani entro il limite delle 15 repliche di lettura per ogni istanza di origine. Una replica in lettura di un'istanza DB MySQL non può utilizzare una versione del motore DB inferiore rispetto alla sua istanza DB di origine. ### Preparazione delle istanze database MySQL che utilizzano MyISAM Se l'istanza database MySQL utilizza un motore non transazionale come MyISAM, devi eseguire la seguente procedura per configurare correttamente la replica di lettura. Questa procedura è necessaria per verificare che la replica di lettura contenga una copia coerente dei dati. Non è invece necessaria alcuna procedura se tutte le tabelle usano un motore transazionale come InnoDB. 1. Arresta tutte le operazioni DML (Data Manipulation Language) e DDL (Data Definition Language) sulle tabelle non transazionali nell'istanza database di origine e attendi il loro completamento. Le istruzioni SELECT possono restare in esecuzione. 1. Scarica e blocca le tabelle nell'istanza database di origine. 1. Crea una replica di lettura usando uno dei metodi nelle seguenti sezioni. 1. Verifica lo stato di avanzamento della creazione della replica di lettura utilizzando, ad esempio, l'operazione API `DescribeDBInstances`. Dopo che la replica di lettura è disponibile, sblocca le tabelle dell'istanza database di origine e ripristina le normali operazioni del database. # Configurazione dei filtri di replica con MySQL Puoi utilizzare i filtri di replica per specificare quali database e tabelle vengono replicati con una replica di lettura. I filtri di replica possono includere database e tabelle nella replica o escluderli dalla replica. Di seguito sono riportati alcuni casi d'uso per i filtri di replica: + Per ridurre le dimensioni di una replica di lettura. Con il filtro di replica è possibile escludere i database e le tabelle che non sono necessari nella replica di lettura. + Per escludere database e tabelle dalle repliche di lettura per motivi di sicurezza. + Per replicare database e tabelle diversi per casi d'uso specifici in repliche di lettura diverse. Ad esempio, è possibile utilizzare repliche di lettura specifiche per l'analisi o la condivisione. + Per un'istanza DB che ha repliche di lettura in diversi Regioni AWS, per replicare database o tabelle diversi in diversi. Regioni AWS **Nota** Puoi utilizzare i filtri di replica anche per specificare i database e le tabelle che vengono replicati con un'istanza database MySQL primaria configurata come replica in una topologia di replica in ingresso. Per ulteriori informazioni su questa configurazione, consulta [Configurazione della replica della posizione del file di log binario con un'istanza di origine esterna.](MySQL.Procedural.Importing.External.Repl.md). **Topics** + [ ## Impostazione dei parametri di filtro della replica RDS for MySQL ](#USER_MySQL.Replication.ReadReplicas.ReplicationFilters.Configuring) + [ ## Limitazioni di filtro delle repliche per RDS per MySQL ](#USER_MySQL.Replication.ReadReplicas.ReplicationFilters.Limitations) + [ ## Esempi di filtri di replica per RDS per MySQL ](#USER_MySQL.Replication.ReadReplicas.ReplicationFilters.Examples) + [ ## Visualizzazione dei filtri di replica per una replica di lettura ](#USER_MySQL.Replication.ReadReplicas.ReplicationFilters.Viewing) ## Impostazione dei parametri di filtro della replica RDS for MySQL Per configurare i filtri di replica, impostare i seguenti parametri di filtro replica sulla replica di lettura: + `replicate-do-db` – Replicare le modifiche ai database specificati. Quando si imposta questo parametro per una replica di lettura, vengono replicati solo i database specificati nel parametro. + `replicate-ignore-db` – Non replicare le modifiche ai database specificati. Quando il parametro `replicate-do-db` è impostato per una replica di lettura, questo parametro non viene valutato. + `replicate-do-table` – Replicare le modifiche alle tabelle specificate. Quando si imposta questo parametro per una replica di lettura, vengono replicate solo le tabelle specificate nel parametro. Inoltre, quando viene impostato il parametro `replicate-do-db` o `replicate-ignore-db`, assicurarsi di includere il database che include le tabelle specificate nella replica con la replica di lettura. + `replicate-ignore-table` – Non replicare le modifiche alle tabelle specificate. Quando il parametro `replicate-do-table` è impostato per una replica di lettura, questo parametro non viene valutato. + `replicate-wild-do-table` – Replicare le tabelle in base ai modelli di nome del database e della tabella specificati. I caratteri jolly `%` e `_` sono supportati. Quando è impostato il parametro `replicate-do-db` o `replicate-ignore-db`, assicurarsi di includere il database che include le tabelle specificate nella replica con la replica di lettura. + `replicate-wild-ignore-table` – Non replicare le tabelle in base ai modelli di nomi di database e tabella specificati. I caratteri jolly `%` e `_` sono supportati. Quando è impostato il parametro `replicate-do-table` o `replicate-wild-do-table` per una replica di lettura, questo parametro non viene valutato. I parametri vengono valutati nell'ordine in cui sono elencati. Per ulteriori informazioni sul funzionamento di questi parametri, consulta la documentazione di MySQL: + Per informazioni generali, consulta [Opzioni e variabili del server di replica](https://dev.mysql.com/doc/refman/8.0/en/replication-options-replica.html). + Per informazioni sulla modalità di valutazione dei parametri di filtro della replica del database, consulta [Valutazione delle opzioni di replica a livello di database e registrazione binaria](https://dev.mysql.com/doc/refman/8.0/en/replication-rules-db-options.html). + Per informazioni sulla modalità di valutazione dei parametri di filtro replica delle tabelle, consulta [Valutazione delle opzioni di replica a livello di tabella](https://dev.mysql.com/doc/refman/8.0/en/replication-rules-table-options.html). Per impostazione predefinita, ognuno di questi parametri ha un valore vuoto. In ogni replica di lettura, è possibile utilizzare questi parametri per impostare, modificare ed eliminare i filtri di replica. Quando viene impostato uno di questi parametri, è necessario separare ogni filtro dagli altri con una virgola. È possibile utilizzare i caratteri jolly `%` e `_` nei parametri `replicate-wild-do-table` e `replicate-wild-ignore-table`. Il carattere jolly `%` corrisponde a un numero qualsiasi di caratteri e il carattere jolly `_` corrisponde a un solo carattere. Il formato di registrazione binaria dell'istanza database di origine è importante per la replica perché determina il record delle modifiche ai dati. L'impostazione del parametro `binlog_format` determina se la replica è basata su righe o basata su dichiarazione. Per ulteriori informazioni, consulta [Configurazione di MySQL RDS per la registrazione binaria MySQL per database Single-AZ](USER_LogAccess.MySQL.BinaryFormat.md). **Nota** Tutte le istruzioni DDL (Data Definition Language) vengono replicate come istruzioni, indipendentemente dall'impostazione `binlog_format` dell'istanza database di origine. ## Limitazioni di filtro delle repliche per RDS per MySQL Le seguenti limitazioni si applicano al filtro di replica per RDS per MySQL: + Ogni parametro di filtro della replica ha un limite di 2.000 caratteri. + Le virgole non sono supportate nei filtri di replica per i valori dei parametri. In un elenco di parametri, le virgole possono essere utilizzate solo come separatori di valori. Ad esempio, `ParameterValue='`a,b`'` non è supportato, ma `ParameterValue='a,b'` è supportato. + Le opzioni MySQL `--binlog-do-db` e `--binlog-ignore-db` per il filtro dei log binari non sono supportate. + Il filtro delle repliche non supporta le transazioni XA. Per ulteriori informazioni, consulta [Restrizioni sulle transazioni XA](https://dev.mysql.com/doc/refman/8.0/en/xa-restrictions.html) nella documentazione di MySQL. ## Esempi di filtri di replica per RDS per MySQL Per configurare il filtro di replica per una replica di lettura, modificare i parametri di filtro replica nel gruppo di parametri associato alla replica di lettura. **Nota** Non è consentito modificare un gruppo di parametri predefinito. Se la replica di lettura usa un gruppo di parametri predefinito, creare un nuovo gruppo di parametri e associarlo alla replica di lettura. Per ulteriori informazioni sui gruppi di parametri database, consulta [Gruppi di parametri per Amazon RDS](USER_WorkingWithParamGroups.md). È possibile impostare i parametri in un gruppo di parametri utilizzando Console di gestione AWS AWS CLI, o l'API RDS. Per informazioni sull'estensione dei parametri consulta [Modifica dei parametri in un gruppo di parametri database in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). Quando si impostano parametri in un gruppo di parametri, tutte le istanze DB associate al gruppo di parametri utilizzano le impostazioni dei parametri. Se si impostano i parametri di filtro della replica in un gruppo di parametri, assicurarsi che il gruppo di parametri sia associato solo alle repliche di lettura. Lasciare vuoti i parametri di filtro di replica per le istanze database di origine. Negli esempi seguenti vengono impostati i parametri utilizzando AWS CLI. In questi esempi si imposta `ApplyMethod` su `immediate` in modo che le modifiche ai parametri avvengano immediatamente dopo il completamento del comando della CLI. Se si desidera applicare una modifica in sospeso dopo il riavvio della replica di lettura, impostare `ApplyMethod` su `pending-reboot`. Gli esempi seguenti impostano i filtri di replica: + [Including databases in replication](#rep-filter-in-dbs-mysql) + [Including tables in replication](#rep-filter-in-tables-mysql) + [Including tables in replication with wildcard characters](#rep-filter-in-tables-wildcards-mysql) + [Excluding databases from replication](#rep-filter-ex-dbs-mysql) + [Excluding tables from replication](#rep-filter-ex-tables-mysql) + [Excluding tables from replication using wildcard characters](#rep-filter-ex-tables-wildcards-mysql) **Example Inclusione dei database nella replica** Nell'esempio seguente sono inclusi i database `mydb1` e `mydb2` nella replica. Per Linux, macOS o Unix: ``` aws rds modify-db-parameter-group \ --db-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-do-db,ParameterValue='mydb1,mydb2',ApplyMethod=immediate" ``` Per Windows: ``` aws rds modify-db-parameter-group ^ --db-parameter-group-name myparametergroup ^ --parameters "ParameterName=replicate-do-db,ParameterValue='mydb1,mydb2',ApplyMethod=immediate" ``` **Example Inclusione delle tabelle nella replica** Nell'esempio seguente sono incluse le tabelle `table1` e `table2` nel database `mydb1` nella replica. Per Linux, macOS o Unix: ``` aws rds modify-db-parameter-group \ --db-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-do-table,ParameterValue='mydb1.table1,mydb1.table2',ApplyMethod=immediate" ``` Per Windows: ``` aws rds modify-db-parameter-group ^ --db-parameter-group-name myparametergroup ^ --parameters "ParameterName=replicate-do-table,ParameterValue='mydb1.table1,mydb1.table2',ApplyMethod=immediate" ``` **Example Inclusione di tabelle nella replica utilizzando caratteri jolly** Nell'esempio seguente sono incluse tabelle con nomi che iniziano con `order` e `return` nel database `mydb` nella replica. Per Linux, macOS o Unix: ``` aws rds modify-db-parameter-group \ --db-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-wild-do-table,ParameterValue='mydb.order%,mydb.return%',ApplyMethod=immediate" ``` Per Windows: ``` aws rds modify-db-parameter-group ^ --db-parameter-group-name myparametergroup ^ --parameters "ParameterName=replicate-wild-do-table,ParameterValue='mydb.order%,mydb.return%',ApplyMethod=immediate" ``` **Example Esclusione di database dalla replica** Nell'esempio seguente vengono esclusi i database `mydb5` e `mydb6` dalla replica. Per Linux, macOS o Unix: ``` aws rds modify-db-parameter-group \ --db-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-ignore-db,ParameterValue='mydb5,mydb6',ApplyMethod=immediate" ``` Per Windows: ``` aws rds modify-db-parameter-group ^ --db-parameter-group-name myparametergroup ^ --parameters "ParameterName=replicate-ignore-db,ParameterValue='mydb5,mydb6',ApplyMethod=immediate" ``` **Example Esclusione di tabelle dalla replica** Nell'esempio seguente vengono escluse dalla replica le tabelle `table1` nel database `mydb5` e `table2` nel database `mydb6`. Per Linux, macOS o Unix: ``` aws rds modify-db-parameter-group \ --db-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-ignore-table,ParameterValue='mydb5.table1,mydb6.table2',ApplyMethod=immediate" ``` Per Windows: ``` aws rds modify-db-parameter-group ^ --db-parameter-group-name myparametergroup ^ --parameters "ParameterName=replicate-ignore-table,ParameterValue='mydb5.table1,mydb6.table2',ApplyMethod=immediate" ``` **Example Esclusione di tabelle dalla replica utilizzando caratteri jolly** Nell'esempio seguente vengono escluse le tabelle con nomi che iniziano con `order` e `return` nel database `mydb7` dalla replica. Per Linux, macOS o Unix: ``` aws rds modify-db-parameter-group \ --db-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-wild-ignore-table,ParameterValue='mydb7.order%,mydb7.return%',ApplyMethod=immediate" ``` Per Windows: ``` aws rds modify-db-parameter-group ^ --db-parameter-group-name myparametergroup ^ --parameters "ParameterName=replicate-wild-ignore-table,ParameterValue='mydb7.order%,mydb7.return%',ApplyMethod=immediate" ``` ## Visualizzazione dei filtri di replica per una replica di lettura È possibile visualizzare i filtri di replica per una replica di lettura nei seguenti modi: + Controllare le impostazioni dei parametri di filtro replica nel gruppo di parametri associato alla replica di lettura. Per istruzioni, consulta [Visualizzazione dei valori dei parametri per un gruppo di parametri del database in Amazon RDS](USER_WorkingWithParamGroups.Viewing.md). + In un client MySQL, connettersi alla replica di lettura ed eseguire l'istruzione `SHOW REPLICA STATUS`. Nell'output, i campi seguenti mostrano i filtri di replica per la replica di lettura: + `Replicate_Do_DB` + `Replicate_Ignore_DB` + `Replicate_Do_Table` + `Replicate_Ignore_Table` + `Replicate_Wild_Do_Table` + `Replicate_Wild_Ignore_Table` Per ulteriori informazioni su questi campi, consulta [Verifica dello stato della replica](https://dev.mysql.com/doc/refman/8.0/en/replication-administration-status.html) nella documentazione di MariaDB. # Configurazione della replica ritardata con MySQL Puoi usare la replica ritardata come strategia per il disaster recovery. Con la replica ritardata puoi specificare il tempo minimo, in secondi, di ritardo della replica rispetto all'origine nella replica di lettura. In caso di emergenza, come ad esempio l'eliminazione accidentale di una tabella, completa la seguente procedura per risolvere velocemente il problema: + Arresta la replica sulla replica di lettura prima che la modifica che ha provocato il problema venga inviata. Usa la procedura archiviata [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) per arrestare la replica. + Avvia la replica e specifica che la replica si arresta automaticamente in corrispondenza di una posizione del file di log. Puoi specificare una posizione prima dell'emergenza utilizzando la procedura archiviata [](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until). + Utilizza le istruzioni contenute in [Promozione di una replica di lettura a istanza database standalone](USER_ReadRepl.Promote.md) per promuovere la replica di lettura a nuova istanza database di origine. **Nota** Su RDS for MySQL 8.4, la replica ritardata è supportata per MySQL 8.4.3 e versioni successive. Su RDS per MySQL 8,0, la replica ritardata è supportata per MySQL 8.0.28 e versioni successive. In RDS for MySQL 5.7, la replica ritardata è supportata per MySQL 5.7.44 e versioni successive. Utilizza le procedure archiviate per configurare la replica ritardata. Non puoi configurare la replica ritardata con Console di gestione AWS, the o l' AWS CLI API Amazon RDS. Puoi utilizzare la replica basata sugli identificatori di transazione globali (GTIDs) in una configurazione di replica ritardata per le seguenti versioni: RDS per MySQL versione 5.7.44 e versioni successive alla 5.7 RDS per MySQL versione 8.0.28 e versioni successive alla 8.0 RDS per MySQL versione 8.4.3 e versioni successive alla 8.4 Se si utilizza la replica basata su GTID, scegliere la stored procedure [](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid) invece della [](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until). Per ulteriori informazioni sulla replica basata su GTID, consultare [Utilizzo della replica basata su GTID](mysql-replication-gtid.md). **Topics** + [ ## Configurazione della replica ritardata durante la creazione della replica di lettura ](#USER_MySQL.Replication.ReadReplicas.DelayReplication.ReplicaCreation) + [ ## Modifica della replica ritardata per una replica di lettura esistente ](#USER_MySQL.Replication.ReadReplicas.DelayReplication.ExistingReplica) + [ ## Definire una posizione per arrestare la replica su una replica di lettura ](#USER_MySQL.Replication.ReadReplicas.DelayReplication.StartUntil) + [ ## Promozione di una replica di lettura ](#USER_MySQL.Replication.ReadReplicas.DelayReplication.Promote) ## Configurazione della replica ritardata durante la creazione della replica di lettura Per configurare la replica ritardata per eventuali repliche di lettura future create da un'istanza database, esegui la stored procedure [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) con il parametro `target delay`. **Per configurare le replica ritardata durante la creazione della replica di lettura** 1. Utilizzando un client MySQL, connettersi all'istanza database MySQL che sarà l'origine delle repliche di lettura come l'utente master. 1. Eseguire la procedura archiviata [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) con il parametro `target delay`. Ad esempio, eseguire la seguente procedura archiviata per specificare che la replica è ritardata per almeno un'ora (3.600 secondi) per le repliche di lettura create dall'istanza database corrente. ``` call mysql.rds_set_configuration('target delay', 3600); ``` **Nota** Dopo aver eseguito questa procedura memorizzata, qualsiasi replica di lettura creata utilizzando l'API AWS CLI o Amazon RDS viene configurata con una replica ritardata del numero di secondi specificato. ## Modifica della replica ritardata per una replica di lettura esistente Per modificare la replica ritardata per una replica di lettura esistente, esegui la stored procedure [mysql.rds\$1set\$1source\$1delay](mysql-stored-proc-replicating.md#mysql_rds_set_source_delay). **Per modificare la replica ritardata per una replica di lettura esistente** 1. Utilizzando un client MySQL, connettersi alla replica di lettura come utente master. 1. Usa la procedura archiviata [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) per arrestare la replica. 1. Eseguire la procedura archiviata [mysql.rds\$1set\$1source\$1delay](mysql-stored-proc-replicating.md#mysql_rds_set_source_delay). Ad esempio, eseguire la seguente stored procedure per specificare che la replica sulla replica di lettura è ritardata per almeno un'ora (3600 secondi). ``` call mysql.rds_set_source_delay(3600); ``` 1. Usare la procedura archiviata [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) per avviare la replica. ## Definire una posizione per arrestare la replica su una replica di lettura Dopo aver arrestato la replica sulla replica di lettura, puoi avviare la replica e poi arrestarla in corrispondenza della posizione del file di log binario specificato utilizzando la procedura archiviata [](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until). **Per avviare la replica su una replica di lettura e arrestare la replica in corrispondenza di una posizione specifica** 1. Utilizzando un client MySQL, connettersi all'istanza database MySQL di origine come utente master. 1. Eseguire la procedura archiviata [](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until). L'esempio seguente avvia la replica e replica le modifiche fino a raggiungere la posizione `120` nel file di log binario `mysql-bin-changelog.000777`. In caso di disaster recovery, presumere che la posizione `120` si riferisca al momento immediatamente precedente l'errore. ``` call mysql.rds_start_replication_until( 'mysql-bin-changelog.000777', 120); ``` La replica si arresta automaticamente quando viene raggiunto il punto di arresto. Viene generato il seguente evento RDS: `Replication has been stopped since the replica reached the stop point specified by the rds_start_replication_until stored procedure`. ## Promozione di una replica di lettura Dopo l'arresto della replica, in uno scenario di disaster recovery, puoi promuovere la replica di lettura come nuova istanza database di origine. Per informazioni sulla promozione di una replica di lettura, consulta [Promozione di una replica di lettura a istanza database standalone](USER_ReadRepl.Promote.md). # Aggiornamento di repliche di lettura con MySQL Le repliche di lettura sono progettate per supportare query di lettura, ma occasionalmente potrebbe essere necessario eseguire aggiornamenti. Ad esempio, potresti dover aggiungere un indice per ottimizzare i tipi specifici di query che accedono alla replica. Sebbene sia possibile abilitare gli aggiornamenti impostando il parametro `read_only` su `0` nel gruppo di parametri database per la replica di lettura, si consiglia di non farlo perché questa operazione può causare problemi se la replica di lettura diventa non compatibile con l'istanza database di origine. Per le operazioni di manutenzione, si consiglia di utilizzare le blue/green distribuzioni. Per ulteriori informazioni, consulta [Utilizzo di Deployments Blue/Green per gli aggiornamenti del database](blue-green-deployments.md). Se disabiliti la modalità di sola lettura su una replica di lettura, modifica il valore del parametro `read_only` impostandolo su `1` il prima possibile. # Utilizzo di implementazioni Multi-AZ di repliche di lettura con MySQL Puoi creare una replica di lettura da implementazioni Single-AZ o Multi-AZ di istanze database. Puoi usare implementazioni Multi-AZ per migliorare la durabilità e la disponibilità di dati critici, ma non puoi usare l'istanza secondaria Multi-AZ per inviare query di sola lettura. Puoi invece creare repliche di lettura da istanze database Multi-AZ con traffico elevato per l'offload di query di sola lettura. Se viene eseguito il failover dell'istanza di origine di un'implementazione Multi-AZ all'istanza secondaria, tutte le repliche di lettura passeranno automaticamente a usare l'istanza secondaria (ora primaria) come origine della replica. Per ulteriori informazioni, consulta [Configurazione e gestione di un’implementazione Multi-AZ per Amazon RDS](Concepts.MultiAZ.md). È possibile creare una replica di lettura come istanza database Multi-AZ. Amazon RDS crea una replica di standby in un'altra zona di disponibilità per il supporto del failover per la replica. La creazione della replica di lettura come un'istanza database Multi-AZ non dipende dal fatto che il database di origine sia un'istanza database Multi-AZ. # Utilizzo di repliche di lettura a cascata con RDS per MySQL RDS per MySQL supporta le repliche di lettura a cascata. Con le *repliche di lettura a cascata*, puoi dimensionare le letture senza aggiungere sovraccarico all'istanza database RDS per MySQL di origine. Con le repliche di lettura a cascata, l'istanza database RDS per MySQL invia i dati alla prima replica di lettura della catena. La replica di lettura invia quindi i dati alla seconda replica della catena e così via. Il risultato finale è che tutte le repliche di lettura nella catena includono le modifiche dall'istanza database RDS per MySQL, ma senza sovraccaricare esclusivamente l'istanza database di origine. È possibile creare una serie di fino a tre repliche di lettura in una catena da un'istanza database RDS per MySQL di origine. Ad esempio, supponi di avere l'istanza database RDS per MySQL `mysql-main`. Puoi eseguire le operazioni indicate di seguito: + A partire da `mysql-main`, crea la prima replica di lettura nella catena, `read-replica-1`. + Da `read-replica-1`, crea quindi la successiva replica di lettura nella catena, `read-replica-2`. + Da `read-replica-2`, crea infine la terza replica di lettura nella catena, `read-replica-3`. Non è possibile creare un'altra replica di lettura oltre la terza replica di lettura a cascata nella serie per `mysql-main`. Una serie completa di istanze da un'istanza database RDS per MySQL di origine fino alla fine di una serie di repliche di lettura a cascata può essere composta al massimo da quattro istanze database. Affinché le repliche di lettura a cascata funzionino, ogni istanza database RDS per MySQL di origine deve avere i backup automatici attivati. Per abilitare i backup automatici in una replica di lettura, crea prima di tutto la replica di lettura, quindi modificala in modo da abilitare i backup automatici. Per ulteriori informazioni, consulta [Creazione di una replica di lettura](USER_ReadRepl.Create.md). Come per qualsiasi replica di lettura, puoi promuovere una replica di lettura appartenente a una cascata. La promozione di una replica di lettura all'interno di una catena di repliche di lettura rimuove la replica dalla catena. Ad esempio, supponi di voler spostare parte del carico di lavoro fuori dall'istanza database `mysql-main` in una nuova istanza usata solo dal reparto contabile. Facendo riferimento alla catena di tre repliche di lettura dell'esempio, decidi di promuovere `read-replica-2`. La catena verrà modificata come segue: + La promozione `read-replica-2` rimuove l'istanza dalla catena di replica. + Ora è un'istanza database completa di lettura/scrittura. + Continua a replicare su `read-replica-3`, proprio come prima della promozione. + L'istanza `mysql-main` continua a venire replicata su `read-replica-1`. Per ulteriori informazioni sulla promozione delle repliche di lettura, consulta [Promozione di una replica di lettura a istanza database standalone](USER_ReadRepl.Promote.md). # Monitoraggio del ritardo di replica per le repliche di lettura MySQL Per le repliche di lettura MySQL, puoi monitorare il ritardo di replica in Amazon CloudWatch visualizzando il parametro Amazon RDS `ReplicaLag`. Il parametro `ReplicaLag` segnala il valore del campo `Seconds_Behind_Master` del comando `SHOW REPLICA STATUS`. Le cause comuni del ritardo di replica per MySQL sono le seguenti: + Interruzione della connessione di rete. + Scrittura su tabelle con indici diversi su una replica di lettura. Se il parametro `read_only` è impostato su `0` sulla replica di lettura, la replica può interrompersi se la replica di lettura diventa incompatibile con l'istanza database di origine. Dopo aver eseguito operazioni di manutenzione sulla replica di lettura, consigliamo di ripristinare il parametro `read_only` a `1`. + Uso di un motore di storage non transazionale come MyISAM. La replica è supportata solo per il motore di storage InnoDB su MySQL. Quando il parametro `ReplicaLag` è 0, la replica ha raggiunto l'istanza del database di origine. Se il parametro `ReplicaLag` restituisce -1, la replica non è attualmente attiva. `ReplicaLag` = -1 equivale a `Seconds_Behind_Master` = `NULL`. # Avvio e arresto della replica con repliche di lettura MySQL Puoi arrestare e riavviare il processo di replica in un'istanza database Amazon RDS chiamando le stored procedure di sistema [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) e [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication). Puoi procedere in questo modo quando esegui la replica tra due istanze Amazon RDS per operazioni a esecuzione prolungata, come la creazione di indici di grandi dimensioni. Devi arrestare e avviare la replica anche durante l'importazione o l'esportazione di database. Per ulteriori informazioni, consultare [Importazione dei dati in un database Amazon RDS per MySQL con tempo di inattività ridotto](mysql-importing-data-reduced-downtime.md) e [Esportazione di dati da un'istanza database MySQL tramite la replica](MySQL.Procedural.Exporting.NonRDSRepl.md). Se la replica viene arrestata per più di 30 giorni consecutivi, manualmente o a causa di un errore di replica, Amazon RDS termina la replica tra l'istanza database di origine e tutte le repliche di lettura. Questo avviene per evitare requisiti di storage maggiori sull'istanza database di origine e tempi di failover prolungati. L'istanza database della replica di lettura continua a essere disponibile. Tuttavia, la replica non può essere ripresa, perché i log binari richiesti dalla replica di lettura vengono eliminati dall'istanza database di origine una volta terminata la replica. Puoi creare una nuova replica di lettura per l'istanza database di origine per ristabilire la replica. # Risoluzione dei problemi relativi a una replica di lettura MySQL Per le istanze database MySQL, in alcuni casi le repliche di lettura presentano errori o incoerenze (o entrambi) dei dati tra la replica di lettura e la sua istanza database di origine. Questo problema si verifica quando alcuni eventi log binario (binlog) o log redo InnoDB non vengono scaricati durante un errore della replica di lettura o dell'istanza database di origine. In questi casi, elimina e ricrea manualmente le repliche di lettura. Puoi ridurre le possibilità che si verifichi una situazione di questo tipo impostando i seguenti valori dei parametri: `sync_binlog=1` e `innodb_flush_log_at_trx_commit=1`. Tali impostazioni potrebbero ridurre le prestazioni, per cui ti consigliamo di testare il loro impatto prima di implementare le modifiche nell'ambiente di produzione. **avvertimento** Nel gruppo di parametri associato all'istanza database di origine, consigliamo di mantenere i valori di questi parametri: `sync_binlog=1` e `innodb_flush_log_at_trx_commit=1`. Questi parametri sono dinamici. Se non vuoi utilizzare queste impostazioni, ti consigliamo di impostare temporaneamente tali valori prima di eseguire qualsiasi operazione sull'istanza database di origine che potrebbe causarne il riavvio. Queste operazioni includono, a titolo esemplificativo ma non esaustivo, il riavvio, il riavvio con failover, l'aggiornamento della versione del database e la modifica della classe di istanza database o della relativa archiviazione. Lo stesso suggerimento si applica alla creazione di nuove repliche di lettura per l'istanza database di origine. Il mancato rispetto di questa guida aumenta il rischio che le repliche di lettura presentino errori o incoerenze dei dati (o entrambe) tra la replica di lettura e la sua istanza database di origine. Le tecnologie di replica per MySQL sono asincrone. Per questo motivo, devi occasionalmente aspettarti incrementi del parametro `BinLogDiskUsage` per l'istanza database di origine e del parametro `ReplicaLag` per la replica di lettura. Ad esempio, può verificarsi un elevato volume di scrittura in parallelo nell'istanza database di origine. Al contrario, le operazioni di scrittura nella replica di lettura vengono serializzate usando un singolo thread di I/O, causando un ritardo tra l'istanza di origine e la replica di lettura. Per ulteriori informazioni sulle repliche di sola lettura, consulta le [informazioni dettagliate sull'implementazione di repliche](https://dev.mysql.com/doc/refman/8.0/en/replication-implementation-details.html) nella documentazione di MySQL. Puoi ridurre il ritardo tra gli aggiornamenti di un'istanza database di origine e i successivi aggiornamenti della replica di lettura in diversi modi, ad esempio: + Dimensionando una replica di lettura in modo che dimensioni di storage e classe dell'istanza database siano equivalenti all'istanza database di origine. + Assicurandoti che le impostazioni dei parametri nei gruppi di parametri database usati dall'istanza database di origine e dalla replica di lettura siano compatibili. Per ulteriori informazioni e un esempio, consulta la discussione sul parametro `max_allowed_packet` più avanti in questa sezione. Amazon RDS monitora lo stato delle repliche di lettura e aggiorna il campo `Replication State` dell'istanza della replica di lettura con il valore `Error` se la replica viene arrestata per qualsiasi motivo. Un possibile esempio è quando query DML in esecuzione nella replica di lettura sono in conflitto con gli aggiornamenti eseguiti nell'istanza database di origine. Puoi esaminare i dettagli dell'errore associato generato dal motore MySQL visualizzando il campo `Replication Error`. Vengono generati anche eventi che indicano lo stato della replica di lettura, inclusi [RDS-EVENT-0045](USER_Events.Messages.md#RDS-EVENT-0045), [RDS-EVENT-0046](USER_Events.Messages.md#RDS-EVENT-0046) e [RDS-EVENT-0047](USER_Events.Messages.md#RDS-EVENT-0047). Per ulteriori informazioni sugli eventi e sulla sottoscrizione a essi, consulta [Utilizzo della notifica degli eventi di Amazon RDS](USER_Events.md). Se viene restituito un messaggio di errore MySQL, verifica il numero di errore nella [documentazione dei messaggi di errore MySQL](https://dev.mysql.com/doc/mysql-errors/8.0/en/server-error-reference.html). Un problema comune che può provocare errori di replica si verifica quando il valore del parametro `max_allowed_packet` per una replica di lettura è minore del parametro `max_allowed_packet` per l'istanza database di origine. Il parametro `max_allowed_packet` è un parametro personalizzato che puoi impostare in un gruppo di parametri database. Utilizza `max_allowed_packet` per specificare la dimensione massima del codice DML che può essere eseguito nel database. In alcuni casi, il valore `max_allowed_packet` nel gruppo dei parametri database associato alla replica di lettura è minore del valore `max_allowed_packet` nel gruppo dei parametri database associato all'istanza database di origine. In questi casi, il processo di replica può generare l'errore `Packet bigger than 'max_allowed_packet' bytes` e interrompere la replica. Per correggere l'errore, impostare l'istanza database di origine e la replica di lettura in modo che utilizzino i gruppi di parametri database con gli stessi valori del parametro `max_allowed_packet`. Altre situazioni comuni che possono causare errori di replica includono le seguenti: + Scrittura in tabelle su una replica di lettura. In alcuni casi, potrebbe essere necessario creare indici su una replica di lettura che sono diversi dagli indici nell'istanza database di origine. In tal caso, imposta il parametro `read_only` su `0` per creare gli indici. Se scrivi in tabelle sulla replica di lettura, questa operazione potrebbe comportare l'interruzione della replica se la replica di lettura diventa incompatibile con l'istanza database di origine. Dopo aver eseguito attività di manutenzione sulla replica di lettura, ti consigliamo di ripristinare il parametro `read_only` su `1`. + Utilizzo di un motore di storage non transazionale come MyISAM. Le repliche di lettura richiedono un motore di storage transazionale. La replica è supportata solo per il motore di storage InnoDB su MySQL. + Utilizzo di query non deterministiche non sicure come `SYSDATE()`. Per ulteriori informazioni, consulta la pagina relativa alla [determinazione delle istruzioni sicure e non sicure nel log binario](https://dev.mysql.com/doc/refman/8.0/en/replication-rbr-safe-unsafe.html). Se decidi di poter ignorare un errore con certezza, puoi completare la procedura descritta nella sezione [Ignorare l’errore di replica corrente per RDS per MySQL](Appendix.MySQL.CommonDBATasks.SkipError.md). In caso contrario, puoi prima eliminare la replica di lettura. Quindi crea un'istanza utilizzando lo stesso identificatore istanze DB in modo che l'endpoint resti lo stesso di quello della replica di lettura precedente. Quando un problema relativo alla replica viene risolto, il campo `Replication State` (Stato di replica) cambia in *replicating (replica in corso)*. # Utilizzo della replica basata su GTID Di seguito sono riportate le indicazioni per utilizzare gli identificatori di transazione globali (GTID) con la replica basata sui log binari (binlog) tra istanze database Amazon RDS per MySQL. Se si utilizza la replica basata su binlog e non si ha familiarità con la replica basata su GTID con MySQL, consulta [Replication with global transaction identifiers](https://dev.mysql.com/doc/refman/5.7/en/replication-gtids.html) nella documentazione MySQL. La replica basata su GTID è supportata per le seguenti versioni: + Tutte le versioni di RDS per MySQL 8.4 + Tutte le versioni di RDS per MySQL 8.0 + Tutte le versioni di RDS per MySQL 5.7 Tutte le istanze database MySQL in una configurazione di replica devono rispettare questo requisito relativo alla versione. **Topics** + [ ## Identificatori globali di transazione (GTID) ](#mysql-replication-gtid.overview) + [ ## Parametri per la replica basata su GTID ](#mysql-replication-gtid.parameters) + [ # Abilitazione della replica basata su GTID per nuove repliche di lettura per RDS per MySQL ](mysql-replication-gtid.configuring-new-read-replicas.md) + [ # Abilitazione della replica basata su GTID per le repliche di lettura esistenti per RDS per MySQL ](mysql-replication-gtid.configuring-existing-read-replicas.md) + [ # Disabilitazione della replica basata su GTID per un'istanza database MySQL con repliche di lettura ](mysql-replication-gtid.disabling.md) ## Identificatori globali di transazione (GTID) *Gli identificatori globali di transazione (GTID)* sono identificatori univoci generati per le transazioni MySQL sottoposte a commit. Puoi utilizzare i GTID per semplificare la replica basata sui log binari e facilitare la risoluzione dei problemi. MySQL utilizza due diversi tipi di transazioni per la replica basata sui log binari: + *Transazioni GTID* – Transazioni identificate da un GTID. + *Transazioni anonime* – Transazioni a cui non è assegnato un GTID. In una configurazione di replica, i GTID sono univoci in tutte le istanze database. I GTID semplificano la configurazione della replica perché, quando vengono utilizzati, non è necessario fare riferimento alle posizioni nel file di log. I GTID semplificano anche la registrazione delle transazioni replicate e verificano che l’istanza di origine e le repliche siano coerenti. Puoi utilizzare la replica basata su GTID per replicare i dati con le repliche di lettura di RDS for MySQL. Puoi configurare la replica basata su GTID quando crei le nuove repliche di lettura oppure puoi convertire le repliche di lettura esistenti in modo che usino la replica basata su GTID. Puoi utilizzare la replica basata su GTID anche in una configurazione di replica ritardata con RDS for MySQL. Per ulteriori informazioni, consulta [Configurazione della replica ritardata con MySQL](USER_MySQL.Replication.ReadReplicas.DelayReplication.md). ## Parametri per la replica basata su GTID Utilizzare i parametri seguenti per configurare la replica basata su GTID. | Parametro | Valori validi | Descrizione | | --- | --- | --- | | `gtid_mode` | `OFF`, `OFF_PERMISSIVE`, `ON_PERMISSIVE`, `ON` | `OFF` indica che le nuove transazioni sono anonime, ovvero non hanno GTID, e che una transazione deve essere anonima per poter essere replicata. `OFF_PERMISSIVE` indica che le nuove transazioni sono anonime, ma tutte le transazioni possono essere replicate. `ON_PERMISSIVE` indica che le nuove transazioni hanno GTID assegnati, ma tutte le transazioni possono essere replicate. `ON` indica che le nuove transazioni hanno GTID assegnati e che una transazione deve avere un GTID per poter essere replicata. | | `enforce_gtid_consistency` | `OFF`, `ON`, `WARN` | `OFF` consente alle transazioni di violare la coerenza GTID. `ON` impedisce alle transazioni di violare la coerenza GTID. `WARN` consente alle transazioni di violare la consistenza GTID, ma genera un avviso quando si verifica una violazione. | **Nota** Nella Console di gestione AWS, il parametro `gtid_mode` viene visualizzato come `gtid-mode`. Per la replica basata su GTID, utilizza queste impostazioni per il gruppo di parametri dell'istanza database o per la replica di lettura: + `ON` e `ON_PERMISSIVE` si applicano solo alla replica in uscita da un'istanza database RDS. Entrambi questi valori fanno sì che l'istanza database RDS utilizzi i GTID per le transazioni replicate. `ON` richiede che anche il database di destinazione utilizzi la replica basata su GTID. Per `ON_PERMISSIVE` la replica basata su GTID è opzionale sul database di destinazione. + `OFF_PERMISSIVE`, se impostato, significa che le istanze database RDS possono accettare la replica in ingresso da un database di origine. Possono farlo indipendentemente dal fatto che il database di origine utilizzi la replica basata su GTID. + `OFF`, se impostato, significa che le istanze database RDS accettano solo la replica in ingresso da database di origine che non utilizzano la replica basata su GTID. Per ulteriori informazioni sui gruppi di parametri, consultare [Gruppi di parametri per Amazon RDS](USER_WorkingWithParamGroups.md). # Abilitazione della replica basata su GTID per nuove repliche di lettura per RDS per MySQL Quando la replica basata su GTID è abilitata per un'istanza database di RDS for MySQL, la replica basata su GTID viene configurata automaticamente per le repliche di lettura di un'istanza database. **Per abilitare la replica basata su GTID per le nuove repliche di lettura** 1. Verificare che il gruppo di parametri associato all'istanza database abbia le impostazioni dei parametri seguenti: + `gtid_mode` – `ON` o `ON_PERMISSIVE` + `enforce_gtid_consistency` – `ON` Per ulteriori informazioni sull'impostazione dei parametri di configurazione mediante i gruppi di parametri, consultare [Gruppi di parametri per Amazon RDS](USER_WorkingWithParamGroups.md). 1. Se è stato modificato un gruppo di parametri dell'istanza database, riavviare l'istanza. Per ulteriori informazioni su come effettuare questa operazione, consultare [Riavvio di un'istanza DB DB](USER_RebootInstance.md). 1. Creare una o più repliche di lettura dell'istanza database. Per ulteriori informazioni su come effettuare questa operazione, consultare [Creazione di una replica di lettura](USER_ReadRepl.Create.md). Amazon RDS prova a stabilire una replica basata su GTID tra l'istanza database di MySQL e le repliche di lettura utilizzando `MASTER_AUTO_POSITION`. Se il tentativo non riesce, Amazon RDS utilizza le posizioni del file di log per la replica con le repliche di lettura. Per ulteriori informazioni su `MASTER_AUTO_POSITION`, consultare l'argomento relativo al [ posizionamento automatico dei GTID](https://dev.mysql.com/doc/refman/5.7/en/replication-gtids-auto-positioning.html) nella documentazione di MySQL. # Abilitazione della replica basata su GTID per le repliche di lettura esistenti per RDS per MySQL Per un'istanza database di RDS for MySQL esistente con repliche di lettura che non utilizzano la replica basata su GTID, è possibile configurare la replica basata su GTID tra l'istanza database e le repliche di lettura. **Per abilitare la replica basata su GTID per le repliche di lettura esistenti** 1. Se l'istanza database o qualsiasi replica di lettura sta utilizzando RDS versione 8.0 for MySQL versione 8.0.26 o precedente, aggiornare l'istanza database o la replica di lettura a MySQL 8.0.26 o versione successiva alla 8.0. Tutte le versioni di RDS per MySQL 8.4 e le versioni 5.7 supportano la replica basata su GTID. Per ulteriori informazioni, consulta [Aggiornamenti del motore di database RDS per MySQL](USER_UpgradeDBInstance.MySQL.md). 1. (Facoltativo) Reimpostare i parametri GTID e verificare il comportamento dell'istanza database e delle repliche di lettura: 1. Verificare che il gruppo di parametri associato all'istanza database e ogni replica di lettura abbiano il parametro `enforce_gtid_consistency` impostato su `WARN`. Per ulteriori informazioni sull'impostazione dei parametri di configurazione mediante i gruppi di parametri, consultare [Gruppi di parametri per Amazon RDS](USER_WorkingWithParamGroups.md). 1. Se è stato modificato un gruppo di parametri dell'istanza database, riavviare l'istanza. Se il gruppo di parametri è stato modificato per una replica di lettura, riavviare la replica. Per ulteriori informazioni, consulta [Riavvio di un'istanza DB DB](USER_RebootInstance.md). 1. Eseguire l'istanza database e le repliche di lettura con il normale carico di lavoro e monitorare i file di log. Se vengono visualizzati avvisi relativi a transazioni incompatibili con GTID, modificare l'applicazione in modo che usi solo caratteristiche compatibili con GTID. Verificare che l'istanza database non stia generando avvisi relativi a transazioni incompatibili con GTID prima di procedere alla prossima fase. 1. Reimpostare i parametri GTID per la replica basata su GTID che consente le transazioni anonime finché le repliche di lettura non ne completano l'elaborazione. 1. Verificare che il gruppo di parametri associato all'istanza database e ogni replica di lettura abbiano le impostazioni dei parametri seguenti: + `gtid_mode` – `ON_PERMISSIVE` + `enforce_gtid_consistency` – `ON` 1. Se è stato modificato un gruppo di parametri dell'istanza database, riavviare l'istanza. Se il gruppo di parametri è stato modificato per una replica di lettura, riavviare la replica. 1. Attendere il completamento della replica di tutte le transazioni anonime. Per verificare che vengano replicate, procedere come descritto di seguito: 1. Eseguire questa istruzione sull'istanza DB primaria. **MySQL 8.4** ``` SHOW BINARY LOG STATUS; ``` **MySQL 5.7 e 8.0** ``` SHOW MASTER STATUS; ``` Annotare i valori nelle colonne `File` e `Position`. 1. In ogni replica di lettura, utilizzare le informazioni su file e posizione presenti nell’istanza di origine menzionata nella fase precedente per eseguire la query seguente. ``` SELECT MASTER_POS_WAIT('file', position); ``` Ad esempio, se il nome del file è `mysql-bin-changelog.000031` e la posizione è `107`, eseguire l'istruzione seguente. ``` SELECT MASTER_POS_WAIT('mysql-bin-changelog.000031', 107); ``` Se la replica di lettura si trova dopo la posizione specificata, la query la restituisce immediatamente. In caso contrario, la funzione entra in attesa. Passare alla fase successiva quando la query restituisce risposte per tutte le repliche di lettura. 1. Reimpostare i parametri GTID solo per la replica basata su GTID. 1. Verificare che il gruppo di parametri associato all'istanza database e ogni replica di lettura abbiano le impostazioni dei parametri seguenti: + `gtid_mode` – `ON` + `enforce_gtid_consistency` – `ON` 1. Riavviare l'istanza database e ogni replica di lettura. 1. In ogni replica di lettura completare la procedura seguente. **MySQL 8.4 e versioni principali successive** ``` CALL mysql.rds_set_source_auto_position(1); ``` **MySQL 8.0 e versioni secondarie precedenti** ``` CALL mysql.rds_set_master_auto_position(1); ``` # Disabilitazione della replica basata su GTID per un'istanza database MySQL con repliche di lettura Puoi disabilitare la replica basata su GTID per un un'istanza database MySQL con repliche di lettura. **Per disabilitare la replica basata su GTID per un'istanza database MySQL con repliche di lettura** 1. In ogni replica di lettura, esegui questa procedura: **MySQL 8.4 e versioni principali successive** ``` CALL mysql.rds_set_source_auto_position(0); ``` **MySQL 8.0 e versioni secondarie precedenti** ``` CALL mysql.rds_set_master_auto_position(0); ``` 1. Reimpostare `gtid_mode` su `ON_PERMISSIVE`. 1. Verifica che il gruppo di parametri associato all'istanza database MySQL e ogni replica di lettura abbiano `gtid_mode` impostato su `ON_PERMISSIVE`. Per ulteriori informazioni sull'impostazione dei parametri di configurazione mediante i gruppi di parametri, consultare [Gruppi di parametri per Amazon RDS](USER_WorkingWithParamGroups.md). 1. Riavvia l'istanza database MySQL e ogni replica di lettura. Per ulteriori informazioni sul riavvio, consultare [Riavvio di un'istanza DB DB](USER_RebootInstance.md). 1. Reimpostare `gtid_mode` su `OFF_PERMISSIVE`. 1. Verifica che il gruppo di parametri associato all'istanza database MySQL e ogni replica di lettura abbiano `gtid_mode` impostato su `OFF_PERMISSIVE`. 1. Riavvia l'istanza database MySQL e ogni replica di lettura. 1. Attendere che tutte le transazioni GTID vengano applicate a tutte le repliche di lettura. Per verificare che le transazioni siano applicate, esegui queste operazioni: 1. Su un’istanza database MySQL, esegui questo comando: **MySQL 8.4** ``` SHOW BINARY LOG STATUS ``` **MySQL 5.7 e 8.0** ``` SHOW MASTER STATUS ``` L’output visualizzato dovrebbe essere simile al seguente. ``` File Position ------------------------------------ mysql-bin-changelog.000031 107 ------------------------------------ ``` Annotare il file e la posizione nell'output. 1. In ogni replica di lettura, utilizza le informazioni su file e posizione presenti nell’istanza di origine menzionata nella fase precedente per eseguire la query seguente. **MySQL 8.4 e MySQL 8.0.26 e versioni successive a MySQL 8.0** ``` SELECT SOURCE_POS_WAIT('file', position); ``` **MySQL 5.7** ``` SELECT MASTER_POS_WAIT('file', position); ``` Ad esempio, se il nome del file è `mysql-bin-changelog.000031` e la posizione è `107`, eseguire l’istruzione seguente. **MySQL 8.4 e MySQL 8.0.26 e versioni successive a MySQL 8.0** ``` SELECT SOURCE_POS_WAIT('mysql-bin-changelog.000031', 107); ``` **MySQL 5.7** ``` SELECT MASTER_POS_WAIT('mysql-bin-changelog.000031', 107); ``` 1. Reimposta i parametri GTID per disabilitare la replica basata su GTID. 1. Verifica che il gruppo di parametri associato all'istanza database MySQL e ogni replica di lettura abbiano le impostazioni dei parametri seguenti: + `gtid_mode` – `OFF` + `enforce_gtid_consistency` – `OFF` 1. Riavvia l'istanza database MySQL e ogni replica di lettura. # Configurazione della replica della posizione del file di log binario con un'istanza di origine esterna. Puoi impostare la replica fra un'istanza database RDS for MySQL o MariaDB e un’istanza MySQL o MariaDB che è esterna ad Amazon RDS usando la replica del file di log binario. **Topics** + [ ## Prima di iniziare ](#MySQL.Procedural.Importing.External.Repl.BeforeYouBegin) + [ ## Configurazione della replica della posizione del file di log binario con un'istanza di origine esterna. ](#MySQL.Procedural.Importing.External.Repl.Procedure) ## Prima di iniziare È possibile configurare la replica utilizzando la posizione del file di log binario delle transazioni replicate. Le autorizzazioni necessarie per avviare la replica in un'istanza database Amazon RDS sono limitate e non disponibili per l'utente master Amazon RDS. Per questo motivo, assicurati di utilizzare i comandi [mysql.rds\$1set\$1external\$1master (RDS per MariaDB e RDS per MySQL versioni principali 8.0 e precedenti)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) o [mysql.rds\$1set\$1external\$1source (RDS per MySQL versioni principali 8.4 e successive)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source) e [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) in Amazon RDS per configurare la replica tra il database live e il database Amazon RDS. Per impostare il formato di logging binario per un database MySQL o MariaDB, aggiornare il parametro `binlog_format`. Se l’istanza database utilizza il gruppo di parametri di istanza database predefinito, crea un nuovo gruppo di questo tipo per modificare il parametro `binlog_format`. In MariaDB e in MySQL 8.0 e versioni precedenti, il valore predefinito di `binlog_format` è `MIXED`. Tuttavia, puoi anche impostare `binlog_format` su `ROW` o `STATEMENT` se hai bisogno di un formato di registro binario (binlog) specifico. Riavvia l'istanza database affinché venga applicata la modifica. In MySQL 8.4 e versioni successive, il valore predefinito di `binlog_format` è `ROW`. Per ulteriori informazioni sull'impostazione del parametro `binlog_format`, consulta [Configurazione di MySQL RDS per la registrazione binaria MySQL per database Single-AZ](USER_LogAccess.MySQL.BinaryFormat.md) Per ulteriori informazioni sulle implicazioni dei vari tipi di replica MySQL, consulta la pagina relativa a [vantaggi e svantaggi della replica basata su istruzioni e basata su riga](https://dev.mysql.com/doc/refman/8.0/en/replication-sbr-rbr.html) nella documentazione di MySQL. ## Configurazione della replica della posizione del file di log binario con un'istanza di origine esterna. Seguire queste linee guida quando si imposta un'istanza di origine esterna e una replica su Amazon RDS: + Monitorare gli eventi di failover per l'istanza database di Amazon RDS che rappresenta la replica. In caso di failover, l'istanza database che rappresenta la replica potrebbe essere ricreata in un nuovo host con un indirizzo di rete diverso. Per informazioni su come monitorare gli eventi di failover, consulta [Utilizzo della notifica degli eventi di Amazon RDS](USER_Events.md). + Conservare i binlog sull'istanza di origine finché non si ha la conferma che siano stati applicati alla replica. Conservando questi file, si è certi di poter ripristinare l'istanza di origine in caso di errori. + Attivare i backup automatici sull'istanza database di Amazon RDS. L'attivazione dei backup automatici assicura il ripristino della replica a un punto temporale specifico nel caso fosse necessario risincronizzare l'istanza di origine e la replica. Per informazioni su backup e point-in-time ripristino, vedere[Backup, ripristino ed esportazione dei dati](CHAP_CommonTasks.BackupRestore.md). **Per configurare la replica della posizione del file di log binario con un'istanza di origine esterna** 1. Rendere l'istanza MySQL o MariaDB di origine di sola lettura. ``` mysql> FLUSH TABLES WITH READ LOCK; mysql> SET GLOBAL read_only = ON; ``` 1. Eseguire il comando `SHOW MASTER STATUS` nell'istanza database di MySQL o MariaDB di origine per determinare la posizione del binlog. Viene restituito un output simile all'esempio seguente. ``` File Position ------------------------------------ mysql-bin-changelog.000031 107 ------------------------------------ ``` 1. Copiare il database dall'istanza esterna all'istanza database Amazon RDS usando `mysqldump`. Per database di dimensioni particolarmente elevate, è possibile utilizzare la procedura in [Importazione dei dati in un database Amazon RDS per MySQL con tempo di inattività ridotto](mysql-importing-data-reduced-downtime.md). Per Linux, macOS o Unix: ``` mysqldump --databases database_name \ --single-transaction \ --compress \ --order-by-primary \ -u local_user \ -plocal_password | mysql \ --host=hostname \ --port=3306 \ -u RDS_user_name \ -pRDS_password ``` Per Windows: ``` mysqldump --databases database_name ^ --single-transaction ^ --compress ^ --order-by-primary ^ -u local_user ^ -plocal_password | mysql ^ --host=hostname ^ --port=3306 ^ -u RDS_user_name ^ -pRDS_password ``` **Nota** Assicurarsi che non siano presenti spazi tra l'opzione `-p` e la password immessa. Utilizzare le opzioni `--host`, `--user (-u)`, `--port` e `-p` nel comando `mysql` per specificare il nome host, il nome utente, la porta e la password per la connessione all'istanza database Amazon RDS. Il nome host è il nome DNS (Domain Name Service) dell'endpoint dell'istanza database di Amazon RDS, ad esempio `myinstance.123456789012.us-east-1.rds.amazonaws.com`. È possibile trovare il valore dell'endpoint nei dettagli dell'istanza nella Console di gestione AWS. 1. Rendere nuovamente scrivibile l'istanza MySQL o MariaDB di origine. ``` mysql> SET GLOBAL read_only = OFF; mysql> UNLOCK TABLES; ``` Per ulteriori informazioni sulla creazione di backup da utilizzare con la replica, vedere [la documentazione di MySQL](https://dev.mysql.com/doc/refman/8.0/en/replication-solutions-backups-read-only.html). 1. Nel Console di gestione AWS, aggiungi l'indirizzo IP del server che ospita il database esterno al gruppo di sicurezza del cloud privato virtuale (VPC) per l'istanza database Amazon RDS. Per ulteriori informazioni sulla modifica di un gruppo di sicurezza VPC, consulta [Gruppi di sicurezza per il VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) nella *Guida per l'utente di Amazon Virtual Private Cloud*. L'indirizzo IP può cambiare quando vengono soddisfatte le seguenti condizioni: + Si sta utilizzando un indirizzo IP pubblico per la comunicazione tra l'istanza di origine esterna e l'istanza database. + L'istanza di origine esterna è stata arrestata e riavviata. Se queste condizioni vengono soddisfatte, verificare l'indirizzo IP prima di aggiungerlo. Potrebbe anche essere necessario configurare la rete locale per consentire le connessioni dall'indirizzo IP dell'istanza database di Amazon RDS, affinché possa comunicare con l'istanza MySQL o MariaDB esterna. Per individuare l'indirizzo IP dell'istanza database di Amazon RDS, utilizzare il comando `host`. ``` host db_instance_endpoint ``` Il nome host è il nome DNS dall'endpoint dell'istanza database di Amazon RDS. 1. Utilizzando il client scelto, eseguire la connessione all'istanza esterna e creare un utente da utilizzare per la replica. Utilizza questo account unicamente per la replica e limitalo al dominio personale per aumentare la sicurezza. Di seguito è riportato un esempio di : ``` CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password'; ``` **Nota** Specifica una password diversa dal prompt mostrato qui come best practice per la sicurezza. 1. Per l'istanza esterna, concedere i privilegi `REPLICATION CLIENT` e `REPLICATION SLAVE` all'utente della replica. Per concedere ad esempio i privilegi `REPLICATION CLIENT` e `REPLICATION SLAVE` su tutti i database per l'utente "`repl_user`" del proprio dominio, eseguire questo comando. ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com'; ``` 1. Definire l'istanza database di Amazon RDS come replica. A tale scopo, connettersi innanzitutto all'istanza database di Amazon RDS come l'utente master. Quindi, identificare il database MySQL o MariaDB esterno come istanza di origine utilizzando il comando [mysql.rds\$1set\$1external\$1source (RDS per MySQL versioni principali 8.4 e successive)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source) o [mysql.rds\$1set\$1external\$1master (RDS per MariaDB e RDS per MySQL versioni principali 8.0 e precedenti)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master). Utilizzare il nome e la posizione del file di log master recuperati nella fase 2. Di seguito sono riportati esempi di comandi. **MySQL 8.4** ``` CALL mysql.rds_set_external_source ('mysourceserver.mydomain.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 1); ``` **MariaDB e MySQL 8.0 e 5.7** ``` CALL mysql.rds_set_external_master ('mymasterserver.mydomain.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 1); ``` **Nota** In RDS per MySQL è possibile scegliere di utilizzare la replica ritardata eseguendo in alternativa la stored procedure [mysql.rds\$1set\$1external\$1source\$1with\$1delay (RDS per MySQL versioni principali 8.4 e successive)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source_with_delay) o [mysql.rds\$1set\$1external\$1master\$1with\$1delay (RDS per MariaDB e RDS per MySQL versioni principali 8.0 e precedenti)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master_with_delay). Su RDS for MySQL, una ragione per utilizzare la replica ritardata è attuare il ripristino di emergenza con la procedura archiviata [](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until). Attualmente RDS for MariaDB supporta la replica ritardata ma non supporta la procedura `mysql.rds_start_replication_until`. 1. Nell'istanza database di Amazon RDS eseguire il comando [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) per avviare la replica. ``` CALL mysql.rds_start_replication; ``` # Configurazione multi-source-replication per Amazon RDS for MySQL La replica da più origini consente di configurare un’istanza database Amazon RDS per MySQL come replica che riceve eventi del log binario da più di un’istanza database RDS per MySQL di origine. La replica da più origini è supportata per le istanze database RDS per MySQL con le versioni del motore seguenti: + Tutte le versioni di MySQL 8.4 + 8.0.35 e versioni secondarie successive + 5.7.44 e versioni secondarie successive Per informazioni sulla replica da più origini MySQL, consulta [MySQL Multi-Source Replication](https://dev.mysql.com/doc/refman/8.0/en/replication-multi-source.html) nella documentazione MySQL. La documentazione MySQL contiene informazioni dettagliate su questa funzionalità, mentre il presente argomento descrive come configurare e gestire i canali di replica da più origini nelle istanze database RDS per MySQL. ## Casi d’uso per la replica da più origini L’uso della replica da più origini in RDS per MySQL è opportuna per le applicazioni o i requisiti seguenti: + Unione o combinazione di più shard di istanze database separate in un unico shard. + Generazione di report da dati consolidati da più origini. + Creazione di backup consolidati a lungo termine dei dati distribuiti tra più istanze database RDS per MySQL. ## Prerequisiti per la replica da più origini Prima di configurare la replica da più origini, assicurarsi che siano rispettati i prerequisiti seguenti. + Per ogni istanza database RDS per MySQL di origine devono essere abilitati i backup automatici. L’abilitazione dei backup automatici consente di eseguire la registrazione di log binari. Per informazioni su come abilitare i backup automatici, consulta [Abilitazione dei backup automatici](USER_WorkingWithAutomatedBackups.Enabling.md). + Per evitare errori di replica, si consiglia di bloccare le operazioni di scrittura nelle istanze database di origine. A tale scopo, impostare il parametro `read-only` su `ON` in un gruppo di parametri personalizzato collegato all’istanza database RDS per MySQL di origine. Puoi usare Console di gestione AWS o the AWS CLI per creare un nuovo gruppo di parametri personalizzato o per modificarne uno esistente. Per ulteriori informazioni, consultare [Creazione di un gruppo di parametri database in Amazon RDS](USER_WorkingWithParamGroups.Creating.md) e [Modifica dei parametri in un gruppo di parametri database in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). + Per ogni istanza database di origine, aggiungere l’indirizzo IP dell’istanza database al gruppo di sicurezza Amazon Virtual Private Cloud (VPC) per l’istanza database da più origini. Per identificare l’indirizzo IP di un’istanza database di origine, eseguire il comando `dig RDS Endpoint` da un’istanza Amazon EC2 nello stesso gruppo VPC dell’istanza database da più origini. + Per ogni istanza database di origine, utilizzare un client per connettersi all’istanza database e creare un utente del database con i privilegi richiesti per la replica, come nell’esempio seguente. ``` CREATE USER 'repl_user' IDENTIFIED BY 'password'; GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'; ``` **Nota** A partire da MySQL 8.4, il privilegio `REPLICATION SLAVE` è obsoleto ed è stato sostituito da `REPLICATION REPLICA`. Per MySQL 8.4 e versioni successive, utilizzare la sintassi seguente: ``` CREATE USER 'repl_user' IDENTIFIED BY 'password'; GRANT REPLICATION CLIENT, REPLICATION REPLICA ON *.* TO 'repl_user'; ``` ## Configurazione di canali di replica da più origini in istanze database RDS per MySQL La configurazione dei canali di replica da più origini è analoga a quella della replica da un’unica origine. Per la replica da più origini, attiva innanzitutto la registrazione di log binari nell’istanza di origine. Successivamente, importa i dati dalle origini nella replica da più origini, quindi avvia la replica da ciascuna origine utilizzando le coordinate del log binario oppure il posizionamento automatico GTID. Per configurare un’istanza database RDS per MySQL come replica da più origini di due o più istanze database RDS per MySQL, esegui queste operazioni. **Topics** + [ ### Fase 1: importare i dati dalle istanze database di origine alla replica da più origini ](#mysql-multi-source-replication-import) + [ ### Fase 2: avviare la replica dalle istanze database di origine nella replica da più origini ](#mysql-multi-source-replication-setting-up-start-replication-other) ### Fase 1: importare i dati dalle istanze database di origine alla replica da più origini Esegui le operazioni seguenti per ogni istanza database di origine. Prima di importare i dati da un’origine nella replica da più origini, esegui il comando `SHOW MASTER STATUS` per determinare il file di log binario e la posizione correnti. Annota questi dettagli per utilizzarli nella fase successiva. In questo output di esempio, il file è `mysql-bin-changelog.000031` e la posizione è `107`. **Nota** A partire da MySQL 8.4, il comando `SHOW MASTER STATUS` è obsoleto ed è stato sostituito da `SHOW BINARY LOG STATUS`. Per MySQL 8.4 e versioni successive, utilizza `SHOW BINARY LOG STATUS`. ``` File Position ----------------------------------- mysql-bin-changelog.000031 107 ----------------------------------- ``` Copia il database dall’istanza database di origine nella replica da più origini utilizzando `mysqldump`, come nell’esempio seguente. ``` mysqldump --databases database_name \ --single-transaction \ --compress \ --order-by-primary \ -u RDS_user_name \ -p RDS_password \ --host=RDS Endpoint | mysql \ --host=RDS Endpoint \ --port=3306 \ -u RDS_user_name \ -p RDS_password ``` Dopo aver copiato il database, è possibile impostare il parametro di sola lettura su `OFF` nell’istanza database di origine. ### Fase 2: avviare la replica dalle istanze database di origine nella replica da più origini Per ogni istanza database di origine, utilizza le credenziali dell’utente amministratore per connetterti all’istanza ed esegui le due stored procedure seguenti che configurano la replica su un canale e la avviano. In questo esempio si utilizzano il nome e la posizione del file binlog restituito dall’esempio nella fase precedente. ``` CALL mysql.rds_set_external_source_for_channel('mysourcehost.example.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 1, 'channel_1'); CALL mysql.rds_start_replication_for_channel('channel_1'); ``` Per ulteriori informazioni sull’utilizzo di queste e di altre stored procedure per l’impostazione e la gestione dei canali di replica, consulta [Gestione della replica da più origini](mysql-stored-proc-multi-source-replication.md). ## Utilizzo dei filtri con la replica da più origini I filtri di replica consentono di specificare quali database e tabelle vengono replicati con una replica da più origini. I filtri di replica possono includere database e tabelle nella replica o escluderli dalla replica. Per ulteriori informazioni sui filtri di replica, consulta [Configurazione dei filtri di replica con MySQL](USER_MySQL.Replication.ReadReplicas.ReplicationFilters.md). Con la replica da più origini è possibile configurare i filtri di replica a livello globale oppure a livello di canale. L’applicazione dei filtri a livello di canale è possibile solo nelle istanze database supportate che eseguono la versione 8.0 o la versione 8.4. Gli esempi seguenti mostrano come configurare i filtri a livello globale oppure a livello di canale. Per l’applicazione dei filtri nella replica da più origini, tenere presente i requisiti seguenti: + I nomi dei canali devono essere racchiusi tra backtick (``). + Se si modificano i filtri di replica nel gruppo di parametri, l’elemento `sql_thread` della replica da più origini per tutti i canali con aggiornamenti viene riavviato per applicare dinamicamente le modifiche. Se un aggiornamento coinvolge un filtro globale, tutti i canali di replica in stato di esecuzione vengono riavviati. + Tutti i filtri globali vengono applicati prima di qualsiasi filtro specifico del canale. + Se un filtro viene applicato globalmente e a livello di canale, si utilizza solo il filtro a livello di canale. Ad esempio, se i filtri sono `replicate_ignore_db="db1,`channel_22`:db2"`, il filtro `replicate_ignore_db` impostato su `db1` viene applicato a tutti a canali ad eccezione di `channel_22` e solo `channel_22` ignora le modifiche da `db2`. Esempio 1. Impostazione di un filtro globale Nell’esempio seguente, il database `temp_data` è escluso dalla replica in ogni canale. Per Linux, macOS o Unix: ``` aws rds modify-db-parameter-group \ --db-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-ignore-db,ParameterValue='temp_data',ApplyMethod=immediate" ``` Esempio 2. Impostazione di un filtro a livello di canale Nell’esempio seguente, le modifiche dal database `sample22` sono incluse sono nel canale `channel_22`. In modo analogo, le modifiche dal database `sample99` sono incluse solo nel canale `channel_99`. Per Linux, macOS o Unix: ``` aws rds modify-db-parameter-group \ --db-parameter-group-name myparametergroup \ --parameters "ParameterName=replicate-do-db,ParameterValue='\`channel_22\`:sample22,\`channel_99\`:sample99',ApplyMethod=immediate" ``` ## Monitoraggio di canali di replica da più origini Per monitorare i singoli canali in una replica da più origini, utilizzare uno dei metodi seguenti: + Per monitorare lo stato di tutti i canali o di un canale specifico, connettersi alla replica da più origini ed eseguire il comando `SHOW REPLICA STATUS` o `SHOW REPLICA STATUS FOR CHANNEL 'channel_name'`. Per ulteriori informazioni, consulta [Verifica dello stato della replica](https://dev.mysql.com/doc/refman/8.0/en/replication-administration-status.html) nella documentazione MySQL. + Per ricevere una notifica quando un canale di replica viene avviato, interrotto o rimosso, utilizzare la notifica di eventi RDS. Per ulteriori informazioni, consulta [Utilizzo della notifica degli eventi di Amazon RDS](USER_Events.md). + Per monitorare il ritardo per un canale specifico, controllare la relativa metrica `ReplicationChannelLag`. I punti dati per questa metrica hanno un periodo di 60 secondi (1 minuto) e sono disponibili per 15 giorni. Per individuare il ritardo del canale di replica per un canale, utilizzare l’identificatore di istanza e il nome del canale di replica. Per ricevere una notifica quando questo ritardo supera una determinata soglia, puoi impostare un CloudWatch allarme. Per ulteriori informazioni, consulta [Monitoraggio dei parametri di Amazon RDS Aurora con Amazon CloudWatch](monitoring-cloudwatch.md). ## Considerazioni e best practice per la replica da più origini Prima di utilizzare la replica da più origini in RDS per MySQL, rivedere le considerazioni e le best practice seguenti: + Verificare che un’istanza database configurata come replica da più origini disponga di risorse sufficienti, ad esempio throughput, memoria, CPU e IOPS, per gestire il carico di lavoro proveniente da più istanze di origine. + Monitorare regolarmente l’uso delle risorse sulla replica da più origini e modificare la configurazione dell’archiviazione o dell’istanza per gestire il carico di lavoro senza sovraccaricare le risorse. + Impostare la variabile di sistema `replica_parallel_workers` su un valore maggiore di `0` per configurare la replica multi-thread in una replica da più origini. In questo caso, il numero di thread assegnati a ciascun canale è il valore della variabile più un thread di coordinamento per gestire i thread dell’applicatore. + Configurare i filtri di replica in modo appropriato per evitare conflitti. Per replicare un intero database su un altro database in una replica, è possibile utilizzare l’opzione `--replicate-rewrite-db`. Ad esempio, si possono replicare tutte le tabelle del database A nel database B in un’istanza di replica. Questo approccio può essere utile quando tutte le istanze di origine utilizzano la stessa convenzione di denominazione dello schema. Per informazioni sull’opzione `--replicate-rewrite-db`, consulta [Replica Server Options and Variables](https://dev.mysql.com/doc/refman/8.0/en/replication-options-replica.html) nella documentazione MySQL. + Per evitare errori di replica, non scrivere sulla replica. Si consiglia di abilitare il parametro `read_only` sulle repliche da più origini per bloccare le operazioni di scrittura. In tal modo è possibile eliminare i problemi di replica causati da operazioni di scrittura in conflitto. + Per aumentare le prestazioni delle operazioni di lettura, ad esempio ordinamenti e join a carico elevato, eseguite sulla replica da più origini, considerare l’utilizzo di Letture ottimizzate per Amazon RDS. Questa funzionalità può essere utile per le query che dipendono da tabelle temporanee o da file di ordinamento di grandi dimensioni. Per ulteriori informazioni, consulta [Prestazioni delle query migliorate per RDS per MySQL con Amazon RDS Optimized Reads](rds-optimized-reads.md). + Per ridurre il ritardo nella replica e migliorare le prestazioni di una replica da più origini, si consiglia di abilitare scritture ottimizzate. Per ulteriori informazioni, consulta [Prestazioni di scrittura migliorate con Scritture ottimizzate per Amazon RDS per MySQL](rds-optimized-writes.md). + Eseguire operazioni di gestione, ad esempio la modifica della configurazione, su un canale alla volta ed evitare di apportare modifiche a più canali da più connessioni per non provocare conflitti nelle operazioni di replica. Se si eseguono simultaneamente le procedure `rds_skip_repl_error_for_channel` e `rds_start_replication_for_channel` da più connessioni, ad esempio, gli eventi possono essere ignorati in un canale diverso da quello previsto. + È possibile abilitare i backup su un’istanza di replica da più origini ed esportare i dati da tale istanza in un bucket Amazon S3 per archiviarli a lungo termine. Tuttavia, è importante configurare anche i backup con una conservazione appropriata nelle singole istanze di origine. Per informazioni sull’esportazione dei dati di snapshot in Amazon S3, consulta [Supporto per l’esportazione di dati dello snapshot del database in Amazon S3 per Amazon RDS](USER_ExportSnapshot.md). + È possibile creare repliche di lettura da una replica da più origini per distribuirvi il carico di lavoro di lettura. È possibile individuare queste repliche di lettura in diversi modi in Regioni AWS base ai requisiti dell'applicazione. Per ulteriori informazioni sulle repliche di lettura, consulta [Uso delle repliche di lettura MySQL](USER_MySQL.Replication.ReadReplicas.md). ## Limitazioni per la replica da più origini in RDS per MySQL Alla replica da più origini in RDS per MySQL si applicano le limitazioni seguenti: + Per una replica da più origini, RDS per MySQL supporta attualmente la configurazione di un massimo di 15 canali. + Un’istanza di replica di lettura non può essere configurata come replica da più origini. + Per configurare la replica da più origini in RDS per MySQL con versione del motore 5.7, è necessario abilitare lo schema delle prestazioni sull’istanza di replica. L’abilitazione dello schema delle prestazioni è facoltativa in RDS per MySQL con versione del motore 8.0 o 8.4. + In RDS per MySQL con versione del motore 5.7, i filtri di replica si applicano a tutti i canali di replica. In RDS per MySQL con versione del motore 8.0 o 8.4, è possibile configurare filtri che si applicano a tutti i canali di replica oppure a singoli canali. + Il ripristino di un'istantanea RDS o l'esecuzione di un Point-in-time-Restore (PITR) non ripristinano le configurazioni dei canali di replica da più fonti. + Quando si crea una replica di lettura di una replica da più origini, vengono replicati solo i dati dell’istanza da più origini e non viene ripristinata alcuna configurazione dei canali. + MySQL non supporta la configurazione di un numero diverso di worker paralleli per canale. A ogni canale viene assegnato lo stesso numero di worker paralleli in base al valore `replica_parallel_workers`. Se la destinazione di replica da più origini è un cluster di database Multi-AZ, si applicano le limitazioni aggiuntive seguenti: + È necessario configurare un canale per un’istanza RDS per MySQL di origine prima che sia possibile scrivere su tale istanza. + Per ogni istanza RDS per MySQL di origine, la replica basata su GTID deve essere abilitata. + Un evento di failover sul cluster di database rimuove la configurazione di replica da più origini. Il ripristino di tale configurazione richiede la ripetizione delle operazioni di configurazione. # Configurazione di cluster attivi-attivi in RDS per MySQL In Amazon RDS, un cluster attivo-attivo è una configurazione di database in cui più nodi gestiscono attivamente le operazioni di lettura e scrittura, distribuendo il carico di lavoro tra le istanze per migliorare la disponibilità e la scalabilità. Ogni nodo del cluster è sincronizzato per mantenere la coerenza dei dati, garantendo un’elevata disponibilità e un failover più rapido in caso di guasto del nodo. È possibile configurare un cluster attivo-attivo in RDS per MySQL utilizzando il plugin di replica di gruppo MySQL. Il plugin di replica di gruppo è supportato per le istanze database RDS per MySQL con le versioni del motore seguenti: + Tutte le versioni di MySQL 8.4 + MySQL 8.0.35 e versioni secondarie successive Per informazioni sulla replica di gruppo MySQL, consulta [ Group Replication](https://dev.mysql.com/doc/refman/8.0/en/group-replication.html) nella documentazione MySQL. La documentazione MySQL contiene informazioni dettagliate su questa funzionalità, mentre il presente argomento descrive come configurare e gestire il plugin nelle istanze database RDS per MySQL. **Nota** Per brevità, tutte le menzioni di cluster “attivo-attivo” in questo argomento si riferiscono ai cluster attivi-attivi che utilizzano il plugin di replica di gruppo MySQL. ## Casi d’uso per cluster attivi-attivi Di seguito sono indicati i casi d’uso in cui è opportuno utilizzare i cluster attivi-attivi: + Applicazioni che richiedono tutte le istanze database nel cluster per supportare le operazioni di scrittura. Il plugin di replica di gruppo mantiene i dati coerenti su ogni istanza database nel cluster attivo-attivo. Per ulteriori informazioni sul funzionamento, consulta [ Group Replication](https://dev.mysql.com/doc/refman/8.0/en/group-replication-summary.html) nella documentazione MySQL. + Applicazioni che richiedono la disponibilità continua del database. In un cluster attivo-attivo i dati vengono mantenuti in tutte le istanze database del cluster. Se in un’istanza database si verifica un errore, l’applicazione può reindirizzare il traffico verso un’altra istanza database del cluster. + Applicazioni per cui può essere necessario suddividere le operazioni di lettura e scrittura tra diversi istanze database del cluster per scopi di bilanciamento del carico. In un cluster attivo-attivo le applicazioni possono inviare traffico di lettura a istanze database specifiche e traffico di scrittura ad altre. È anche possibile cambiare le istanze database a cui inviare letture o scritture in qualsiasi momento. **Topics** + [ ## Casi d’uso per cluster attivi-attivi ](#mysql-active-active-clusters-benefits) + [ # Limitazioni e considerazioni relative ai cluster attivi-attivi ](mysql-active-active-clusters-considerations-limitations.md) + [ # Preparazione per un cluster attivo-attivo tra VPC ](mysql-active-active-clusters-cross-vpc-prerequisites.md) + [ # Impostazioni dei parametri richieste per i cluster attivi-attivi ](mysql-active-active-clusters-parameters.md) + [ # Conversione di un’istanza database esistente in un cluster attivo-attivo ](mysql-active-active-clusters-converting.md) + [ # Configurazione di un cluster attivo-attivo con nuove istanze database ](mysql-active-active-clusters-setting-up.md) + [ # Aggiunta di un’istanza database a un cluster attivo-attivo ](mysql-active-active-clusters-adding.md) + [ # Monitoraggio dei cluster attivi-attivi ](mysql-active-active-clusters-monitoring.md) + [ # Arresto della replica di gruppo in un’istanza database in un cluster attivo-attivo ](mysql-active-active-clusters-stopping.md) + [ # Ridenominazione di un’istanza database in un cluster attivo-attivo ](mysql-active-active-clusters-renaming.md) + [ # Rimozione di un’istanza database da un cluster attivo-attivo ](mysql-active-active-clusters-remove.md) # Limitazioni e considerazioni relative ai cluster attivi-attivi In Amazon RDS i cluster attivi-attivi offrono disponibilità e scalabilità migliorate grazie alla possibilità di distribuire i carichi di lavoro su più istanze. Quando si utilizza questa architettura, tuttavia, è necessario tenere presente alcune limitazioni e considerazioni importanti. Nelle sezioni seguenti vengono descritti fattori chiave come i ritardi di replica, la risoluzione dei conflitti, l’allocazione delle risorse e il comportamento di failover. È importante comprendere queste considerazioni per garantire prestazioni e affidabilità ottimali nelle implementazioni di cluster attivi-attivi. **Topics** + [ ## Limitazioni per i cluster attivi-attivi in RDS per MySQL ](#mysql-active-active-clusters-limitations) + [ ## Considerazioni e best practice per i cluster attivi-attivi di RDS per MySQL ](#mysql-active-active-clusters-considerations) ## Limitazioni per i cluster attivi-attivi in RDS per MySQL Le seguenti limitazioni si applicano ai cluster attivi-attivi in RDS per MySQL: + Per le istanze database di un cluster attivo-attivo, il nome utente principale non può essere `rdsgrprepladmin` perché tale nome è riservato alle connessioni di replica di gruppo. + Per le istanze database con repliche di lettura in cluster attivi-attivi, uno stato di replica prolungato diverso da `Replicating` può comportare il superamento dei limiti di archiviazione da parte dei file di log. Per informazioni sullo stato delle repliche di lettura, consulta [Monitoraggio della replica di lettura](USER_ReadRepl.Monitoring.md). + Le implementazioni blu/verde non sono supportate nelle istanze database di un cluster attivo-attivo. Per ulteriori informazioni, consulta [Utilizzo di Amazon RDS Blue/Green Aurora Deployments per gli aggiornamenti del database](blue-green-deployments.md). + L’autenticazione Kerberos non è supportata nelle istanze database di un cluster attivo-attivo. Per ulteriori informazioni, consulta [Utilizzo dell’autenticazione Kerberos per Amazon RDS per MySQL](mysql-kerberos.md). + Le istanze database di un cluster di database Multi-AZ non possono essere aggiunte a un cluster attivo-attivo, a differenza delle istanze database in un’implementazione di istanze database Multi-AZ per cui l’aggiunta è possibile. Per ulteriori informazioni, consulta [Configurazione e gestione di un’implementazione Multi-AZ per Amazon RDS](Concepts.MultiAZ.md). + Le tabelle per cui non esiste una chiave primaria non vengono replicate in un cluster attivo-attivo perché le scritture vengono rifiutate dal plugin di replica di gruppo. + Le tabelle non InnoDB non vengono replicate in un cluster attivo-attivo. + I cluster attivi-attivi non supportano istruzioni DML e DDL simultanee su istanze database diverse nel cluster. + Non è possibile configurare un cluster attivo-attivo per utilizzare la modalità primaria singola per la modalità di replica di gruppo. Per questa configurazione, si consiglia di utilizzare un cluster di database Multi-AZ. Per ulteriori informazioni, consulta [Implementazioni di cluster di database Multi-AZ per Amazon RDS](multi-az-db-clusters-concepts.md). + La replica da più origini non è supportata per le istanze database di un cluster attivo-attivo. + Un cluster attivo-attivo tra Regioni non può imporre la verifica dell’autorità di certificazione (CA) per le connessioni di replica di gruppo. ## Considerazioni e best practice per i cluster attivi-attivi di RDS per MySQL Prima di utilizzare i cluster attivi-attivi di RDS per MySQL, esamina le considerazioni e le best practice seguenti: + Nei cluster attivi-attivi non possono essere presenti più di nove istanze database. + Il plugin di replica di gruppo consente di controllare le garanzie di coerenza delle transazioni del cluster attivo-attivo. Per ulteriori informazioni, consulta [Transaction Consistency Guarantees](https://dev.mysql.com/doc/refman/8.0/en/group-replication-consistency-guarantees.html) nella documentazione MySQL. + Quando istanze database diverse aggiornano la stessa riga in un cluster attivo-attivo, possono verificarsi conflitti. Per informazioni sui conflitti e la relativa risoluzione, consulta [Group Replication](https://dev.mysql.com/doc/refman/8.0/en/group-replication-summary.html) nella documentazione MySQL. + Per la tolleranza ai guasti, includere almeno tre istanze database nel cluster attivo-attivo. È possibile configurare un cluster attivo-attivo solamente con una o due istanze database, ma il cluster non sarà tollerante ai guasti. Per informazioni sulla tolleranza ai guasti, consulta [Fault-tolerance](https://dev.mysql.com/doc/refman/8.0/en/group-replication-fault-tolerance.html) nella documentazione MySQL. + Quando un’istanza database si unisce a un cluster attivo-attivo esistente ed esegue la versione del motore uguale a quella minima del cluster, l’istanza database si unisce in modalità di lettura/scrittura. + Quando un’istanza database si unisce a un cluster attivo-attivo esistente ed esegue una versione del motore successiva a quella minima del cluster, l’istanza database deve rimanere in modalità di sola lettura. + Se si abilita la replica di gruppo per un'istanza DB impostando il relativo `rds.group_replication_enabled` parametro su `1` nel gruppo di parametri DB, ma la replica non è iniziata o non è riuscita, l'istanza DB viene messa in super-read-only modalità per evitare incoerenze tra i dati. Per informazioni sulla super-read-only modalità, consulta la documentazione di [MySQL](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_super_read_only). + È possibile aggiornare un’istanza database in un cluster attivo-attivo, ma l’istanza rimane di sola lettura fino a quando tutte le altre istanze database del cluster attivo-attivo non vengono aggiornate alla stessa versione del motore oppure a una versione successiva. Quando si aggiorna un’istanza database, l’istanza si unisce automaticamente allo stesso cluster attivo-attivo al termine dell’aggiornamento. Per evitare che un’istanza database passi involontariamente alla modalità di sola lettura, disabilitarne gli aggiornamenti automatici delle versioni secondarie. Per informazioni sull’aggiornamento di un’istanza database MySQL, consulta [Aggiornamenti del motore di database RDS per MySQL](USER_UpgradeDBInstance.MySQL.md). + È possibile aggiungere un’istanza database in un’implementazione di istanze database Multi-AZ a un cluster attivo-attivo esistente. È anche possibile convertire un’istanza database Single-AZ di un cluster attivo-attivo a un’implementazione di istanza database Multi-AZ. Se in un’istanza database di un’implementazione Multi-AZ si verifica un errore, viene eseguito il failover dell’istanza primaria all’istanza di standby. La nuova istanza database primaria si unisce automaticamente allo stesso cluster al termine del failover. Per ulteriori informazioni sulle implementazioni di istanze database Multi-AZ, consulta [Implementazioni di istanze database Multi-AZ per Amazon RDS](Concepts.MultiAZSingleStandby.md). + È consigliabile che gli intervalli di tempo per le finestre di manutenzione delle istanze database di un cluster attivo-attivo siano diversi. In tal modo si evita che più istanze database del cluster siano contemporaneamente offline per la manutenzione. Per ulteriori informazioni, consulta [Finestra di manutenzione Amazon RDS](USER_UpgradeDBInstance.Maintenance.md#Concepts.DBMaintenance). + I cluster attivi-attivi possono utilizzare SSL per le connessioni tra istanze database. Per configurare le connessioni SSL, impostare i parametri [ group\$1replication\$1recovery\$1use\$1ssl](https://dev.mysql.com/doc/refman/8.0/en/group-replication-system-variables.html#sysvar_group_replication_recovery_use_ssl) e [ group\$1replication\$1ssl\$1mode](https://dev.mysql.com/doc/refman/8.0/en/group-replication-system-variables.html#sysvar_group_replication_ssl_mode) i cui valori devono corrispondere per tutte le istanze database del cluster attivo-attivo. Attualmente, i cluster attivi-attivi non supportano la verifica dell’autorità di certificazione (CA) per le connessioni tra Regioni AWS. Di conseguenza, è necessario impostare il parametro [ group\$1replication\$1ssl\$1mode](https://dev.mysql.com/doc/refman/8.0/en/group-replication-system-variables.html#sysvar_group_replication_ssl_mode) su `DISABLED` (impostazione predefinita) o su `REQUIRED` per cluster tra Regioni. + Un cluster attivo-attivo RDS per MySQL viene eseguito in modalità multiprimaria. Il valore predefinito di [ group\$1replication\$1enforce\$1update\$1everywhere\$1checks](https://dev.mysql.com/doc/refman/8.0/en/group-replication-system-variables.html#sysvar_group_replication_enforce_update_everywhere_checks) è `ON` e il parametro è statico. Quando il parametro è impostato su `ON`, le applicazioni non possono effettuare inserimenti in una tabella con vincoli di chiave esterna a cascata. + Un cluster attivo-attivo RDS per MySQL utilizza lo stack di comunicazione MySQL per la sicurezza della connessione anziché XCOM. Per ulteriori informazioni, consulta [Communication Stack for Connection Security Management](https://dev.mysql.com/doc/refman/8.0/en/group-replication-connection-security.html) nella documentazione MySQL. + Quando un gruppo di parametri database è associato a un’istanza database di un cluster attivo-attivo, si consiglia di associarlo solo ad altre istanze database presenti nel cluster. + I cluster attivi-attivi supportano solo le istanze database RDS per MySQL. Tali istanze devono eseguire versioni supportate del motore di database. + Quando in un’istanza database di un cluster attivo-attivo si verifica un errore imprevisto, RDS avvia automaticamente il ripristino di tale istanza. Se l'istanza DB non viene ripristinata, consigliamo di sostituirla con una nuova istanza DB eseguendo un point-in-time ripristino con un'istanza DB integra nel cluster. Per istruzioni, consulta [Aggiunta di un’istanza database a un cluster attivo-attivo tramite il recupero point-in-time](mysql-active-active-clusters-adding.md#mysql-active-active-clusters-adding-pitr). + È possibile eliminare un’istanza database di un cluster attivo-attivo senza influire sulle altre istanze database del cluster. Per informazioni sulla creazione di un’istanza database, consulta [Eliminazione di un'istanza database](USER_DeleteInstance.md). + Quando un’istanza database esce involontariamente da un cluster attivo-attivo, per impostazione predefinita il valore del parametro `group_replication_exit_state_action` cambia in `OFFLINE_MODE`. In questo stato, l’istanza database non è accessibile ed è necessario riavviarla per riportarla online e unirla nuovamente al cluster. Per cambiare questo comportamento, modifica il parametro `group_replication_exit_state_action` in un gruppo di parametri personalizzato. Se si imposta il parametro su `READ_ONLY`, quando l’istanza database esce involontariamente da un cluster passa a uno stato super-read-only anziché allo stato offline. # Preparazione per un cluster attivo-attivo tra VPC È possibile configurare un cluster attivo-attivo con istanze database Amazon RDS per MySQL in più di un VPC. VPCs Possono essere uguali Regione AWS o diversi Regioni AWS. **Nota** L'invio di traffico tra più Regioni AWS utenti potrebbe comportare costi aggiuntivi. Per ulteriori informazioni, consulta [Overview of Data Transfer Costs for Common Architectures](https://aws.amazon.com/blogs/architecture/overview-of-data-transfer-costs-for-common-architectures/). Se configuri un cluster attivo-attivo in un singolo VPC, puoi saltare questi passaggi e passare a [Configurazione di un cluster attivo-attivo con nuove istanze database](mysql-active-active-clusters-setting-up.md). **Per prepararsi a un cluster attivo-attivo con istanze database in più di un VPC** 1. Assicurati che gli intervalli di IPv4 indirizzi nei blocchi CIDR soddisfino i seguenti requisiti: + Gli intervalli di IPv4 indirizzi nei blocchi CIDR di non VPCs possono sovrapporsi. + Tutti gli intervalli di IPv4 indirizzi nei blocchi CIDR devono essere inferiori `128.0.0.0/subnet_mask` o superiori a 128.0.0.0/. *subnet\$1mask* Gli intervalli seguenti illustrano questi requisiti: + La presenza di `10.1.0.0/16` in un VPC e di `10.2.0.0/16` nell’altro VPC è supportata. + La presenza di `172.1.0.0/16` in un VPC e di `172.2.0.0/16` nell’altro VPC è supportata. + La presenza di `10.1.0.0/16` in un VPC e di `10.1.0.0/16` nell’altro VPC *non è* supportata perché gli intervalli si sovrappongono. + La presenza di `10.1.0.0/16` in un VPC e di `172.1.0.0/16` nell’altro VPC *non è* supportata perché un intervallo è inferiore a `128.0.0.0/subnet_mask` e l’altro è superiore a `128.0.0.0/subnet_mask`. Per informazioni sugli intervalli CIDR, consulta [ VPC CIDR blocks](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-cidr-blocks.html) nella *Guida per l’utente di Amazon VPC*. 1. In ogni VPC, verifica che la risoluzione e nomi host DNS siano entrambi abilitati. Per istruzioni, consulta [Visualizzazione e aggiornamento degli attributi DNS per il VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating) nella *Guida per l’utente di Amazon VPC*. 1. Configurali VPCs in modo da poter indirizzare il traffico tra di essi in uno dei seguenti modi: + Crea una connessione peering VPC tra. VPCs Per istruzioni, consulta [Creazione di una connessione peering VPC](https://docs.aws.amazon.com/vpc/latest/peering/create-vpc-peering-connection.html) nella *Guida per il peering VPC Amazon*. In ogni VPC, verifica che siano presenti regole in entrata per i gruppi di sicurezza che fanno riferimento a gruppi di sicurezza nel VPC collegato in peering. In questo modo, si consente il traffico verso e da istanze associate al gruppo di sicurezza a cui si fa riferimento nel VPC collegato in peering. Per istruzioni, consulta [Aggiornamento dei gruppi di sicurezza per fare riferimento a gruppi di sicurezza peer di riferimento](https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-security-groups.html) nella *Guida per il peering VPC Amazon*. + Crea un gateway di transito tra. VPCs Per istruzioni, consulta [Nozioni di base sui gateway di transito](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-getting-started.html) in *Amazon VPC Transit Gateway*. In ogni VPC, verifica che siano presenti regole in entrata per i gruppi di sicurezza che consentano il traffico proveniente dall’altro VPC, ad esempio regole in entrata che specificano il CIDR dell’altro VPC. In questo modo, si consente il traffico verso e da istanze associate al gruppo di sicurezza a cui si fa riferimento nel cluster attivo-attivo. Per ulteriori informazioni, consulta [Controlla il traffico verso AWS le tue risorse utilizzando i gruppi di sicurezza](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html#working-with-security-groups) nella *Amazon VPC User Guide*. # Impostazioni dei parametri richieste per i cluster attivi-attivi In Amazon RDS per MySQL, la configurazione dei parametri per i cluster attivi-attivi è essenziale per mantenere prestazioni e stabilità operativa costanti. Questa tabella descrive in dettaglio i parametri chiave che controllano la replica, la risoluzione dei conflitti e la distribuzione del carico di lavoro. La corretta configurazione garantisce una sincronizzazione efficiente tra i nodi, riduce il ritardo di replica e ottimizza l’utilizzo delle risorse in ambienti distribuiti oppure a traffico elevato. | Parametro | Descrizione | Impostazione obbligatoria | | --- | --- | --- | | `binlog_format` | Imposta il formato per la registrazione di log binari. Il valore predefinito per RDS per MySQL 8.0 e versioni precedenti è `MIXED`. Il valore predefinito per RDS per MySQL 8.4 è `ROW`. Per ulteriori informazioni, consulta [ la documentazione MySQL](https://dev.mysql.com/doc/refman/8.0/en/replication-options-binary-log.html#sysvar_binlog_format). | `ROW` | | `enforce_gtid_consistency` | Applica la coerenza GTID per l’esecuzione delle istruzioni. Il valore predefinito per RDS per MySQL è `OFF`. Per ulteriori informazioni, consulta [ la documentazione MySQL](https://dev.mysql.com/doc/refman/8.0/en/replication-options-gtids.html#sysvar_enforce_gtid_consistency). | `ON` | | `group_replication_group_name` | Imposta il nome della replica di gruppo su un UUID. Il formato UUID è `11111111-2222-3333-4444-555555555555`. Per generare un UUID MySQL, connettiti a un’istanza database MySQL ed esegui `SELECT UUID()`. Il valore deve essere lo stesso per tutte le istanze database del cluster attivo-attivo. Per ulteriori informazioni, consulta [ la documentazione MySQL](https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functions.html#function_uuid). | UUID MySQL | | `gtid-mode` | Controlla la registrazione di log basata su GTID. Il valore predefinito per RDS per MySQL è `OFF_PERMISSIVE`. Per ulteriori informazioni, consulta [ la documentazione MySQL](https://dev.mysql.com/doc/refman/8.0/en/replication-options-gtids.html#sysvar_gtid_mode). | `ON` | | `rds.custom_dns_resolution` | Specifica se consentire la risoluzione DNS dal server Amazon DNS al VPC in uso. La risoluzione DNS deve essere abilitata quando la replica di gruppo è abilitata con il parametro `rds.group_replication_enabled`. La risoluzione DNS non può essere abilitata quando la replica di gruppo è disabilitata con il parametro `rds.group_replication_enabled`. Per ulteriori informazioni, consulta [Amazon DNS Server](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#AmazonDNS) nella *Guida per l’utente di Amazon VPC*. | `1` | | `rds.group_replication_enabled` | Specifica se la replica di gruppo è abilitata per un’istanza database. In un cluster attivo-attivo la replica di gruppo deve essere abilitata in un’istanza database. | `1` | | `replica_preserve_commit_order` (RDS per MySQL 8.4 e versioni successive) o `slave_preserve_commit_order` (RDS per MySQL 8.0) | Controlla l’ordine in cui viene eseguito il commit delle transazioni in una replica. Il valore predefinito per RDS per MySQL è `ON`. Per ulteriori informazioni, consulta [ la documentazione MySQL](https://dev.mysql.com/doc/refman/8.0/en/replication-options-replica.html#sysvar_slave_preserve_commit_order). | `ON` | # Conversione di un’istanza database esistente in un cluster attivo-attivo La versione del motore di database dell’istanza database da migrare in cluster attivo-attivo deve essere una delle seguenti: + Tutte le versioni di MySQL 8.4 + MySQL 8.0.35 e versioni secondarie successive Se è necessario aggiornare la versione del motore, consulta [Aggiornamenti del motore di database RDS per MySQL](USER_UpgradeDBInstance.MySQL.md). Se configuri un cluster attivo-attivo con istanze database in più di un cloud privato virtuale, verifica che i prerequisiti in [Preparazione per un cluster attivo-attivo tra VPC](mysql-active-active-clusters-cross-vpc-prerequisites.md) siano soddisfatti. Per migrare un’istanza database esistente in un cluster attivo-attivo per RDS per MySQL, esegui queste operazioni. **Topics** + [ ## Fase 1: impostare i parametri del cluster attivo-attivo in uno o più gruppi di parametri personalizzati ](#mysql-active-active-clusters-converting-parameter-group) + [ ## Fase 2: associare l’istanza database a un gruppo di parametri di database con i parametri di replica di gruppo richiesti impostati ](#mysql-active-active-clusters-converting-associate-parameter-group) + [ ## Fase 3: creare il cluster attivo-attivo ](#mysql-active-active-clusters-converting-associate-parameter-groups) + [ ## Fase 4: creare istanze database RDS per MySQL per il cluster attivo-attivo ](#mysql-active-active-clusters-converting-add-db-instances) + [ ## Fare 5: inizializzare il gruppo sull’istanza database in fase di conversione ](#mysql-active-active-clusters-converting-start-replication-first) + [ ## Fase 6: avviare la replica sulle altre istanze database nel cluster attivo-attivo ](#mysql-active-active-clusters-converting-start-replication-other) + [ ## Fase 7 (consigliata): verificare lo stato del cluster attivo-attivo ](#mysql-active-active-clusters-converting-view) ## Fase 1: impostare i parametri del cluster attivo-attivo in uno o più gruppi di parametri personalizzati Le istanze database RDS per MySQL in un cluster attivo-attivo devono essere associate a un gruppo di parametri personalizzato con l’impostazione corretta per i parametri richiesti. Per ulteriori informazioni sui parametri e la relativa impostazione per ciascuno, consulta [Impostazioni dei parametri richieste per i cluster attivi-attivi](mysql-active-active-clusters-parameters.md). È possibile impostare i parametri in nuovi gruppi di parametri o in gruppi di parametri esistenti. Tuttavia, per evitare di influire accidentalmente sulle istanze database che non fanno parte del cluster attivo-attivo, si consiglia di creare un nuovo gruppo di parametri personalizzato. Le istanze database di un cluster attivo-attivo possono essere associate allo stesso gruppo di parametri di database oppure a gruppi di parametri di database diversi. È possibile utilizzare Console di gestione AWS o il AWS CLI per creare un nuovo gruppo di parametri personalizzato. Per ulteriori informazioni, consulta [Creazione di un gruppo di parametri database in Amazon RDS](USER_WorkingWithParamGroups.Creating.md). L'esempio seguente esegue il [create-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-parameter-group.html) AWS CLI comando per creare un gruppo di parametri DB personalizzato denominato RDS `myactivepg` for MySQL 8.0: Per Linux, macOS o Unix: ``` aws rds create-db-parameter-group \ --db-parameter-group-name myactivepg \ --db-parameter-group-family mysql8.0 \ --description "Parameter group for active-active clusters" ``` Per Windows: ``` aws rds create-db-parameter-group ^ --db-parameter-group-name myactivepg ^ --db-parameter-group-family mysql8.0 ^ --description "Parameter group for active-active clusters" ``` È inoltre possibile utilizzare Console di gestione AWS o the AWS CLI per impostare i parametri nel gruppo di parametri personalizzato. Per ulteriori informazioni, consulta [Modifica dei parametri in un gruppo di parametri database in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). L'esempio seguente esegue il [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) AWS CLI comando per impostare i parametri per RDS for MySQL 8.0. Per utilizzare questo esempio con RDS per MySQL 8.4, modificare `slave_preserve_commit_order` in `replica_preserve_commit_order`. Per Linux, macOS o Unix: ``` aws rds modify-db-parameter-group \ --db-parameter-group-name myactivepg \ --parameters "ParameterName='rds.group_replication_enabled',ParameterValue='1',ApplyMethod=pending-reboot" \ "ParameterName='rds.custom_dns_resolution',ParameterValue='1',ApplyMethod=pending-reboot" \ "ParameterName='enforce_gtid_consistency',ParameterValue='ON',ApplyMethod=pending-reboot" \ "ParameterName='gtid-mode',ParameterValue='ON',ApplyMethod=pending-reboot" \ "ParameterName='binlog_format',ParameterValue='ROW',ApplyMethod=immediate" \ "ParameterName='slave_preserve_commit_order',ParameterValue='ON',ApplyMethod=immediate" \ "ParameterName='group_replication_group_name',ParameterValue='11111111-2222-3333-4444-555555555555',ApplyMethod=pending-reboot" ``` Per Windows: ``` aws rds modify-db-parameter-group ^ --db-parameter-group-name myactivepg ^ --parameters "ParameterName='rds.group_replication_enabled',ParameterValue='1',ApplyMethod=pending-reboot" ^ "ParameterName='rds.custom_dns_resolution',ParameterValue='1',ApplyMethod=pending-reboot" ^ "ParameterName='enforce_gtid_consistency',ParameterValue='ON',ApplyMethod=pending-reboot" ^ "ParameterName='gtid-mode',ParameterValue='ON',ApplyMethod=pending-reboot" ^ "ParameterName='binlog_format',ParameterValue='ROW',ApplyMethod=immediate" ^ "ParameterName='slave_preserve_commit_order',ParameterValue='ON',ApplyMethod=immediate" ^ "ParameterName='group_replication_group_name',ParameterValue='11111111-2222-3333-4444-555555555555',ApplyMethod=pending-reboot" ``` ## Fase 2: associare l’istanza database a un gruppo di parametri di database con i parametri di replica di gruppo richiesti impostati Associa l’istanza database a un gruppo di parametri di database creato o modificato nella fase precedente. Per istruzioni, consulta [Associazione di un gruppo di parametri database a un’istanza database in Amazon RDS](USER_WorkingWithParamGroups.Associating.md). Affinché le nuove impostazioni del parametro abbiano effetto, riavvia l’istanza database. Per istruzioni, consulta [Riavvio di un'istanza DB DB](USER_RebootInstance.md). ## Fase 3: creare il cluster attivo-attivo Nel gruppo di parametri di database associato a ciascuna istanza database, imposta il parametro `group_replication_group_seeds` sull’endpoint delle istanze database in fase di conversione. È possibile utilizzare Console di gestione AWS o the per impostare il parametro AWS CLI . Dopo aver impostato il parametro, non è necessario riavviare l’istanza database. Per informazioni sull’impostazione dei parametri, consulta [Modifica dei parametri in un gruppo di parametri database in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). L'esempio seguente esegue il [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) AWS CLI comando per impostare i parametri: Per Linux, macOS o Unix: ``` aws rds modify-db-parameter-group \ --db-parameter-group-name myactivepg \ --parameters "ParameterName='group_replication_group_seeds',ParameterValue='myactivedb1.123456789012.us-east-1.rds.amazonaws.com:3306',ApplyMethod=immediate" ``` Per Windows: ``` aws rds modify-db-parameter-group ^ --db-parameter-group-name myactivepg ^ --parameters "ParameterName='group_replication_group_seeds',ParameterValue='myactivedb1.123456789012.us-east-1.rds.amazonaws.com:3306',ApplyMethod=immediate" ``` ## Fase 4: creare istanze database RDS per MySQL per il cluster attivo-attivo Per creare istanze DB aggiuntive per il cluster active-active, esegui il point-in-time ripristino sull'istanza DB che stai convertendo. Per istruzioni, consulta [Aggiunta di un’istanza database a un cluster attivo-attivo tramite il recupero point-in-time](mysql-active-active-clusters-adding.md#mysql-active-active-clusters-adding-pitr). Nei cluster attivi-attivi possono essere presenti fino a nove istanze database. Esegui il point-in-time ripristino sull'istanza DB fino a ottenere il numero di istanze DB che desideri per il cluster. Quando esegui point-in-recovery, assicurati di associare l'istanza DB che stai aggiungendo a un gruppo di parametri DB `rds.group_replication_enabled` impostato `1` su. In caso contrario, la replica di gruppo non verrà avviata sull’istanza database aggiunta. ## Fare 5: inizializzare il gruppo sull’istanza database in fase di conversione Inizializza il gruppo e avvia la replica: 1. Connettiti all’istanza database in fase di conversione in un client SQL. Per ulteriori informazioni sulla connessione a un’istanza database RDS per MySQL, consulta [Connessione all’istanza database MySQL](USER_ConnectToInstance.md). 1. Nel client SQL, esegui le seguenti stored procedure e *group\$1replication\$1user\$1password* sostituiscile con la password dell'`rdsgrprepladmin`utente. In un cluster attivo-attivo, l’utente `rdsgrprepladmin` è riservato alle connessioni di replica di gruppo. La password di tale utente deve essere la stessa su tutte le istanze database di un cluster attivo-attivo. ``` call mysql.rds_set_configuration('binlog retention hours', 168); -- 7 days binlog call mysql.rds_group_replication_create_user('group_replication_user_password'); call mysql.rds_group_replication_set_recovery_channel('group_replication_user_password'); call mysql.rds_group_replication_start(1); ``` Questo esempio imposta il valore `binlog retention hours` su `168` in modo che i file di log binari vengano mantenuti per sette giorni nell’istanza database. È possibile modificare questo valore per soddisfare i requisiti specifici. Questo esempio specifica `1` nella stored procedure `mysql.rds_group_replication_start` per inizializzare un nuovo gruppo con l’istanza database corrente. Per ulteriori informazioni sulle stored procedure chiamate nell’esempio, consulta [Gestione di cluster attivi-attivi](mysql-stored-proc-active-active-clusters.md). ## Fase 6: avviare la replica sulle altre istanze database nel cluster attivo-attivo Per ciascuna istanza database del cluster attivo-attivo, utilizza un client SQL per connetterti all’istanza ed esegui queste stored procedure. Sostituire *group\$1replication\$1user\$1password* con la password dell'`rdsgrprepladmin`utente. ``` call mysql.rds_set_configuration('binlog retention hours', 168); -- 7 days binlog call mysql.rds_group_replication_create_user('group_replication_user_password'); call mysql.rds_group_replication_set_recovery_channel('group_replication_user_password'); call mysql.rds_group_replication_start(0); ``` Questo esempio imposta il valore `binlog retention hours` su `168` in modo che i file di log binari vengano mantenuti per sette giorni in ciascuna istanza database. È possibile modificare questo valore per soddisfare i requisiti specifici. L’esempio specifica `0` nella stored procedure `mysql.rds_group_replication_start` per unire l’istanza database corrente a un gruppo esistente. **Suggerimento** Assicurati di eseguire queste stored procedure su tutte le altre istanze database del cluster attivo-attivo. ## Fase 7 (consigliata): verificare lo stato del cluster attivo-attivo Per verificare che ogni membro del cluster sia configurato correttamente, connettiti a un’istanza database del cluster attivo-attivo ed esegui questo comando SQL per controllare lo stato del cluster: ``` SELECT * FROM performance_schema.replication_group_members; ``` L’output deve essere `ONLINE` per l’elemento `MEMBER_STATE` di ogni istanza database, come nell’output di esempio seguente: ``` +---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+ | CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK | +---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+ | group_replication_applier | 9854d4a2-5d7f-11ee-b8ec-0ec88c43c251 | ip-10-15-3-137 | 3306 | ONLINE | PRIMARY | 8.0.35 | MySQL | | group_replication_applier | 9e2e9c28-5d7f-11ee-8039-0e5d58f05fef | ip-10-15-3-225 | 3306 | ONLINE | PRIMARY | 8.0.35 | MySQL | | group_replication_applier | a6ba332d-5d7f-11ee-a025-0a5c6971197d | ip-10-15-1-83 | 3306 | ONLINE | PRIMARY | 8.0.35 | MySQL | +---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+ 3 rows in set (0.00 sec) ``` Per informazioni sui possibili valori `MEMBER_STATE`, consulta [Group Replication Server States](https://dev.mysql.com/doc/refman/8.0/en/group-replication-server-states.html) nella documentazione MySQL. # Configurazione di un cluster attivo-attivo con nuove istanze database Per configurare un cluster attivo-attivo utilizzando nuove istanze database di Amazon RDS per MySQL, esegui queste operazioni. Se configuri un cluster attivo-attivo con istanze database in più di un cloud privato virtuale, verifica che i prerequisiti in [Preparazione per un cluster attivo-attivo tra VPC](mysql-active-active-clusters-cross-vpc-prerequisites.md) siano soddisfatti. **Topics** + [ ## Fase 1: impostare i parametri del cluster attivo-attivo in uno o più gruppi di parametri personalizzati ](#mysql-active-active-clusters-setting-up-parameter-group) + [ ## Fase 2: creare nuove istanze database RDS per MySQL per il cluster attivo-attivo ](#mysql-active-active-clusters-setting-up-db-instances) + [ ## Fase 3: specificare le istanze database nel cluster attivo-attivo ](#mysql-active-active-clusters-setting-up-associate-parameter-groups) + [ ## Fase 4: inizializzare il gruppo su un’istanza database e avviare la replica ](#mysql-active-active-clusters-setting-up-start-replication-first) + [ ## Fase 5: avviare la replica sulle altre istanze database nel cluster attivo-attivo ](#mysql-active-active-clusters-setting-up-start-replication-other) + [ ## Fase 6 (consigliata): verificare lo stato del cluster attivo-attivo ](#mysql-active-active-clusters-setting-up-view) + [ ## Fase 7 (facoltativa): importare i dati in un’istanza database del cluster attivo-attivo ](#mysql-active-active-clusters-import) ## Fase 1: impostare i parametri del cluster attivo-attivo in uno o più gruppi di parametri personalizzati Le istanze database RDS per MySQL in un cluster attivo-attivo devono essere associate a un gruppo di parametri personalizzato con l’impostazione corretta per i parametri richiesti. Per ulteriori informazioni sui parametri e la relativa impostazione per ciascuno, consulta [Impostazioni dei parametri richieste per i cluster attivi-attivi](mysql-active-active-clusters-parameters.md). È possibile impostare i parametri in nuovi gruppi di parametri o in gruppi di parametri esistenti. Tuttavia, per evitare di influire accidentalmente sulle istanze database che non fanno parte del cluster attivo-attivo, si consiglia di creare un nuovo gruppo di parametri personalizzato. Le istanze database di un cluster attivo-attivo possono essere associate allo stesso gruppo di parametri di database oppure a gruppi di parametri di database diversi. È possibile utilizzare Console di gestione AWS o il AWS CLI per creare un nuovo gruppo di parametri personalizzato. Per ulteriori informazioni, consulta [Creazione di un gruppo di parametri database in Amazon RDS](USER_WorkingWithParamGroups.Creating.md). L'esempio seguente esegue il [create-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-parameter-group.html) AWS CLI comando per creare un gruppo di parametri DB personalizzato denominato RDS `myactivepg` for MySQL 8.0: Per Linux, macOS o Unix: ``` aws rds create-db-parameter-group \ --db-parameter-group-name myactivepg \ --db-parameter-group-family mysql8.0 \ --description "Parameter group for active-active clusters" ``` Per Windows: ``` aws rds create-db-parameter-group ^ --db-parameter-group-name myactivepg ^ --db-parameter-group-family mysql8.0 ^ --description "Parameter group for active-active clusters" ``` È inoltre possibile utilizzare Console di gestione AWS o the AWS CLI per impostare i parametri nel gruppo di parametri personalizzato. Per ulteriori informazioni, consulta [Modifica dei parametri in un gruppo di parametri database in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). L'esempio seguente esegue il [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) AWS CLI comando per impostare i parametri per RDS for MySQL 8.0. Per utilizzare questo esempio con RDS per MySQL 8.4, modificare `slave_preserve_commit_order` in `replica_preserve_commit_order`. Per Linux, macOS o Unix: ``` aws rds modify-db-parameter-group \ --db-parameter-group-name myactivepg \ --parameters "ParameterName='rds.group_replication_enabled',ParameterValue='1',ApplyMethod=pending-reboot" \ "ParameterName='rds.custom_dns_resolution',ParameterValue='1',ApplyMethod=pending-reboot" \ "ParameterName='enforce_gtid_consistency',ParameterValue='ON',ApplyMethod=pending-reboot" \ "ParameterName='gtid-mode',ParameterValue='ON',ApplyMethod=pending-reboot" \ "ParameterName='binlog_format',ParameterValue='ROW',ApplyMethod=immediate" \ "ParameterName='slave_preserve_commit_order',ParameterValue='ON',ApplyMethod=immediate" \ "ParameterName='group_replication_group_name',ParameterValue='11111111-2222-3333-4444-555555555555',ApplyMethod=pending-reboot" ``` Per Windows: ``` aws rds modify-db-parameter-group ^ --db-parameter-group-name myactivepg ^ --parameters "ParameterName='rds.group_replication_enabled',ParameterValue='1',ApplyMethod=pending-reboot" ^ "ParameterName='rds.custom_dns_resolution',ParameterValue='1',ApplyMethod=pending-reboot" ^ "ParameterName='enforce_gtid_consistency',ParameterValue='ON',ApplyMethod=pending-reboot" ^ "ParameterName='gtid-mode',ParameterValue='ON',ApplyMethod=pending-reboot" ^ "ParameterName='binlog_format',ParameterValue='ROW',ApplyMethod=immediate" ^ "ParameterName='slave_preserve_commit_order',ParameterValue='ON',ApplyMethod=immediate" ^ "ParameterName='group_replication_group_name',ParameterValue='11111111-2222-3333-4444-555555555555',ApplyMethod=pending-reboot" ``` ## Fase 2: creare nuove istanze database RDS per MySQL per il cluster attivo-attivo I cluster attivi-attivi sono supportati per le seguenti versioni delle istanze database RDS per MySQL: + Tutte le versioni di MySQL 8.4 + MySQL versione 8.0.35 e versioni secondarie successive È possibile creare fino a nove nuove istanze database per il cluster. È possibile utilizzare Console di gestione AWS o the AWS CLI per creare nuove istanze DB. Per ulteriori informazioni sulla creazione di un'istanza database, consulta [Creazione di un'istanza database Amazon RDS](USER_CreateDBInstance.md). Quando crei l’istanza database, associala a un gruppo di parametri di database creato o modificato nella fase precedente. ## Fase 3: specificare le istanze database nel cluster attivo-attivo Nel gruppo di parametri di database associato a ciascuna istanza database, imposta il parametro `group_replication_group_seeds` sugli endpoint delle istanze database da includere nel cluster. È possibile utilizzare Console di gestione AWS o the AWS CLI per impostare il parametro. Dopo aver impostato il parametro, non è necessario riavviare l’istanza database. Per informazioni sull’impostazione dei parametri, consulta [Modifica dei parametri in un gruppo di parametri database in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). L'esempio seguente esegue il [modify-db-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-parameter-group.html) AWS CLI comando per impostare i parametri: Per Linux, macOS o Unix: ``` aws rds modify-db-parameter-group \ --db-parameter-group-name myactivepg \ --parameters "ParameterName='group_replication_group_seeds',ParameterValue='myactivedb1.123456789012.us-east-1.rds.amazonaws.com:3306,myactivedb2.123456789012.us-east-1.rds.amazonaws.com:3306,myactivedb3.123456789012.us-east-1.rds.amazonaws.com:3306',ApplyMethod=immediate" ``` Per Windows: ``` aws rds modify-db-parameter-group ^ --db-parameter-group-name myactivepg ^ --parameters "ParameterName='group_replication_group_seeds',ParameterValue='myactivedb1.123456789012.us-east-1.rds.amazonaws.com:3306,myactivedb2.123456789012.us-east-1.rds.amazonaws.com:3306,myactivedb3.123456789012.us-east-1.rds.amazonaws.com:3306',ApplyMethod=immediate" ``` **Suggerimento** Assicurati di impostare il parametro `group_replication_group_seeds` in ogni gruppo di parametri di database associato a un’istanza database nel cluster attivo-attivo. ## Fase 4: inizializzare il gruppo su un’istanza database e avviare la replica È possibile scegliere qualsiasi nuovo database per inizializzare il gruppo e avviare la replica. Per fare ciò, completa la seguente procedura: 1. Scegli un’istanza database nel cluster attivo-attivo e connettiti a tale istanza utilizzando un client SQL. Per ulteriori informazioni sulla connessione a un’istanza database RDS per MySQL, consulta [Connessione all’istanza database MySQL](USER_ConnectToInstance.md). 1. Nel client SQL, esegui le seguenti stored procedure e *group\$1replication\$1user\$1password* sostituiscile con la password dell'`rdsgrprepladmin`utente. In un cluster attivo-attivo, l’utente `rdsgrprepladmin` è riservato alle connessioni di replica di gruppo. La password di tale utente deve essere la stessa su tutte le istanze database di un cluster attivo-attivo. ``` call mysql.rds_set_configuration('binlog retention hours', 168); -- 7 days binlog call mysql.rds_group_replication_create_user('group_replication_user_password'); call mysql.rds_group_replication_set_recovery_channel('group_replication_user_password'); call mysql.rds_group_replication_start(1); ``` Questo esempio imposta il valore `binlog retention hours` su `168` in modo che i file di log binari vengano mantenuti per sette giorni nell’istanza database. È possibile modificare questo valore per soddisfare i requisiti specifici. Questo esempio specifica `1` nella stored procedure `mysql.rds_group_replication_start` per inizializzare un nuovo gruppo con l’istanza database corrente. Per ulteriori informazioni sulle stored procedure chiamate nell’esempio, consulta [Gestione di cluster attivi-attivi](mysql-stored-proc-active-active-clusters.md). ## Fase 5: avviare la replica sulle altre istanze database nel cluster attivo-attivo Per ciascuna istanza database del cluster attivo-attivo, utilizza un client SQL per connetterti all’istanza ed esegui queste stored procedure. Sostituire *group\$1replication\$1user\$1password* con la password dell'`rdsgrprepladmin`utente. ``` call mysql.rds_set_configuration('binlog retention hours', 168); -- 7 days binlog call mysql.rds_group_replication_create_user('group_replication_user_password'); call mysql.rds_group_replication_set_recovery_channel('group_replication_user_password'); call mysql.rds_group_replication_start(0); ``` Questo esempio imposta il valore `binlog retention hours` su `168` in modo che i file di log binari vengano mantenuti per sette giorni in ciascuna istanza database. È possibile modificare questo valore per soddisfare i requisiti specifici. L’esempio specifica `0` nella stored procedure `mysql.rds_group_replication_start` per unire l’istanza database corrente a un gruppo esistente. **Suggerimento** Assicurati di eseguire queste stored procedure su tutte le altre istanze database del cluster attivo-attivo. ## Fase 6 (consigliata): verificare lo stato del cluster attivo-attivo Per verificare che ogni membro del cluster sia configurato correttamente, connettiti a un’istanza database del cluster attivo-attivo ed esegui questo comando SQL per controllare lo stato del cluster: ``` SELECT * FROM performance_schema.replication_group_members; ``` L’output deve essere `ONLINE` per l’elemento `MEMBER_STATE` di ogni istanza database, come nell’output di esempio seguente: ``` +---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+ | CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK | +---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+ | group_replication_applier | 9854d4a2-5d7f-11ee-b8ec-0ec88c43c251 | ip-10-15-3-137 | 3306 | ONLINE | PRIMARY | 8.0.35 | MySQL | | group_replication_applier | 9e2e9c28-5d7f-11ee-8039-0e5d58f05fef | ip-10-15-3-225 | 3306 | ONLINE | PRIMARY | 8.0.35 | MySQL | | group_replication_applier | a6ba332d-5d7f-11ee-a025-0a5c6971197d | ip-10-15-1-83 | 3306 | ONLINE | PRIMARY | 8.0.35 | MySQL | +---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+ 3 rows in set (0.00 sec) ``` Per informazioni sui possibili valori `MEMBER_STATE`, consulta [Group Replication Server States](https://dev.mysql.com/doc/refman/8.0/en/group-replication-server-states.html) nella documentazione MySQL. ## Fase 7 (facoltativa): importare i dati in un’istanza database del cluster attivo-attivo È possibile importare dati da un database MySQL in un’istanza database nel cluster attivo-attivo. Dopo l’importazione, la replica di gruppo replica i dati nelle altre istanze database del cluster. Per informazioni sull’importazione di dati, consulta [Importazione dei dati in un database Amazon RDS per MySQL con tempo di inattività ridotto](mysql-importing-data-reduced-downtime.md). # Aggiunta di un’istanza database a un cluster attivo-attivo È possibile aggiungere un’istanza database a un cluster attivo-attivo Amazon RDS per MySQL ripristinando uno snapshot di database o un’istanza database in un determinato momento. Nei cluster attivi-attivi possono essere presenti fino a nove istanze database. Quando si ripristina un’istanza database in un determinato momento, in genere vengono incluse transazioni più recenti rispetto a quelle di un’istanza database ripristinata da uno snapshot di database. Se nell’istanza database sono presenti transazioni più recenti, è necessario applicare un numero inferiore di transazioni all’avvio della replica. Di conseguenza, il recupero point-in-time per aggiungere un’istanza database a un cluster è in genere più rapido rispetto al ripristino da uno snapshot di database. **Topics** + [ ## Aggiunta di un’istanza database a un cluster attivo-attivo tramite il recupero point-in-time ](#mysql-active-active-clusters-adding-pitr) + [ ## Aggiunta di un’istanza database a un cluster attivo-attivo tramite uno snapshot di database ](#mysql-active-active-clusters-adding-snapshot) ## Aggiunta di un’istanza database a un cluster attivo-attivo tramite il recupero point-in-time Per aggiungere un’istanza database aggiuntiva per il cluster attivo-attivo, esegui il recupero point-in-time sull’istanza database nel cluster. Per informazioni sul recupero di un’istanza database in un determinato momento in una Regione AWS diversa, consulta [Replica dei backup automatici su un altro Regione AWS](USER_ReplicateBackups.md). **Per aggiungere un’istanza database a un cluster attivo-attivo tramite il recupero point-in-time** 1. Crea una nuova istanza database eseguendo il recupero point-in-time sull’istanza database nel cluster attivo-attivo. È possibile eseguire il recupero point-in-time su qualsiasi istanza database nel cluster per creare la nuova istanza database. Per istruzioni, consultare [Ripristino di un’istanza database a un punto temporale specifico per Amazon RDS](USER_PIT.md). **Importante** Durante il recupero point-in-time, associa la nuova istanza database a un gruppo di parametri di database con i parametri del cluster attivo-attivo impostati. In caso contrario, la replica di gruppo non verrà avviata sulla nuova istanza database. Per ulteriori informazioni sui parametri e la relativa impostazione per ciascuno, consulta [Impostazioni dei parametri richieste per i cluster attivi-attivi](mysql-active-active-clusters-parameters.md). **Suggerimento** Se si acquisisce uno snapshot dell’istanza database prima di avviare il recupero point-in-time, è possibile ridurre il tempo necessario per applicare le transazioni alla nuova istanza database. 1. Aggiungi l’istanza database al parametro `group_replication_group_seeds` in ogni gruppo di parametri di database associato a un’istanza database nel cluster attivo-attivo, incluso il gruppo di parametri di database associato alla nuova istanza database. Per informazioni sull'estensione dei parametri consulta [Modifica dei parametri in un gruppo di parametri database in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). 1. In un client SQL, connettiti alla nuova istanza database e chiama la stored procedure [mysql.rds\$1group\$1replication\$1set\$1recovery\$1channel](mysql-stored-proc-active-active-clusters.md#mysql_rds_group_replication_set_recovery_channel). Sostituisci *group\$1replication\$1user\$1password* con la password per l’utente `rdsgrprepladmin`. ``` call mysql.rds_group_replication_set_recovery_channel('group_replication_user_password'); ``` 1. Utilizzando il client SQL, chiama la stored procedure [mysql.rds\$1group\$1replication\$1start](mysql-stored-proc-active-active-clusters.md#mysql_rds_group_replication_start) per avviare la replica: ``` call mysql.rds_group_replication_start(0); ``` ## Aggiunta di un’istanza database a un cluster attivo-attivo tramite uno snapshot di database È possibile aggiungere un’istanza database a un cluster attivo-attivo creando uno snapshot di database di un’istanza database nel cluster e quindi ripristinando lo snapshot di database. Per ulteriori informazioni sulla copia di uno snapshot in una Regione AWS diversa, consulta [Considerazioni sulla copia di snapshot tra Regioni](USER_CopySnapshot.md#USER_CopySnapshot.AcrossRegions). **Per aggiungere un’istanza database a un cluster attivo-attivo tramite uno snapshot di database** 1. Crea uno snapshot di database di un’istanza database nel cluster attivo-attivo. Per creare uno snapshot di database di qualsiasi istanza database del cluster. Per istruzioni, consultare [Creazione di uno snapshot del database per un’istanza database Single-AZ per Amazon RDS](USER_CreateSnapshot.md). 1. Ripristina un’istanza database dallo snapshot di database. Durante il ripristino point-in-time, associa la nuova istanza database a un gruppo di parametri di database con i parametri del cluster attivo-attivo impostati. Per ulteriori informazioni sui parametri e la relativa impostazione per ciascuno, consulta [Impostazioni dei parametri richieste per i cluster attivi-attivi](mysql-active-active-clusters-parameters.md). Per informazioni sul ripristino di un’istanza database da uno snapshot di database, consulta [Ripristino in un’istanza database](USER_RestoreFromSnapshot.md). 1. Aggiungi l’istanza database al parametro `group_replication_group_seeds` in ogni gruppo di parametri di database associato a un’istanza database nel cluster attivo-attivo, incluso il gruppo di parametri di database associato alla nuova istanza database. Per informazioni sull'estensione dei parametri consulta [Modifica dei parametri in un gruppo di parametri database in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). 1. In un client SQL, connettiti alla nuova istanza database e chiama la stored procedure [mysql.rds\$1group\$1replication\$1set\$1recovery\$1channel](mysql-stored-proc-active-active-clusters.md#mysql_rds_group_replication_set_recovery_channel). Sostituisci *group\$1replication\$1user\$1password* con la password per l’utente `rdsgrprepladmin`. ``` call mysql.rds_group_replication_set_recovery_channel('group_replication_user_password'); ``` 1. Utilizzando il client SQL, chiama la stored procedure [mysql.rds\$1group\$1replication\$1start](mysql-stored-proc-active-active-clusters.md#mysql_rds_group_replication_start) per avviare la replica: ``` call mysql.rds_group_replication_start(0); ``` # Monitoraggio dei cluster attivi-attivi In Amazon RDS per MySQL, il monitoraggio dei cluster attivi-attivi è fondamentale per tenere traccia delle prestazioni, dell’integrità della replica e della sincronizzazione dei nodi. Per monitorare il cluster attivo-attivo, connettiti a un’istanza database nel cluster ed esegui questo comando SQL: ``` SELECT * FROM performance_schema.replication_group_members; ``` L’output deve essere `ONLINE` per l’elemento `MEMBER_STATE` di ogni istanza database, come nell’output di esempio seguente: ``` +---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+ | CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK | +---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+ | group_replication_applier | 9854d4a2-5d7f-11ee-b8ec-0ec88c43c251 | ip-10-15-3-137 | 3306 | ONLINE | PRIMARY | 8.0.35 | MySQL | | group_replication_applier | 9e2e9c28-5d7f-11ee-8039-0e5d58f05fef | ip-10-15-3-225 | 3306 | ONLINE | PRIMARY | 8.0.35 | MySQL | | group_replication_applier | a6ba332d-5d7f-11ee-a025-0a5c6971197d | ip-10-15-1-83 | 3306 | ONLINE | PRIMARY | 8.0.35 | MySQL | +---------------------------+--------------------------------------+----------------+-------------+--------------+-------------+----------------+----------------------------+ 3 rows in set (0.00 sec) ``` Per informazioni sui possibili valori `MEMBER_STATE`, consulta [Group Replication Server States](https://dev.mysql.com/doc/refman/8.0/en/group-replication-server-states.html) nella documentazione MySQL. # Arresto della replica di gruppo in un’istanza database in un cluster attivo-attivo È possibile arrestare la replica di gruppo in un’istanza database in un cluster attivo-attivo. Quando si interrompe la replica di gruppo, l'istanza DB viene messa in super-read-only modalità fino al riavvio della replica o alla rimozione dell'istanza DB dal cluster active-active. Per informazioni sulla super-read-only modalità, consulta la documentazione di [MySQL](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_super_read_only). **Per arrestare temporaneamente la replica di gruppo in un cluster attivo-attivo** 1. Connettiti a un’istanza database nel cluster attivo-attivo utilizzando un client SQL. Per ulteriori informazioni sulla connessione a un’istanza database RDS per MySQL, consulta [Connessione all’istanza database MySQL](USER_ConnectToInstance.md). 1. Nel client SQL, chiama la stored procedure [mysql.rds\$1group\$1replication\$1stop](mysql-stored-proc-active-active-clusters.md#mysql_rds_group_replication_stop): ``` call mysql.rds_group_replication_stop(); ``` # Ridenominazione di un’istanza database in un cluster attivo-attivo È possibile modificare il nome di un’istanza database in un cluster attivo-attivo. Per rinominare più di un’istanza database in un cluster attivo-attivo, esegui un’istanza database alla volta. Rinomina quindi un’istanza database e uniscila nuovamente al cluster prima di rinominare l’istanza database successiva. **Per rinominare un’istanza database in un cluster attivo-attivo** 1. Connettiti all’istanza database in un client SQL e chiama la stored procedure [mysql.rds\$1group\$1replication\$1stop](mysql-stored-proc-active-active-clusters.md#mysql_rds_group_replication_stop): ``` call mysql.rds_group_replication_stop(); ``` 1. Segui le istruzioni in [Ridenominazione di un'istanza database](USER_RenameInstance.md) per rinominare l’istanza database. 1. Modifica il parametro `group_replication_group_seeds` in ogni gruppo di parametri di database associato a un’istanza database nel cluster attivo-attivo. Nell’impostazione dei parametri, sostituisci il vecchio endpoint dell’istanza database con quello nuovo. Per informazioni sull'estensione dei parametri consulta [Modifica dei parametri in un gruppo di parametri database in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). 1. Connettiti all’istanza database in un client SQL e chiama la stored procedure [mysql.rds\$1group\$1replication\$1start](mysql-stored-proc-active-active-clusters.md#mysql_rds_group_replication_start): ``` call mysql.rds_group_replication_start(0); ``` # Rimozione di un’istanza database da un cluster attivo-attivo Quando si rimuove un’istanza database da un cluster attivo-attivo, viene ripristinata un’istanza database autonoma. **Per rimuovere un’istanza database da un cluster attivo-attivo** 1. Connettiti all’istanza database in un client SQL e chiama la stored procedure [mysql.rds\$1group\$1replication\$1stop](mysql-stored-proc-active-active-clusters.md#mysql_rds_group_replication_stop): ``` call mysql.rds_group_replication_stop(); ``` 1. Modifica il `group_replication_group_seeds` parametro per le istanze database che rimangono nel cluster attivo-attivo. Nel parametro `group_replication_group_seeds`, elimina l’istanza database da rimuovere dal cluster attivo-attivo. Per informazioni sull’impostazione dei parametri, consulta [Modifica dei parametri in un gruppo di parametri database in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). 1. Modifica i parametri dell’istanza database da rimuovere dal cluster attivo-attivo in modo che non appartenga più al cluster. È possibile associare l’istanza database a un gruppo di parametri diverso o modificare i parametri del gruppo di parametri di database associato all’istanza database. I parametri da modificare includono `group_replication_group_name`, `rds.group_replication_enabled` e `group_replication_group_seeds`. Per ulteriori informazioni sui parametri di un cluster attivo-attivo, consulta [Impostazioni dei parametri richieste per i cluster attivi-attivi](mysql-active-active-clusters-parameters.md). Se modifichi i parametri in un gruppo di parametri di database, verifica che il gruppo di parametri di database non sia associato ad altre istanze database nel cluster attivo-attivo. 1. Affinché le nuove impostazioni del parametro abbiano effetto, riavvia l’istanza database rimossa dal cluster attivo-attivo. Per istruzioni, consulta [Riavvio di un'istanza DB DB](USER_RebootInstance.md). # Esportazione di dati da un'istanza database MySQL tramite la replica È possibile utilizzare la replica per esportare dati da un'istanza database MySQL a un'istanza di MySQL eseguita esternamente ad Amazon RDS. In questo scenario, l'istanza database MySQL è l'*istanza database MySQL di origine* e l’istanza MySQL in esecuzione esterna a Amazon RDS è il *database MySQL esterno*. Il database MySQL esterno può essere eseguito in locale nel data center o su un'istanza Amazon EC2. Il database MySQL esterno deve eseguire la stessa versione dell'istanza database MySQL di origine o una versione successiva. La replica in un database MySQL esterno è supportata solo durante il tempo necessario per esportare un database dall'istanza database MySQL di origine. La replica deve essere terminata dopo che i dati sono stati esportati e le applicazioni possono iniziare ad accedere all'istanza MySQL esterna. Nell'elenco seguente è indicata la procedura da eseguire. Ciascuna fase della procedura è descritta in modo dettagliato nelle sezioni successive. 1. Preparare un'istanza database MySQL esterna. 1. Preparare l'istanza database MySQL di origine per la replica. 1. Utilizzare l'utilità mysqldump per trasferire il database dall'istanza database MySQL di origine al database MySQL esterno. 1. Avviare la replica nel database MySQL esterno. 1. Al termine dell'esportazione, arrestare la replica. ## Preparare un database MySQL esterno Eseguire la procedura seguente per preparare il database MySQL esterno. **Per preparare il database MySQL esterno** 1. Installare il database MySQL esterno. 1. Connettiti al database MySQL esterno come utente master. Creare quindi gli utenti necessari per supportare gli amministratori, le applicazioni e i servizi che accedono al database. 1. Seguire le istruzioni nella documentazione MySQL per preparare il database MySQL esterno come replica. Per ulteriori informazioni, consulta [Setting the Replica Configuration](https://dev.mysql.com/doc/refman/8.0/en/replication-howto-slavebaseconfig.html) nella documentazione MySQL. 1. Configurare una regola di uscita per consentire al database MySQL esterno di funzionare come replica di lettura durante l'esportazione. La regola di uscita consente al database MySQL esterno di connettersi all'istanza database MySQL di origine durante la replica. Specificare una regola in uscita che consenta le connessioni TCP (Transmission Control Protocol) alla porta e all'indirizzo IP dell'istanza database MySQL di origine. Specificare le regole di uscita appropriate per l'ambiente in uso: + Se il database MySQL esterno è in esecuzione in un'istanza Amazon EC2 in un Virtual Private Cloud (VPC) basato sul servizio Amazon VPC, specificare le regole di uscita in un gruppo di sicurezza VPC. Per ulteriori informazioni, consulta [Controllo dell'accesso con i gruppi di sicurezza](Overview.RDSSecurityGroups.md). + Se il database MySQL esterno è installato in locale, specificare le regole di uscita in un firewall. 1. Se il database MySQL esterno è in esecuzione in un VPC, configurare le regole per le regole dell'elenco di controllo accessi VPC (ACL) oltre alla regola di uscita del gruppo di sicurezza: + Configurare una regola in ingresso della lista di controllo accessi che abiliti il traffico TCP verso le porte 1024–65535 dall'indirizzo IP dell'istanza database MySQL di origine. + Configurare una regola in uscita della lista di controllo accessi che abiliti il traffico TCP in uscita verso la porta e l'indirizzo IP dell'istanza database MySQL di origine. Per ulteriori informazioni sulla rete Amazon VPC ACLs, consulta [Network](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html) in ACLs Amazon *VPC* User Guide. 1. (Facoltativo) Si consiglia di impostare il parametro `max_allowed_packet` sulla dimensione massima per evitare errori di replica. Si consiglia questa impostazione. ## Preparare l'istanza database MySQL di origine Eseguire la procedura seguente per preparare l'istanza database MySQL di origine come origine di replica. **Per preparare l'istanza database MySQL di origine** 1. Assicurarsi che il computer client disponga di spazio su disco sufficiente per salvare i log binari durante la configurazione della replica. 1. Connettersi all’istanza database MySQL di origine e creare un account di replica seguendo le istruzioni in [Creating a User for Replication](http://dev.mysql.com/doc/refman/8.0/en/replication-howto-repuser.html) nella documentazione MySQL. 1. Configurare le regole di ingresso sul sistema che esegue l'istanza database MySQL di origine per consentire al database MySQL esterno di connettersi durante la replica. Specificare una regola di ingresso che abiliti connessioni TCP alla porta usata dall'istanza database MySQL di origine dall'indirizzo IP del database MySQL esterno. 1. Specificare le regole di uscita: + Se l'istanza database viene eseguita in un VPC, specificare le regole in ingresso in un gruppo di sicurezza VPC. Per ulteriori informazioni, consulta [Controllo dell'accesso con i gruppi di sicurezza](Overview.RDSSecurityGroups.md). 1. Se l'istanza database viene eseguita in un VPC, configurare le regole della lista di controllo accessi VPC oltre alla regola di ingresso del gruppo di sicurezza. + Configurare una regola di ingresso della lista di controllo accessi che abiliti le connessioni TCP alla porta utilizzata dall'istanza Amazon RDS dall'indirizzo IP del database MySQL esterno. + Configurare una regola di ingresso che abiliti le connessioni TCP dalle porte 1024–65535 all'indirizzo IP del database MySQL esterno. Per ulteriori informazioni sulla rete Amazon VPC ACLs, consulta [Rete ACLs](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html) nella Amazon *VPC* User Guide. 1. È necessario assicurarsi che la durata del periodo di retention dei backup impostata sia sufficiente a garantire che nessun log binario sia eliminato durante l'esportazione. Se eventuali log vengono eliminati prima che l'esportazione sia completata, dovrai riavviare la replica dall'inizio. Per ulteriori informazioni su come impostare il periodo di retention dei backup, consulta [Introduzione ai backup](USER_WorkingWithAutomatedBackups.md). 1. Utilizzare la stored procedure `mysql.rds_set_configuration` per impostare una durata del periodo di retention dei log binari sufficiente a garantire che i log primari non vengano eliminati durante l'esportazione. Per ulteriori informazioni, consulta [Accesso ai log binari MySQL](USER_LogAccess.MySQL.Binarylog.md). 1. Per garantire ulteriormente che i log binari dell'istanza database MySQL di origine non vengano eliminati, è necessario creare una replica di lettura Amazon RDS dall'istanza database MySQL di origine. Per ulteriori informazioni, consulta [Creazione di una replica di lettura](USER_ReadRepl.Create.md). 1. Dopo che la replica di lettura Amazon RDS è stata creata, chiamare la stored procedure `mysql.rds_stop_replication` per arrestare il processo di replica. L'istanza database MySQL di origine non elimina più i file di log binari, quindi questi sono disponibili per il processo di replica. 1. (Facoltativo) Impostare il parametro `max_allowed_packet` e il parametro `slave_max_allowed_packet` sulla dimensione massima per evitare errori di replica. La dimensione massima per entrambi i parametri è 1 GB. Si consiglia questa impostazione per entrambi i parametri. Per informazioni sull'estensione dei parametri consulta [Modifica dei parametri in un gruppo di parametri database in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). ## Copia del database Eseguire la procedura seguente per copiare il database. **Per copiare il database** 1. Connettersi alla replica di lettura RDS dell'istanza database MySQL di origine ed eseguire l'istruzione `SHOW REPLICA STATUS\G` MySQL. Prendere nota dei valori per i seguenti elementi: + `Master_Host` + `Master_Port` + `Master_Log_File` + `Exec_Master_Log_Pos` **Nota** Versioni precedenti di MySQL utilizzate `SHOW SLAVE STATUS` al posto di `SHOW REPLICA STATUS`. Se si utilizza una versione MySQL prima della 8.0.23, utilizzare `SHOW SLAVE STATUS`. 1. Usa l'utilità mysqldump per creare uno snapshot, che copia i dati da Amazon RDS al computer client locale. Assicurarsi che il computer client disponga di spazio sufficiente per contenere i file `mysqldump` dei database da replicare. Questo processo può richiedere diverse ore in caso di database di grandi dimensioni. Seguire le indicazioni in [Creating a Data Snapshot Using mysqldump](https://dev.mysql.com/doc/mysql-replication-excerpt/8.0/en/replication-howto-mysqldump.html) nella documentazione MySQL. Nell'esempio seguente viene eseguito `mysqldump` su un client e viene scritto il dump in un file. Per Linux, macOS o Unix: ``` mysqldump -h source_MySQL_DB_instance_endpoint \ -u user \ -ppassword \ --port=3306 \ --single-transaction \ --routines \ --triggers \ --databases database database2 > path/rds-dump.sql ``` Per Windows: ``` mysqldump -h source_MySQL_DB_instance_endpoint ^ -u user ^ -ppassword ^ --port=3306 ^ --single-transaction ^ --routines ^ --triggers ^ --databases database database2 > path\rds-dump.sql ``` È possibile caricare il file di backup nel database MySQL esterno. Per ulteriori informazioni, consulta [Reloading SQL-Format Backups](https://dev.mysql.com/doc/refman/8.0/en/reloading-sql-format-dumps.html) (Ricaricamento dei backup in formato SQL) nella documentazione di MySQL. Puoi eseguire un'altra utilità per caricare i dati nel database MySQL esterno. ## Completamento dell'esportazione Per completare l'esportazione, attenersi alla seguente procedura. **Per completare l'esportazione** 1. Utilizzare l'istruzione MySQL `CHANGE MASTER` per configurare il database MySQL esterno. Specificare l'ID e la password delle autorizzazioni `REPLICATION SLAVE` concesse all'utente. Specificare i valori di `Master_Host`, `Master_Port`, `Relay_Master_Log_File`e `Exec_Master_Log_Pos` ottenuti dall’istruzione `SHOW REPLICA STATUS\G` MySQL eseguita sulla replica di lettura RDS. Per ulteriori informazioni, consulta [CHANGE MASTER TO Statement](https://dev.mysql.com/doc/refman/8.0/en/change-master-to.html) nella documentazione MySQL. **Nota** Versioni precedenti di MySQL utilizzate `SHOW SLAVE STATUS` al posto di `SHOW REPLICA STATUS`. Se si utilizza una versione MySQL prima della 8.0.23, utilizzare `SHOW SLAVE STATUS`. 1. Utilizzare il comando `START REPLICA` MySQL per avviare la replica dall'istanza database MySQL di origine al database MySQL esterno. In questo modo viene avviata la replica dall'istanza database MySQL di origine e vengono esportate tutte le modifiche di origine che si sono verificate dopo aver interrotto la replica dalla replica di lettura Amazon RDS. **Nota** Versioni precedenti di MySQL utilizzate `START SLAVE` al posto di `START REPLICA`. Se si utilizza una versione MySQL prima della 8.0.23, utilizzare `START SLAVE`. 1. Eseguire il comando `SHOW REPLICA STATUS\G` MySQL sul database MySQL esterno per verificare che funzioni come replica di lettura. Per ulteriori informazioni, consulta [SHOW SLAVE \$1 REPLICA STATUS Statement](https://dev.mysql.com/doc/refman/8.0/en/show-slave-status.html) nella documentazione MySQL. 1. Dopo che la replica sul database MySQL esterno ha raggiunto l'istanza database MySQL di origine, utilizzare il comando `STOP REPLICA` MySQL per interrompere la replica dall'istanza database MySQL di origine. **Nota** Versioni precedenti di MySQL utilizzate `STOP SLAVE` al posto di `STOP REPLICA`. Se si utilizza una versione MySQL prima della 8.0.23, utilizzare `STOP SLAVE`. 1. Nella replica di lettura Amazon RDS, chiamare la stored procedure `mysql.rds_start_replication`. In questo modo Amazon RDS inizierà a eliminare i file di log binari dall'istanza database MySQL di origine. # Opzioni per le istanze database MySQL Vengono descritte anche le opzioni o le funzionalità aggiuntive disponibili per le istanze di Amazon RDS che eseguono il motore di database MySQL. Per abilitare queste opzioni, puoi aggiungerle a un gruppo di opzioni personalizzato e quindi associare il gruppo di opzioni all'istanza database. Per ulteriori informazioni sull'utilizzo di gruppi di opzioni, consulta [Uso di gruppi di opzioni](USER_WorkingWithOptionGroups.md). Amazon RDS supporta le seguenti opzioni per MySQL: **** | Opzione | ID opzione | Versioni del motore | | --- | --- | --- | | [Supporto per MySQL del plug-in per audit MariaDB](Appendix.MySQL.Options.AuditPlugin.md) | `MARIADB_AUDIT_PLUGIN` | Tutte le versioni di MySQL 8.4MySQL 8.0.28 e versioni successive alla 8.0Tutte le versioni di MySQL 5.7 | | [Supporto per memcached MySQL](Appendix.MySQL.Options.memcached.md) | `MEMCACHED` | Tutte le versioni di MySQL 5.7 e 8.0 | # Supporto per MySQL del plug-in per audit MariaDB Amazon RDS offre un plug-in per audit per le istanze database MySQL basate sul plug-in per audit MariaDB open source. Per ulteriori informazioni, consulta il repository [Audit Plugin for MySQL Server GitHub](https://github.com/aws/audit-plugin-for-mysql). **Nota** Il plugin per audit per MySQL è basato sul plugin per audit MariaDB. In questo articolo, lo chiamiamo plugin per audit MariaDB. Il plug-in per audit MariaDB registra le attività del database, inclusi gli utenti che accedono al database e le query eseguite sul database. Il record con le attività del database è archiviato in un file di log. ## Impostazioni dell'opzione relativa al plug-in per audit Amazon RDS supporta le seguenti impostazioni per l'opzione relativa al plug-in per audit MariaDB. | Impostazione opzioni | Valori validi | Valore predefinito | Descrizione | | --- | --- | --- | --- | | `SERVER_AUDIT_FILE_PATH` | `/rdsdbdata/log/audit/` | `/rdsdbdata/log/audit/` | La posizione del file di log. Il file di log contiene il record dell'attività specificata in `SERVER_AUDIT_EVENTS`. Per ulteriori informazioni, consulta [Visualizzazione ed elenco dei file di log del database](USER_LogAccess.Procedural.Viewing.md) e [File di registro del database ](USER_LogAccess.Concepts.MySQL.md). | | `SERVER_AUDIT_FILE_ROTATE_SIZE` | 1–1000000000 | 1000000 | La dimensione in byte che, una volta raggiunta, provoca la rotazione del file. Per ulteriori informazioni, consulta [Panoramica dei registri di database RDS per MySQL](USER_LogAccess.MySQL.LogFileSize.md). | | `SERVER_AUDIT_FILE_ROTATIONS` | 0–100 | 9 | Il numero di rotazioni dei log da salvare se `server_audit_output_type=file`. Se impostata su 0, la rotazione del file di log non viene mai eseguita. Per ulteriori informazioni, consultare [Panoramica dei registri di database RDS per MySQL](USER_LogAccess.MySQL.LogFileSize.md) e [Download di un file di log di database](USER_LogAccess.Procedural.Downloading.md). | | `SERVER_AUDIT_EVENTS` | `CONNECT`, `QUERY`, `QUERY_DDL`, `QUERY_DML`, `QUERY_DML_NO_SELECT`, `QUERY_DCL` | `CONNECT`, `QUERY` | I tipi di attività da registrate nel log. Viene registrata anche l'installazione del plug-in per audit MariaDB. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/Appendix.MySQL.Options.AuditPlugin.html) Per MySQL, `TABLE` non è supportato. | | `SERVER_AUDIT_INCL_USERS` | Più valori separati da virgola | Nessuna | Sono incluse solo le attività degli utenti specificati. Per impostazione predefinita, l'attività viene registrata per tutti gli utenti. `SERVER_AUDIT_INCL_USERS` e `SERVER_AUDIT_EXCL_USERS` si escludono a vicenda. Se si aggiungono valori a `SERVER_AUDIT_INCL_USERS`, è necessario assicurarsi che non venga aggiunto alcun valore a `SERVER_AUDIT_EXCL_USERS`. | | `SERVER_AUDIT_EXCL_USERS` | Più valori separati da virgola | Nessuna | Sono escluse le attività degli utenti specificati. Per impostazione predefinita, l'attività viene registrata per tutti gli utenti. `SERVER_AUDIT_INCL_USERS` e `SERVER_AUDIT_EXCL_USERS` si escludono a vicenda. Se si aggiungono valori a `SERVER_AUDIT_EXCL_USERS`, è necessario assicurarsi che non venga aggiunto alcun valore a `SERVER_AUDIT_INCL_USERS`. L'utente `rdsadmin` esegue query sul database ogni secondo per verificare l'integrità del database. In base alle altre impostazioni, questa attività può causare un rapido ed eccessivo aumento delle dimensioni del file di log. Se non desideri registrare questa attività, aggiungi l'utente `rdsadmin` all'elenco `SERVER_AUDIT_EXCL_USERS`. `CONNECT`L'attività viene sempre registrata per tutti gli utenti, anche se l'utente è specificato per l'impostazione di questa opzione. | | `SERVER_AUDIT_LOGGING` | `ON` | `ON` | La registrazione è attiva. L'unico valore valido è `ON`. Amazon RDS non supporta la disattivazione del logging. Se desideri disattivare la registrazione, rimuovi il plug-in per audit MariaDB. Per ulteriori informazioni, consulta [Rimozione del plug-in per audit MariaDB](#Appendix.MySQL.Options.AuditPlugin.Remove). | | `SERVER_AUDIT_QUERY_LOG_LIMIT` | 0–2147483647 | 1.024 | Il limite di lunghezza della stringa di query in un record. | ## Aggiunta del plug-in per audit MariaDB Di seguito è riportato il processo generale per aggiungere il plug-in per audit MariaDB a un'istanza database: + Creare un nuovo gruppo di opzioni oppure copiare o modificare un gruppo di opzioni esistente + Aggiungere l'opzione al gruppo di opzioni + Associare il gruppo di opzioni a questa istanza database Dopo aver aggiunto il plug-in per audit MariaDB, non dovrai riavviare la tua istanza database. Non appena il gruppo di opzioni è attivo, inizia immediatamente l'audit. **Importante** L'aggiunta del plug-in per audit MariaDB a un'istanza database può causare un errore. Consigliamo di aggiungere il plug-in per audit MariaDB durante una finestra di manutenzione o durante o un periodo di carico di lavoro del database basso. **Per aggiungere il plug-in per audit MariaDB** 1. Determinare il gruppo di opzioni che si desidera usare. È possibile creare un nuovo gruppo di opzioni oppure usare un gruppo di opzioni esistente. Se si desidera usare un gruppo di opzioni esistente, puoi passare alla fase successiva. Altrimenti, creare un gruppo di opzioni database personalizzato. Scegli **mysql** per **Motore**, quindi scegli **5.7**, **8.0** o **8.4** per **Versione del motore principale**. Per ulteriori informazioni, consulta [Creazione di un gruppo di opzioni](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.Create). 1. Aggiungere l'opzione **MARIADB\$1AUDIT\$1PLUGIN** al gruppo di opzioni e configurare le impostazioni dell'opzione. Per ulteriori informazioni sull'aggiunta di opzioni, consulta [Aggiunta di un'opzione a un gruppo di opzioni](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.AddOption). Per ulteriori informazioni su ciascuna impostazione, consulta [Impostazioni dell'opzione relativa al plug-in per audit](#Appendix.MySQL.Options.AuditPlugin.Options). 1. Applicare il gruppo di opzioni a un'istanza database nuova o esistente. + Per una nuova istanza database, si applica il gruppo di opzioni quando viene avviata l'istanza. Per ulteriori informazioni, consulta [Creazione di un'istanza database Amazon RDS](USER_CreateDBInstance.md). + Per un'istanza database esistente, viene applicato il gruppo di opzioni modificando l'istanza e collegando il nuovo gruppo di opzioni. Per ulteriori informazioni, consulta [Modifica di un'istanza database Amazon RDS](Overview.DBInstance.Modifying.md). ## Formato dei registri di verifica I file di log sono rappresentati come file con valori delimitati da virgole (CSV) in formato UTF-8. **Suggerimento** Le voci dei log non sono in ordine sequenziale. Per ordinare le voci, utilizza il valore del timestamp. Per visualizzare gli ultimi eventi, potrebbe essere necessario esaminare tutti i file di log. Per una maggiore flessibilità nell'ordinamento e nella ricerca dei dati di registro, attiva l'impostazione per caricare i log di controllo CloudWatch e visualizzarli utilizzando l'interfaccia. CloudWatch Per visualizzare i dati di verifica con più tipi di campi e con output in formato JSON, puoi inoltre utilizzare la caratteristica Database Activity Streams (Flussi di attività di database). Per ulteriori informazioni, consulta [Monitoraggio di Amazon RDS tramite i flussi di attività del database](DBActivityStreams.md). I file dei log di audit includono le seguenti informazioni delimitate da virgola, in righe, nell'ordine specificato: | Campo | Descrizione | | --- | --- | | timestamp | `YYYYMMDD` seguito da `HH:MI:SS` (orologio a 24 ore) per l'evento registrato. | | serverhost | Il nome dell'istanza per cui l'evento viene registrato. | | username | Il nome utente connesso dell'utente. | | host | L'host da cui l'utente ha effettuato la connessione. | | connectionid | Il numero di ID di connessione per l'operazione registrata. | | queryid | Il numero di ID di query che può essere utilizzato per trovare gli eventi di tabella relazionale e le query correlate. Per gli eventi `TABLE`, vengono aggiunte più righe. | | operation | Il tipo di operazione registrata. I valori possibili sono `CONNECT`, `QUERY`, `READ`, `WRITE`, `CREATE`, `ALTER`, `RENAME` e `DROP`. | | database | Il database attivo, come impostato dal comando `USE`. | | oggetto | Per gli eventi `QUERY`, questo valore indica la query eseguita dal database. Per gli eventi `TABLE`, indica il nome di tabella. | | retcode | Il codice restituito dell'operazione di registrazione. | | connection\$1type | Stato di sicurezza della connessione al server. I valori possibili sono: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/UserGuide/Appendix.MySQL.Options.AuditPlugin.html) | ## Visualizzazione e download del log del plug-in per audit MariaDB Dopo avere abilitato il plug-in per audit MariaDB, potrai accedere ai risultati nei file di log nello stesso modo in cui accedi a qualsiasi altro file di log basato su testo. I file di log per audit si trovano in `/rdsdbdata/log/audit/`. Per ulteriori informazioni sulla visualizzazione del file di log nella console, consulta [Visualizzazione ed elenco dei file di log del database](USER_LogAccess.Procedural.Viewing.md). Per informazioni sul download del file di log, consulta [Download di un file di log di database](USER_LogAccess.Procedural.Downloading.md). ## Modifica delle impostazioni del plug-in per audit MariaDB Dopo aver abilitato il plug-in per audit MariaDB, puoi modificare le impostazioni. Per ulteriori informazioni su come modificare le impostazioni dell'opzione, consulta [Modifica di un'impostazione di un'opzione](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.ModifyOption). Per ulteriori informazioni su ciascuna impostazione, consulta [Impostazioni dell'opzione relativa al plug-in per audit](#Appendix.MySQL.Options.AuditPlugin.Options). ## Rimozione del plug-in per audit MariaDB Amazon RDS non supporta la disattivazione della registrazione nel plug-in per audit MariaDB. Puoi tuttavia rimuovere il plug-in da un'istanza database. Dopo aver rimosso il plug-in per audit MariaDB, l'istanza database viene riavviata automaticamente per arrestare l'audit. Per rimuovere il plug-in per audit MariaDB da un'istanza database, procedi in uno dei seguenti modi: + Rimuovere l'opzione relativa al plug-in per audit MariaDB dal gruppo di opzioni a cui appartiene. Questa modifica coinvolge tutte le istanze database che usano il gruppo di opzioni. Per ulteriori informazioni, consulta [Rimozione di un'opzione da un gruppo di opzioni](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.RemoveOption) + Modificare l'istanza database e specificare un diverso gruppo di opzioni che non comprenda il plug-in. Questa modifica coinvolge una singola istanza database. È possibile specificare il gruppo di opzioni predefinito (vuoto) o un gruppo di opzioni personalizzato diverso. Per ulteriori informazioni, consulta [Modifica di un'istanza database Amazon RDS](Overview.DBInstance.Modifying.md). # Supporto per memcached MySQL Amazon RDS supporta l'uso dell'interfaccia `memcached` in tabelle InnoDB, introdotta in MySQL 5.6. L'API `memcached` permette alle applicazioni di usare tabelle InnoDB in modo simile ai datastore di coppie chiave/valore NoSQL. **Nota** L’interfaccia memcached non è più disponibile in MySQL 8.4. Quando aggiorni le istanze database a MySQL 8.4, devi disabilitare `memcached` nei gruppi di opzioni esistenti. L'interfaccia `memcached` è una cache semplice basata su chiave. Le applicazioni utilizzano `memcached` per inserire, manipolare e recuperare dalla cache coppie di dati a chiave-valore. MySQL 5.6 ha introdotto un plugin che implementa un servizio daemon che espone dati di tabelle InnoDB attraverso il protocollo `memcached`. Per ulteriori informazioni sul plugin `memcached` MySQL, consulta [InnoDB Integration with memcached](https://dev.mysql.com/doc/refman/8.0/en/innodb-memcached.html). **Per abilitare il supporto per memcached per un'istanza database RDS per MySQL** 1. Determinare il gruppo di sicurezza da utilizzare per controllare l'accesso all'interfaccia `memcached`. Se il set di applicazioni che sta già utilizzando l'interfaccia SQL è lo stesso che accederà all'interfaccia `memcached`, è possibile utilizzare lo stesso gruppo di sicurezza VPC utilizzato dall'interfaccia SQL. Se il set di applicazioni che accederà all'interfaccia `memcached` è diverso, definire un nuovo gruppo di sicurezza VPC o DB. Per ulteriori informazioni sulla gestione dei gruppi di sicurezza, consulta [Controllo dell'accesso con i gruppi di sicurezza](Overview.RDSSecurityGroups.md) 1. Creare un gruppo di opzioni di database personalizzato, selezionando MySQL come tipo di motore e versione. Per ulteriori informazioni sulla creazione di un gruppo di opzioni, consulta [Creazione di un gruppo di opzioni](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.Create). 1. Aggiungere l'opzione `MEMCACHED` al gruppo di opzioni. Specificare la porta di `memcached` che l'interfaccia utilizzerà e il gruppo di sicurezza da utilizzare per il controllo dell'accesso all'interfaccia. Per ulteriori informazioni sull'aggiunta di opzioni, consulta [Aggiunta di un'opzione a un gruppo di opzioni](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.AddOption). 1. Se necessario, modificare le impostazioni di opzione per configurare i parametri di `memcached`. Per ulteriori informazioni su come modificare le impostazioni dell'opzione, consulta [Modifica di un'impostazione di un'opzione](USER_WorkingWithOptionGroups.md#USER_WorkingWithOptionGroups.ModifyOption). 1. Applica il gruppo di opzioni a un'istanza. Amazon RDS abilita il supporto di `memcached` per l'istanza quando viene applicato il gruppo di opzioni: + Il supporto `memcached` per una nuova istanza viene abilitato specificando il gruppo di opzioni personalizzato quando viene avviata l'istanza. Per ulteriori informazioni sul lancio di un'istanza MySQL, consulta [Creazione di un'istanza database Amazon RDS](USER_CreateDBInstance.md). + Il supporto `memcached` per un'istanza esistente viene abilitato specificando il gruppo di opzioni personalizzato quando si modifica l'istanza. Per ulteriori informazioni sulla modifica di un'istanza database , consulta [Modifica di un'istanza database Amazon RDS](Overview.DBInstance.Modifying.md). 1. Specificare a quali colonne delle tabelle MySQL è possibile accedere attraverso l'interfaccia `memcached`. Il plugin `memcached` crea una tabella catalogo chiamata `containers` all'interno di un database dedicato denominato `innodb_memcache`. Inserire una riga nella tabella `containers` per mappare una tabella InnoDB per l'accesso tramite `memcached`. Specificare una colonna della tabella InnoDB utilizzata per archiviare i valori della chiave `memcached` e una o più colonne utilizzate per archiviare i valori dei dati associati alla chiave. Specificare anche il nome utilizzato da un'applicazione `memcached` per fare riferimento a quel set di colonne. Per i dettagli su come inserire righe nella tabella `containers`, consulta [InnoDB memcached Plugin Internals](https://dev.mysql.com/doc/refman/8.0/en/innodb-memcached-internals.html). Per un esempio di mappatura di una tabella InnoDB e di accesso ad essa tramite `memcached`, consulta [Writing Applications for the InnoDB memcached Plugin](https://dev.mysql.com/doc/refman/8.0/en/innodb-memcached-developing.html). 1. Se le applicazioni che accedono all'`memcached`interfaccia si trovano su computer o EC2 istanze diversi rispetto alle applicazioni che utilizzano l'interfaccia SQL, aggiungi le informazioni di connessione per tali computer al gruppo di sicurezza VPC associato all'istanza MySQL. Per ulteriori informazioni sulla gestione dei gruppi di sicurezza, consulta [Controllo dell'accesso con i gruppi di sicurezza](Overview.RDSSecurityGroups.md). Disabilitare il supporto `memcached` per un'istanza modificandola e specificando il gruppo di opzioni predefinite per la versione di MySQL. Per ulteriori informazioni sulla modifica di un'istanza database , consulta [Modifica di un'istanza database Amazon RDS](Overview.DBInstance.Modifying.md). ## Considerazioni di sicurezza per memcached di MySQL Il protocollo `memcached` non supporta l'autenticazione degli utenti. Per ulteriori informazioni sulle considerazioni sulla sicurezza di MySQL `memcached`, consulta [Considerazioni di sicurezza per il plugin memcached InnoDB](https://dev.mysql.com/doc/refman/8.0/en/innodb-memcached-security.html) nella documentazione di MySQL. Per migliorare la sicurezza dell'interfaccia `memcached`, è possibile adottare le seguenti misure: + Quando aggiungi l'opzione `MEMCACHED` al gruppo di opzioni, specifica una porta diversa dalla porta 11211 predefinita. + Assicurati di associare l'`memcached`interfaccia a un gruppo di sicurezza VPC che limiti l'accesso a indirizzi e istanze client noti e EC2 affidabili. Per ulteriori informazioni sulla gestione dei gruppi di sicurezza, consulta [Controllo dell'accesso con i gruppi di sicurezza](Overview.RDSSecurityGroups.md). ## Informazioni sulla connessione di memcached a MySQL Per accedere all'interfaccia `memcached`, un'applicazione deve specificare sia il nome DNS sia l'istanza Amazon RDS e il numero di porta di `memcached`. Ad esempio, se il nome DNS di un'istanza è `my-cache-instance.cg034hpkmmjt.region.rds.amazonaws.com` e l'interfaccia memcached sta usando la porta 11212, le informazioni di connessione specificate in PHP saranno: ``` 1. connect('my-cache-instance.cg034hpkmmjt.region.rds.amazonaws.com',11212); 5. ?> ``` **Per trovare il nome DNS e la porta di memcached di un'istanza database MySQL** 1. Accedi a Console di gestione AWS e apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Nell'angolo in alto a destra di Console di gestione AWS, seleziona la regione che contiene l'istanza DB. 1. Nel pannello di navigazione, seleziona **Database**. 1. Scegliere il nome dell'istanza database MySQL per visualizzarne i dettagli. 1. Nella sezione **Connect (Connessione)**, prendere nota del valore del campo **Endpoint**. Il nome DNS è lo stesso dell'endpoint. Inoltre, tenere presente che la porta nella sezione **Connect (Connessione)** non si utilizza per accedere all'interfaccia `memcached`. 1. Nella sezione **Details (Dettagli)**, prendere nota del nome elencato nel campo **Option Group (Gruppo di opzioni)**. 1. Nel riquadro di navigazione scegliere **Option groups (Gruppi di opzioni)**. 1. Scegliere il nome del gruppo di opzioni utilizzato dall'istanza database MySQL per visualizzare i dettagli del gruppo di opzioni. Nella sezione **Options (Opzioni)**, prendere nota del valore dell'impostazione **Port (Porta)** per l'opzione **MEMCACHED**. ## Impostazioni dell'opzione memcached di MySQL Amazon RDS espone i parametri `memcached` di MySQL come impostazioni di opzione nell'opzione `MEMCACHED` di Amazon RDS. ### Parametri di memcached di MySQL + `DAEMON_MEMCACHED_R_BATCH_SIZE`: un valore intero che specifica quante operazioni di lettura (get) di `memcached` è necessario eseguire prima di effettuare un COMMIT per iniziare una nuova transazione. I valori validi sono compresi tra 1 e 4294967295; il valore predefinito è 1. L'opzione non ha effetto fino a quando l'istanza non viene riavviata. + `DAEMON_MEMCACHED_W_BATCH_SIZE`: un valore intero che specifica quante operazioni di scrittura di `memcached`, come add, set o incr, è necessario eseguire prima di effettuare un COMMIT per iniziare una nuova transazione. I valori validi sono compresi tra 1 e 4294967295; il valore predefinito è 1. L'opzione non ha effetto fino a quando l'istanza non viene riavviata. + `INNODB_API_BK_COMMIT_INTERVAL`: un valore intero che specifica con quanta frequenza effettuare auto-commit delle connessioni inattive che utilizzano l'interfaccia `memcached` di InnoDB. I valori validi sono compresi tra 1 e 1073741824; il valore predefinito è 5. L'opzione ha effetto immediato senza necessità di riavviare l'istanza. + `INNODB_API_DISABLE_ROWLOCK`: un valore booleano che disabilita (1 (true)) o abilita (0 (false)) l'utilizzo di blocchi di riga quando si utilizza l'interfaccia `memcached` di InnoDB. Il valore predefinito è 0 (false). L'opzione non ha effetto fino a quando l'istanza non viene riavviata. + `INNODB_API_ENABLE_MDL`: un valore booleano che quando impostato su 0 (false) blocca la tabella utilizzata dal plugin `memcached` di InnoDB, in modo che non possa essere eliminata o modificata da DDL attraverso l'interfaccia SQL. Il valore predefinito è 0 (false). L'opzione non ha effetto fino a quando l'istanza non viene riavviata. + `INNODB_API_TRX_LEVEL`: un valore intero che specifica il livello di isolamento della transazione per query elaborate dall'interfaccia `memcached`. I valori consentiti sono da 0 a 3. Il valore predefinito è 0. L'opzione non ha effetto fino a quando l'istanza non viene riavviata. Amazon RDS configura questi parametri `memcached` di MySQL, che non possono essere modificati: `DAEMON_MEMCACHED_LIB_NAME`, `DAEMON_MEMCACHED_LIB_PATH` e `INNODB_API_ENABLE_BINLOG`. I parametri impostati dagli amministratori di MySQL tramite `daemon_memcached_options` sono disponibili come singole impostazioni dell'opzione `MEMCACHED` in Amazon RDS. ### Parametri daemon\$1memcached\$1options di MySQL + `BINDING_PROTOCOL`: una stringa che specifica il protocollo binding da utilizzare. I valori consentiti sono `auto`, `ascii` o `binary`. Quello predefinito è `auto`, vale a dire che il server negozia automaticamente il protocollo con il client. L'opzione non ha effetto fino a quando l'istanza non viene riavviata. + `BACKLOG_QUEUE_LIMIT` – un valore intero che specifica quante connessioni di rete possono essere in attesa di elaborazione da parte di `memcached`. L'aumento di questo limite potrebbe ridurre gli errori ricevuti da un client che non riesce a effettuare la connessione all'istanza `memcached`, ma non migliora le prestazioni del server. I valori validi sono compresi tra 1 e 2048; il valore predefinito è 1024. L'opzione non ha effetto fino a quando l'istanza non viene riavviata. + `CAS_DISABLED`: un valore booleano che abilita (1 (true)) o disabilita (0 (false)) l'utilizzo di compare and swap (CAS), che riduce di 8 byte le dimensioni per voce. Il valore predefinito è 0 (false). L'opzione non ha effetto fino a quando l'istanza non viene riavviata. + `CHUNK_SIZE`: un valore intero che specifica le dimensioni minime (in byte) del blocco da allocare per chiave, valore e flag della voce più piccola. I valori consentiti sono da 1 a 48. Quello predefinito è 48, ma è possibile migliorare notevolmente l'efficienza della memoria con un valore inferiore. L'opzione non ha effetto fino a quando l'istanza non viene riavviata. + `CHUNK_SIZE_GROWTH_FACTOR`: un valore float che controlla le dimensioni dei nuovi blocchi. Le dimensioni di un nuovo blocco sono le dimensioni del blocco precedente moltiplicato per `CHUNK_SIZE_GROWTH_FACTOR`. I valori validi sono compresi tra 1 e 2; il valore predefinito è 1,25. L'opzione non ha effetto fino a quando l'istanza non viene riavviata. + `ERROR_ON_MEMORY_EXHAUSTED`: un valore booleano che, quando è impostato su 1 (true), specifica che `memcached` restituirà un errore anziché eliminare voci quando si esaurisce la memoria per archiviarle. Se impostato su 0 (false), `memcached` eliminerà elementi se la memoria è esaurita. Il valore predefinito è 0 (false). L'opzione non ha effetto fino a quando l'istanza non viene riavviata. + `MAX_SIMULTANEOUS_CONNECTIONS`: un valore intero che specifica il numero massimo di connessioni simultanee. Impostare questo valore al di sotto di 10 impedisce l'avvio di MySQL. I valori validi sono compresi tra 10 e 1024; il valore predefinito è 1024. L'opzione non ha effetto fino a quando l'istanza non viene riavviata. + `VERBOSITY`: una stringa che specifica il livello di informazioni registrate dal servizio `memcached` nel log degli errori di MySQL. Il valore predefinito è v. L'opzione non ha effetto fino a quando l'istanza non viene riavviata. I valori consentiti sono: + `v` – Avvisi ed errori dei log durante l'esecuzione del loop eventi principale. + `vv`: oltre alle informazioni registrate da v, registra anche ogni comando del client e la risposta. + `vvv`: oltre alle informazioni registrate da vv, registra anche le transizioni dello stato interno. Amazon RDS configura questi parametri `DAEMON_MEMCACHED_OPTIONS` di MySQL, che non possono essere modificati: `DAEMON_PROCESS`, `LARGE_MEMORY_PAGES`, `MAXIMUM_CORE_FILE_LIMIT`, `MAX_ITEM_SIZE`, `LOCK_DOWN_PAGE_MEMORY`, `MASK`, `IDFILE`, `REQUESTS_PER_EVENT`, `SOCKET` e `USER`. # Parametri per MySQL Per impostazione predefinita, un'istanza database MySQL utilizza un gruppo di parametri database specifico a un database MySQL. Questo gruppo di parametri contiene parametri per il motore del database MySQL. Per informazioni sull'utilizzo dei gruppi di parametri e sull'impostazione dei parametri, consulta [Gruppi di parametri per Amazon RDS](USER_WorkingWithParamGroups.md). I parametri di RDS for MySQL sono impostati sui valori predefiniti del motore di storage selezionati. Per ulteriori informazioni sui parametri di MySQL, consulta la [documentazione di MySQL](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html). Per ulteriori informazioni sui motori di storage MySQL, consulta [Motori di storage supportati per RDS for MySQL](MySQL.Concepts.FeatureSupport.md#MySQL.Concepts.Storage). È possibile visualizzare i parametri disponibili per una versione RDS for MySQL specifica utilizzando la console RDS o la AWS CLI. Per informazioni sulla visualizzazione dei parametri in un gruppo di parametri MySQL nella console RDS, consulta [Visualizzazione dei valori dei parametri per un gruppo di parametri del database in Amazon RDS](USER_WorkingWithParamGroups.Viewing.md). Utilizzando AWS CLI, è possibile visualizzare i parametri di una versione RDS for MySQL eseguendo il comando [https://docs.aws.amazon.com/cli/latest/reference/rds/describe-engine-default-parameters.html](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-engine-default-parameters.html). Indica uno dei valori seguenti per l’opzione `--db-parameter-group-family`: + `mysql8.4` + `mysql8.0` + `mysql5.7` Ad esempio, per visualizzare i parametri supportati per RDS for MySQL versione 8.0 esegui il comando seguente. ``` aws rds describe-engine-default-parameters --db-parameter-group-family mysql8.0 ``` L'output avrà un aspetto simile al seguente. ``` { "EngineDefaults": { "Parameters": [ { "ParameterName": "activate_all_roles_on_login", "ParameterValue": "0", "Description": "Automatically set all granted roles as active after the user has authenticated successfully.", "Source": "engine-default", "ApplyType": "dynamic", "DataType": "boolean", "AllowedValues": "0,1", "IsModifiable": true }, { "ParameterName": "allow-suspicious-udfs", "Description": "Controls whether user-defined functions that have only an xxx symbol for the main function can be loaded", "Source": "engine-default", "ApplyType": "static", "DataType": "boolean", "AllowedValues": "0,1", "IsModifiable": false }, { "ParameterName": "auto_generate_certs", "Description": "Controls whether the server autogenerates SSL key and certificate files in the data directory, if they do not already exist.", "Source": "engine-default", "ApplyType": "static", "DataType": "boolean", "AllowedValues": "0,1", "IsModifiable": false }, ... ``` Per visualizzare i parametri supportati per RDS for MySQL versione 8.0 esegui il comando seguente. Per Linux, macOS o Unix: ``` aws rds describe-engine-default-parameters --db-parameter-group-family mysql8.0 \ --query 'EngineDefaults.Parameters[?IsModifiable==`true`]' ``` Per Windows: ``` aws rds describe-engine-default-parameters --db-parameter-group-family mysql8.0 ^ --query "EngineDefaults.Parameters[?IsModifiable==`true`]" ``` # Attività di log DBA comuni per istanze database MySQL Questo articolo descrive le implementazioni specifiche di Amazon RDS di alcune attività DBA comuni per le istanze database in esecuzione sul motore di database MySQL. Per offrire un'esperienza di servizio gestito, Amazon RDS non fornisce accesso shell alle istanze database. Limita anche l'accesso ad alcune procedure di sistema e tabelle che richiedono privilegi avanzati. Per informazioni sull'uso di file di log MySQL in Amazon RDS, consult [File di registro del database ](USER_LogAccess.Concepts.MySQL.md). ## Informazioni sugli utenti predefiniti Amazon RDS crea automaticamente diversi utenti predefiniti con istanze database RDS per MySQL. Gli utenti predefiniti e i relativi privilegi non possono essere modificati. Non è possibile eliminare, rinominare o modificare i privilegi per questi utenti predefiniti. Qualsiasi tentativo comporta la generazione di un errore. + **rdsadmin**: un utente creato per gestire molte delle attività di gestione che l’amministratore con privilegi `superuser` esegue su un database MySQL autonomo. Questo utente viene utilizzato internamente da RDS per MySQL per molte attività di gestione. + **rdsrepladmin**: un utente utilizzato internamente da Amazon RDS per supportare le attività di replica su cluster e istanze database RDS per MySQL. Per informazioni su altre attività DBA comuni, consulta gli argomenti indicati di seguito. **Topics** + [ ## Informazioni sugli utenti predefiniti ](#Appendix.MySQL.CommonDBATasks.users) + [ # Privilegio basato sui ruoli per RDS per MySQL ](Appendix.MySQL.CommonDBATasks.privilege-model.md) + [ # Privilegi dinamici per RDS per MySQL ](Appendix.MySQL.CommonDBATasks.dynamic-privileges.md) + [ # Termine di una sessione o una query per RDS per MySQL ](Appendix.MySQL.CommonDBATasks.End.md) + [ # Ignorare l’errore di replica corrente per RDS per MySQL ](Appendix.MySQL.CommonDBATasks.SkipError.md) + [ # Lavorare con i tablespace InnoDB per migliorare i tempi di ripristino dopo un arresto anomalo per RDS per MySQL ](Appendix.MySQL.CommonDBATasks.Tables.md) + [ # Gestione della cronologia dello stato globale per RDS per MySQL ](Appendix.MySQL.CommonDBATasks.GoSH.md) + [ # Configurazione delle dimensioni del pool di buffer e della capacità dei log di redo in MySQL 8.4 ](Appendix.MySQL.CommonDBATasks.Config.Size.8.4.md) # Privilegio basato sui ruoli per RDS per MySQL A partire da RDS per MySQL versione 8.0.36, non è più possibile modificare le tabelle direttamente nel database `mysql`. In particolare, non puoi creare utenti del database eseguendo operazioni DML (Data Manipulation Language) sulle tabelle `grant`. Si utilizzano invece istruzioni di gestione degli account MySQL come `CREATE USER`, `GRANT` e `REVOKE` per concedere privilegi basati sui ruoli agli utenti. Inoltre, nel database `mysql`, non è possibile creare altri tipi di oggetti come le stored procedure. È comunque possibile interrogare le tabelle di `mysql`. Se utilizzi la replica del log binario, le modifiche apportate direttamente alle tabelle `mysql` sull’istanza database di origine non vengono replicate nel cluster di destinazione. In alcuni casi, l'applicazione potrebbe utilizzare scorciatoie per creare utenti o altri oggetti inserendoli nelle tabelle di `mysql`. In tal caso, modifica il codice dell'applicazione per utilizzare le istruzioni corrispondenti come `CREATE USER`. Per esportare i metadati per gli utenti del database durante la migrazione da un database MySQL esterno, utilizza uno dei metodi riportati di seguito: + Utilizza l’utilità di dump delle istanze di MySQL Shell con un filtro per escludere utenti, ruoli e concessioni. L’esempio seguente mostra la sintassi dei comandi da utilizzare. Assicurati che `outputUrl` sia vuoto. ``` mysqlsh user@host -- util.dumpInstance(outputUrl,{excludeSchemas:['mysql'],users: true}) ``` Per ulteriori informazioni, consulta [Instance Dump Utility, Schema Dump Utility, and Table Dump Utility](https://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-shell-utilities-dump-instance-schema.html) nel manuale di riferimento di MySQL. + Usa l’utilità client `mysqlpump`. Questo esempio include tutte le tabelle ad eccezione di quelle nel database di sistema `mysql`. Include anche istruzioni `CREATE USER` e `GRANT` per riprodurre tutti gli utenti MySQL nel database migrato. ``` mysqlpump --exclude-databases=mysql --users ``` L’utilità client `mysqlpump` non è più disponibile con MySQL 8.4. Utilizza invece `mysqldump`. Per semplificare la gestione delle autorizzazioni per molti utenti o applicazioni, è possibile utilizzare l'istruzione `CREATE ROLE` per creare un ruolo con una serie di autorizzazioni. Puoi quindi utilizzare le istruzioni `GRANT` e `SET ROLE` e la funzione `current_role` per assegnare ruoli a utenti o applicazioni, cambiare il ruolo corrente e verificare quali ruoli sono in vigore. Per ulteriori informazioni sul sistema di autorizzazione basato sui ruoli in MySQL 8.0, consultare [Utilizzo di ruoli](https://dev.mysql.com/doc/refman/8.0/en/roles.html) nel Manuale di riferimento di MySQL. **Importante** Si consiglia di non utilizzare l'utente master direttamente nelle applicazioni. Rispetta piuttosto la best practice di utilizzare un utente del database creato con i privilegi minimi richiesti per l'applicazione. A partire dalla versione 8.0.36, RDS per MySQL include un ruolo speciale che ha tutti i seguenti privilegi. Il ruolo è denominato `rds_superuser_role`. L’utente amministrativo principale per ciascuna istanza database ha già concesso questo ruolo. Il ruolo `rds_superuser_role` include i seguenti privilegi per tutti gli oggetti del database: + `ALTER` + `APPLICATION_PASSWORD_ADMIN` + `ALTER ROUTINE` + `CREATE` + `CREATE ROLE` + `CREATE ROUTINE` + `CREATE TEMPORARY TABLES` + `CREATE USER` + `CREATE VIEW` + `DELETE` + `DROP` + `DROP ROLE` + `EVENT` + `EXECUTE` + `INDEX` + `INSERT` + `LOCK TABLES` + `PROCESS` + `REFERENCES` + `RELOAD` + `REPLICATION CLIENT` + `REPLICATION SLAVE` + `ROLE_ADMIN` + `SET_USER_ID` + `SELECT` + `SHOW DATABASES` + `SHOW VIEW` + `TRIGGER` + `UPDATE` + `XA_RECOVER_ADMIN` La definizione del ruolo include anche la `WITH GRANT OPTION` in modo che un utente amministrativo possa concedere tale ruolo ad altri utenti. In particolare, l’amministratore deve concedere tutti i privilegi necessari per eseguire la replica del log binario con il cluster MySQL come destinazione. **Suggerimento** Per visualizzare i dettagli completi delle autorizzazioni, usare la seguente istruzione. ``` SHOW GRANTS FOR rds_superuser_role@'%'; ``` Quando concedi l’accesso utilizzando i ruoli in RDS per MySQL versione 8.0.36 e successive, attivi anche il ruolo utilizzando l’istruzione `SET ROLE role_name` o `SET ROLE ALL`. L'esempio seguente mostra come. Sostituire il nome del ruolo appropriato per `CUSTOM_ROLE`. ``` # Grant role to user mysql> GRANT CUSTOM_ROLE TO 'user'@'domain-or-ip-address' # Check the current roles for your user. In this case, the CUSTOM_ROLE role has not been activated. # Only the rds_superuser_role is currently in effect. mysql> SELECT CURRENT_ROLE(); +--------------------------+ | CURRENT_ROLE() | +--------------------------+ | `rds_superuser_role`@`%` | +--------------------------+ 1 row in set (0.00 sec) # Activate all roles associated with this user using SET ROLE. # You can activate specific roles or all roles. # In this case, the user only has 2 roles, so we specify ALL. mysql> SET ROLE ALL; Query OK, 0 rows affected (0.00 sec) # Verify role is now active mysql> SELECT CURRENT_ROLE(); +--------------------------------------------------+ | CURRENT_ROLE() | +--------------------------------------------------+ | `CUSTOM_ROLE`@`%`,`rds_superuser_role`@`%` | +--------------------------------------------------+ ``` # Privilegi dinamici per RDS per MySQL I privilegi dinamici sono privilegi MySQL che è possibile concedere esplicitamente utilizzando l’istruzione `GRANT`. A seconda della versione di RDS per MySQL, RDS consente di concedere solo privilegi dinamici specifici. RDS non consente alcuni di questi privilegi perché possono interferire con determinate operazioni del database, come la replica e il backup. La tabella seguente mostra quali di questi privilegi è possibile concedere a diverse versioni di MySQL. Se esegui l’aggiornamento da una versione di MySQL precedente alla 8.0.36 o successiva, potrebbe essere necessario aggiornare il codice dell’applicazione se non è più consentito concedere un particolare privilegio. | Privilegio | MySQL 8.0.35 e versioni precedenti | MySQL 8.0.36 e versioni secondarie successive | MySQL 8.4.3 e versioni successive | | --- | --- | --- | --- | | [ALLOW\$1NONEXISTENT\$1DEFINER](https://dev.mysql.com/doc/refman/8.4/en/privileges-provided.html#priv_allow-nonexistent-definer) | Non disponibile | Non disponibile | Non consentito | | [APPLICATION\$1PASSWORD\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_application-password-admin) | Consentito | Consentito | Consentito | | [AUDIT\$1ABORT\$1EXEMPT](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_audit-abort-exempt) | Consentito | Non consentito | Non consentito | | [AUDIT\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_audit-admin) | Non consentito | Non consentito | Non consentito | | [AUTHENTICATION\$1POLICY\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_authentication-policy-admin) | Consentito | Non consentito | Non consentito | | [BACKUP\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_backup-admin) | Consentito | Non consentito | Non consentito | | [BINLOG\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_binlog-admin) | Consentito | Non consentito | Non consentito | | [BINLOG\$1ENCRYPTION\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_binlog-encryption-admin) | Non consentito | Non consentito | Non consentito | | [CLONE\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_clone-admin) | Non consentito | Non consentito | Non consentito | | [CONNECTION\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_connection-admin) | Consentito | Non consentito | Non consentito | | [ENCRYPTION\$1KEY\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_encryption-key-admin) | Non consentito | Non consentito | Non consentito | | [FIREWALL\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_firewall-admin) | Non consentito | Non consentito | Non consentito | | [FIREWALL\$1EXEMPT](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_firewall-exempt) | Consentito | Non consentito | Non consentito | | [FIREWALL\$1USER](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_firewall-user) | Non consentito | Non consentito | Non consentito | | [FLUSH\$1OPTIMIZER\$1COSTS](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_flush-optimizer-costs) | Consentito | Consentito | Consentito | | [FLUSH\$1PRIVILEGI](https://dev.mysql.com/doc/refman/8.4/en/privileges-provided.html#priv_flush-privileges) | Non disponibile | Non disponibile | Consentito | | [FLUSH\$1STATUS](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_flush-status) | Consentito | Consentito | Consentito | | [FLUSH\$1TABLES](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_flush-tables) | Consentito | Consentito | Consentito | | [FLUSH\$1USER\$1RESOURCES](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_flush-user-resources) | Consentito | Consentito | Consentito | | [ADMIN DI REPLICA DI GRUPPO](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_group-replication-admin) | Non consentito | Non consentito | Non consentito | | [GROUP\$1REPLICATION\$1STREAM](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_group-replication-stream) | Non consentito | Non consentito | Non consentito | | [INNODB\$1REDO\$1LOG\$1ARCHIVE](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_innodb-redo-log-archive) | Non consentito | Non consentito | Non consentito | | [INNODB\$1REDO\$1LOG\$1ENABLE](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_innodb-redo-log-enable) | Non consentito | Non consentito | Non consentito | | [MASKING\$1DICTIONARIES\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_masking-dictionaries-admin) | Non consentito | Non consentito | Non consentito | | [NDB\$1STORED\$1USER](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_ndb-stored-user) | Non consentito | Non consentito | Non consentito | | [OPTIMIZE\$1LOCAL\$1TABLE](https://dev.mysql.com/doc/refman/8.4/en/privileges-provided.html#priv_optimize-local-table) | Non disponibile | Non disponibile | Non consentito | | [PASSWORDLESS\$1USER\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_passwordless-user-admin) | Non consentito | Non consentito | Non consentito | | [PERSIST\$1RO\$1VARIABLES\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_persist-ro-variables-admin) | Non consentito | Non consentito | Non consentito | | [REPLICATION\$1APPLIER](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_replication-applier) | Consentito | Non consentito | Non consentito | | [REPLICATION\$1SLAVE\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_replication-slave-admin) | Non consentito | Non consentito | Non consentito | | [RESOURCE\$1GROUP\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_resource-group-admin) | Consentito | Non consentito | Non consentito | | [RESOURCE\$1GROUP\$1USER](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_resource-group-user) | Consentito | Non consentito | Non consentito | | [ROLE\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_role-admin) | Consentito | Consentito | Consentito | | [SENSITIVE\$1VARIABLES\$1OBSERVER](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_sensitive-variables-observer) | Consentito | Consentito | Consentito | | [SERVICE\$1CONNECTION\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_service-connection-admin) | Consentito | Non consentito | Non consentito | | [SESSION\$1VARIABLES\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_session-variables-admin) | Consentito | Consentito | Consentito | | [SET\$1ANY\$1DEFINER](https://dev.mysql.com/doc/refman/8.4/en/privileges-provided.html#priv_set-any-definer) | Non disponibile | Non disponibile | Consentito | | [IMPOSTA USER\$1ID](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_set-user-id) | Consentito | Consentito | Non disponibile | | [SHOW\$1ROUTINE](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_show-routine) | Consentito | Consentito | Consentito | | [SKIP\$1QUERY\$1REWRITE](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_skip-query-rewrite) | Non consentito | Non consentito | Non consentito | | [SYSTEM\$1USER](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_system-user) | Non consentito | Non consentito | Non consentito | | [SYSTEM\$1VARIABLES\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_system-variables-admin) | Non consentito | Non consentito | Non consentito | | [TABLE\$1ENCRYPTION\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_table-encryption-admin) | Non consentito | Non consentito | Non consentito | | [TELEMETRY\$1LOG\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_telemetry-log-admin) | Consentito | Non consentito | Non consentito | | [TP\$1CONNECTION\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_tp-connection-admin) | Non consentito | Non consentito | Non consentito | | [TRANSACTION\$1GTID\$1TAG](https://dev.mysql.com/doc/refman/8.4/en/privileges-provided.html#priv_transaction-gtid-tag) | Non disponibile | Non disponibile | Non consentito | | [VERSION\$1TOKEN\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_version-token-admin) | Non consentito | Non consentito | Non consentito | | [XA\$1RECOVER\$1ADMIN](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_xa-recover-admin) | Consentito | Consentito | Consentito | # Termine di una sessione o una query per RDS per MySQL Puoi terminare query o sessioni utente sulle istanze database utilizzando i comandi `rds_kill` e `rds_kill_query`. Connettiti alla tua istanza database MySQL, quindi immetti il comando appropriato come mostrato di seguito. Per ulteriori informazioni, consulta [Connessione all’istanza database MySQL](USER_ConnectToInstance.md). ``` CALL mysql.rds_kill(thread-ID) CALL mysql.rds_kill_query(thread-ID) ``` Ad esempio, per terminare la sessione in esecuzione sul thread 99, dovresti digitare: ``` CALL mysql.rds_kill(99); ``` Per terminare la query in esecuzione sul thread 99, dovresti digitare: ``` CALL mysql.rds_kill_query(99); ``` # Ignorare l’errore di replica corrente per RDS per MySQL È possibile ignorare un errore sulle repliche di lettura se l'errore provoca il blocco della replica di lettura e non compromette l'integrità dei dati. **Nota** Dovrai prima verificare che sia sicuro ignorare l'errore. In una utility MySQL, connettiti alla replica di lettura ed esegui il seguente comando MySQL. ``` SHOW REPLICA STATUS\G ``` Per informazioni sui valori restituiti, vedere [la documentazione di MySQL](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html). Le versioni precedenti di MySQL utilizzavano `SHOW SLAVE STATUS` anziché `SHOW REPLICA STATUS`. Se si utilizza una versione MySQL prima della 8.0.23, utilizzare `SHOW SLAVE STATUS`. È possibile saltare un errore nella replica di lettura nei seguenti modi. **Topics** + [ ## Chiamata della procedura mysql.rds\$1skip\$1repl\$1error ](#Appendix.MySQL.CommonDBATasks.SkipError.procedure) + [ ## Impostazione del parametro slave\$1skip\$1errors ](#Appendix.MySQL.CommonDBATasks.SkipError.parameter) ## Chiamata della procedura mysql.rds\$1skip\$1repl\$1error Amazon RDS fornisce una stored procedure che puoi chiamare per saltare un errore nelle repliche di lettura. In primo luogo, collegati alla replica di lettura, quindi emetti i comandi appropriati come mostrato qui di seguito. Per ulteriori informazioni, consulta [Connessione all’istanza database MySQL](USER_ConnectToInstance.md). Per ignorare l'errore, puoi emettere il seguente comando. ``` CALL mysql.rds_skip_repl_error; ``` Questo comando non ha alcun effetto se lo esegui sull'istanza database di origine o in una replica di lettura che non ha riscontrato un errore di replica. Per ulteriori informazioni, ad esempio per conoscere le versioni di MySQL che supportano `mysql.rds_skip_repl_error`, consulta [mysql.rds\$1skip\$1repl\$1error](mysql-stored-proc-replicating.md#mysql_rds_skip_repl_error). **Importante** Se tenti di chiamare `mysql.rds_skip_repl_error` e incontri questo errore: `ERROR 1305 (42000): PROCEDURE mysql.rds_skip_repl_error does not exist`, aggiorna l’istanza database MySQL alla versione secondaria più recente o a una delle versioni secondarie minime indicate in [mysql.rds\$1skip\$1repl\$1error](mysql-stored-proc-replicating.md#mysql_rds_skip_repl_error). ## Impostazione del parametro slave\$1skip\$1errors Per saltare uno o più errori, puoi impostare il parametro statico `slave_skip_errors` sulla replica di lettura. Puoi impostare questo parametro per saltare uno o più codici di errore di replica specifici. Attualmente, puoi impostare questo parametro solo per le istanze DB per RDS for MySQL 5.7. Dopo aver modificato l'impostazione per questo parametro, accertati di riavviare l'istanza database per rendere effettiva la nuova impostazione. Per ulteriori informazioni su questo parametro, consulta la [documentazione di MySQL](https://dev.mysql.com/doc/refman/5.7/en/replication-options-replica.html#sysvar_slave_skip_errors). Consigliamo di impostare questo parametro in un gruppo di parametri database a parte. Puoi associare questo gruppo di parametri database solo alle repliche di lettura che devono saltare gli errori. Seguendo questa best practice riduci il potenziale impatto su altre istanze database e sulle repliche di lettura. **Importante** L'impostazione di un valore non predefinito per questo parametro può causare incoerenza nella replica. Impostare questo parametro su un valore non predefinito solo se sono state esaurite le altre opzioni per risolvere il problema e si è sicuri del potenziale impatto sui dati della replica di lettura. # Lavorare con i tablespace InnoDB per migliorare i tempi di ripristino dopo un arresto anomalo per RDS per MySQL Ogni tabella in MySQL è formata da una definizione della tabella, dati e indici. Il motore di storage InnoDB MySQL salva gli indici e i dati della tabella in un *tablespace*. InnoDB crea un tablespace globale condiviso che contiene un dizionario di dati e altri metadati rilevanti e che può inoltre contenere indici e dati della tabella. InnoDB può anche creare degli spazi tabella per ciascuna tabella e partizione. Questi spazi tabella separati vengono salvati in file con estensione .ibd e l'intestazione di ciascuno spazio tabella contiene un numero identificativo univoco. Amazon RDS fornisce un parametro in un gruppo di parametri MySQL denominato `innodb_file_per_table`. Questo parametro controlla se InnoDB aggiunge nuovi dati e indici di tabella allo spazio di tabella condiviso (impostando il valore del parametro su 0) o a singoli spazi di tabella (impostando il valore del parametro su 1). Amazon RDS imposta il valore predefinito per il parametro `innodb_file_per_table` su 1, che consente di eliminare singole tabelle InnoDB e recuperare l'archiviazione utilizzata da tali tabelle per l'istanza database. Nella maggior parte dei casi d'uso l'impostazione del parametro `innodb_file_per_table` su 1 rappresenta l'opzione consigliata. Dovresti impostare il parametro `innodb_file_per_table` su 0 quando hai un numero elevato di tabelle, ad esempio oltre 1.000 tabelle quando utilizzi lo storage standard (magnetico) o lo storage General Purpose SSD oppure oltre 10.000 tabelle quando utilizzi lo storage Provisioned IOPS Quando imposti questo parametro su 0, non vengono creati singoli spazi tabella, pertanto il ripristino dopo un arresto anomalo del database viene completato in minor tempo. MySQL elabora ciascun file dei metadati, che include spazi tabella durante il ciclo di recupero dopo un arresto anomalo. Il tempo richiesto da MySQL per elaborare le informazioni dei metadati negli spazi tabella condivisi è trascurabile rispetto al tempo necessario per elaborare migliaia di file di spazi tabella quando sono presenti più spazi tabella. Poiché il numero di spazi tabella viene salvato nell'intestazione di ciascun file, il tempo complessivo per leggere tutti i file degli spazi tabella può essere di diverse ore. Ad esempio, per elaborare un milione di spazi tabella InnoDB nello storage standard per un ciclo di ripristino dopo un arresto anomalo potrebbero essere necessarie da cinque a otto ore. In alcuni casi, InnoDB può reputare la necessità di una pulizia aggiuntiva dopo un ciclo di ripristino dopo un arresto anomalo che attiverà un altro ciclo di ripristino dopo un arresto anomalo, rendendo più lungo il tempo di ripristino. Ricorda che un ciclo di ripristino dopo un arresto anomalo, oltre all'elaborazione delle informazioni degli spazi tabella, implica transazioni di rollback, riparazioni delle pagine non funzionanti e altre operazioni. Poiché il parametro `innodb_file_per_table` risiede in un gruppo di parametri, puoi cambiare il valore del parametro modificando il gruppo di parametri utilizzato dalla tua istanza database senza riavviarla. Dopo aver cambiato l'impostazione, ad esempio da 1 (per creare tabelle individuali) a 0 (per utilizzare gli spazi tabella condivisi), allo spazio tabella condiviso saranno aggiunte altre tabelle InnoDB, mentre quelle esistenti continueranno ad avere degli spazi tabella individuali. Per spostare una tabella InnoDB in uno spazio tabella condiviso, devi utilizzare il comando `ALTER TABLE`. ## Migrazione di più spazi tabella in uno spazio tabella condiviso Puoi spostare i metadati di una tabella InnoDB dal loro spazio tabella allo spazio tabella condiviso che ricompilerà i metadati della tabella secondo l'impostazione del parametro `innodb_file_per_table`. Connettiti innanzitutto alla tua istanza database MySQL, quindi utilizza i comandi appropriati come mostrato di seguito. Per ulteriori informazioni, consulta [Connessione all’istanza database MySQL](USER_ConnectToInstance.md). ``` ALTER TABLE table_name ENGINE = InnoDB, ALGORITHM=COPY; ``` Ad esempio, la seguente query restituisce un’istruzione `ALTER TABLE` per ogni tabella InnoDB non presente nel tablespace condiviso. **Per le istanze database MySQL 5.7:** ``` SELECT CONCAT('ALTER TABLE `', REPLACE(LEFT(NAME , INSTR((NAME), '/') - 1), '`', '``'), '`.`', REPLACE(SUBSTR(NAME FROM INSTR(NAME, '/') + 1), '`', '``'), '` ENGINE=InnoDB, ALGORITHM=COPY;') AS Query FROM INFORMATION_SCHEMA.INNODB_SYS_TABLES WHERE SPACE <> 0 AND LEFT(NAME, INSTR((NAME), '/') - 1) NOT IN ('mysql',''); ``` **Per le istanze database MySQL 8.4 e 8.0:** ``` SELECT CONCAT('ALTER TABLE `', REPLACE(LEFT(NAME , INSTR((NAME), '/') - 1), '`', '``'), '`.`', REPLACE(SUBSTR(NAME FROM INSTR(NAME, '/') + 1), '`', '``'), '` ENGINE=InnoDB, ALGORITHM=COPY;') AS Query FROM INFORMATION_SCHEMA.INNODB_TABLES WHERE SPACE <> 0 AND LEFT(NAME, INSTR((NAME), '/') - 1) NOT IN ('mysql',''); ``` La ricompilazione di una tabella MySQL per spostare i metadati della tabella nel tablespace condiviso richiede uno spazio di archiviazione ulteriore disponibile nell’istanza database. Durante la ricompilazione, la tabella è bloccata e inaccessibile alle query. Per le tabelle di piccole dimensioni o le tabelle a cui non si accede di frequente, questo potrebbe non essere un problema. Per tabelle di grandi dimensioni o tabelle a cui si accede di frequente in un ambiente con molti processi simultanei, puoi ricompilare le tabelle su una replica di lettura. Puoi creare una replica di lettura e migrare i metadati della tabella nello spazio tabella condiviso sulla replica di lettura. Mentre l'istruzione ALTER TABLE blocca l'accesso sulla replica di lettura, l'istanza database di origine non viene interessata. L'istanza database di origine continuerà a generare i suoi log binari, mentre la replica di lettura sarà in ritardo durante il processo di ricompilazione della tabella. Poiché la ricompilazione richiede spazio di storage aggiuntivo e il file di log di riproduzione può essere di grandi dimensioni, dovresti creare una replica di lettura con uno storage allocato più grande rispetto all'istanza database di origine. Per creare una replica di lettura e ricompilare le tabelle InnoDB per utilizzare lo spazio tabella condiviso, procedere come indicato di seguito: 1. Assicurarsi che la retention dei backup sia abilitata sull'istanza database di origine in modo che sia abilitato il log binario. 1. Usa Console di gestione AWS o AWS CLI per creare una replica di lettura per l'istanza DB di origine. Poiché la creazione di una replica di lettura richiede molti degli stessi processi di un ripristino dopo un arresto anomalo, il processo di creazione potrebbe richiedere diverso tempo se sono presenti numerosi spazi tabella InnoDB. Allocare più spazio di storage sulla replica di lettura rispetto a quello attualmente utilizzato sull'istanza database. 1. Una volta creata la replica di lettura, creare un gruppo di parametri con le impostazioni dei parametri `read_only = 0` e `innodb_file_per_table = 0`. Quindi, associare il gruppo di parametri alla replica di lettura. 1. Immettere la seguente istruzione SQL per tutte le tabelle di cui si desidera eseguire la migrazione nella replica: ``` ALTER TABLE name ENGINE = InnoDB ``` 1. Quando tutte le istruzioni `ALTER TABLE` sono state completate sulla replica di lettura, verificare che quest'ultima sia connessa all'istanza database di origine e che le due istanze siano sincronizzate. 1. Utilizzare la console o la CLI per promuovere la replica di lettura a istanza. Assicurarsi che il gruppo di parametri utilizzato per la nuova istanza DB standalone abbia il parametro `innodb_file_per_table` impostato su 0. Modificare il nome della nuova istanza DB standalone e puntare tutte le applicazioni alla nuova istanza DB standalone. # Gestione della cronologia dello stato globale per RDS per MySQL **Suggerimento** Per analizzare le prestazioni del database, puoi anche utilizzare la funzionalità Approfondimenti sulle prestazioni su Amazon RDS. Per ulteriori informazioni, consulta [Monitoraggio del carico DB con Performance Insights su Amazon RDS](USER_PerfInsights.md). MySQL mantiene molte variabili di stato che forniscono informazioni sul suo funzionamento. Il loro valore può aiutarti a rilevare problemi di blocco o di memoria su un'istanza database. I valori di queste variabili di stato sono cumulativi dal momento dell'ultimo avvio dell'istanza database. Puoi reimpostare la maggiore parte delle variabili di stato su 0 utilizzando il comando `FLUSH STATUS`. Per consentire il monitoraggio di questi valori nel tempo, Amazon RDS fornisce un insieme di procedure che effettuano una snapshot dei valori di queste variabili di stato nel tempo e li scrivono su una tabella insieme alle modifiche eseguite dall'ultima snapshot. Questa infrastruttura, denominata GoSH (Global Status History, cronologia di stato globale), viene installata in tutte le istanze database MySQL a partire dalle versioni 5.5.23. La funzione GoSH è disabilitata per impostazione predefinita. Per abilitare la funzione GoSH dovrai prima abilitare il pianificatore di eventi da un gruppo di parametri database impostando il parametro `event_scheduler` su `ON`. Anche per le istanze database MySQL su cui è in esecuzione MySQL 5.7, imposta il parametro `show_compatibility_56` su `1`. Per informazioni sulla creazione e la modifica di un gruppo di parametri database, consulta [Gruppi di parametri per Amazon RDS](USER_WorkingWithParamGroups.md). Per informazioni sugli effetti collaterali dell'abilitazione di questo parametro, consulta [show\$1compatibility\$156](https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_show_compatibility_56) nel *Manuale di riferimento di MySQL 5.7*. Puoi utilizzare le procedure riportate nella seguente tabella per abilitare e configurare la funzione GoSH. Connettiti innanzitutto alla tua istanza database MySQL, quindi utilizza i comandi appropriati come mostrato di seguito. Per ulteriori informazioni, consulta [Connessione all’istanza database MySQL](USER_ConnectToInstance.md). Per ogni procedura, esegui il comando seguente e sostituisci **procedure-name**: ``` CALL procedure-name; ``` Nella tabella seguente sono elencate tutte le procedure che è possibile utilizzare **procedure-name**nel comando precedente. | Procedura | Descrizione | | --- | --- | | `mysql.rds_enable_gsh_collector` | Abilita la funzione GoSH per acquisire le snapshot per impostazione predefinita a intervalli specificati da `rds_set_gsh_collector`. | | `mysql.rds_set_gsh_collector` | Specifica l'intervallo, in minuti, tra gli snapshot. Il valore predefinito è 5. | | `mysql.rds_disable_gsh_collector` | Disabilita gli snapshot. | | `mysql.rds_collect_global_status_history` | Acquisisce una snapshot a richiesta. | | `mysql.rds_enable_gsh_rotation` | Abilita la rotazione dei contenuti della tabella `mysql.rds_global_status_history` su `mysql.rds_global_status_history_old` a intervalli specificati da `rds_set_gsh_rotation`. | | `mysql.rds_set_gsh_rotation` | Specifica l'intervallo, in giorni, tra le conversioni delle tabelle. Il valore predefinito è 7. | | `mysql.rds_disable_gsh_rotation` | Disabilita la rotazione delle tabelle. | | `mysql.rds_rotate_global_status_history` | Ruota i contenuti della tabella `mysql.rds_global_status_history` su `mysql.rds_global_status_history_old` a richiesta. | Quando la funzione GoSH è in esecuzione, puoi inviare query alle tabelle su cui viene completata la scrittura. Ad esempio, per inviare una query per il numero di riscontri del buffer pool InnoDB, dovresti inviare la seguente query: ``` select a.collection_end, a.collection_start, (( a.variable_Delta-b.variable_delta)/a.variable_delta)*100 as "HitRatio" from mysql.rds_global_status_history as a join mysql.rds_global_status_history as b on a.collection_end = b.collection_end where a. variable_name = 'Innodb_buffer_pool_read_requests' and b.variable_name = 'Innodb_buffer_pool_reads' ``` # Configurazione delle dimensioni del pool di buffer e della capacità dei log di redo in MySQL 8.4 In MySQL 8.4, Amazon RDS abilita il parametro `innodb_dedicated_server` per impostazione predefinita. Con il parametro `innodb_dedicated_server`, il motore del database calcola i parametri `innodb_buffer_pool_size` e `innodb_redo_log_capacity`. Per informazioni su come vengono calcolati questi parametri, consulta [Configuring InnoDB Buffer Pool Size](https://dev.mysql.com/doc/refman/8.4/en/innodb-buffer-pool-resize.html) e [Redo Log](https://dev.mysql.com/doc/refman/8.4/en/innodb-redo-log.html) nella documentazione MySQL. Se è abilitato `innodb_dedicated_server`, il parametro `innodb_buffer_pool_size` viene calcolato in base alla memoria per la classe di istanza database. La tabella seguente mostra la memoria del server rilevata e le dimensioni del pool di buffer corrispondente. | Memoria del server rilevata | Dimensioni del pool di buffer | | --- | --- | | < 1 GB | Valore predefinito di 128 MB | | Da 1 GB a 4 GB | *Detected server memory*\$1 0,5 | | > 4 GB | *Detected server memory*\$1 0,75 | Il `innodb_redo_log_capacity` parametro viene ridimensionato automaticamente in base alla classe di istanza fino a (numero di CPUs v/ 2) GB fino a un massimo di 16 GB. Le classi delle istanze più grandi hanno una maggiore capacità di log di redo, che può migliorare le prestazioni e la resilienza per carichi di lavoro ad alta intensità di scrittura. Prima di effettuare l’aggiornamento da MySQL 8.0 a MySQL 8.4, assicurati di aumentare lo spazio di archiviazione per far fronte a un potenziale aumento delle dimensioni dei log di redo che potrebbe verificarsi dopo il completamento dell’aggiornamento. Per ulteriori informazioni, consulta [Aumento della capacità di storage dell'istanza database](USER_PIOPS.ModifyingExisting.md). Se non desideri che il parametro `innodb_dedicated_server` calcoli i valori per i parametri `innodb_buffer_pool_size` e `innodb_redo_log_capacity`, puoi sovrascrivere questi valori impostando valori specifici per essi in un gruppo di parametri personalizzato. In alternativa, puoi disabilitare il parametro `innodb_dedicated_server` e impostare i valori per i parametri `innodb_buffer_pool_size` e `innodb_redo_log_capacity` in un gruppo di parametri personalizzato. Per ulteriori informazioni, consulta [Gruppi di parametri predefiniti e personalizzati](parameter-groups-overview.md#parameter-groups-overview.custom). Se disabiliti il parametro `innodb_dedicated_server` impostandolo su `0` e non imposti valori per i parametri `innodb_buffer_pool_size` e `innodb_redo_log_capacity`, Amazon RDS imposta gli ultimi due parametri rispettivamente su 128 MB e 100 MB. Con queste impostazioni predefinite si può riscontrare una riduzione delle prestazioni sulle classi di istanze più grandi. # Fuso orario locale per le istanze database MySQL Per impostazione predefinita, il fuso orario per un'istanza database MySQL è in formato Universal Time Coordinated (UTC). Puoi impostare il fuso orario per l'istanza database sul fuso orario locale dell'applicazione. Per impostare il fuso orario locale per un'istanza database, imposta il parametro `time_zone` nel gruppo di parametri per l'istanza database su uno dei valori supportati elencati più avanti in questa sezione. Quando imposti il parametro `time_zone` per un gruppo di parametri, tutte le istanze database e le repliche di lettura che utilizzano tale gruppo di parametri cambiano per utilizzare il nuovo fuso orario locale. Per informazioni sull'impostazione dei parametri in un gruppo di parametri, consulta [Gruppi di parametri per Amazon RDS](USER_WorkingWithParamGroups.md). Dopo aver impostato il fuso orario locale, tutte le nuove connessioni al database riflettono la modifica. Se ci sono connessioni aperte al database quando modifichi il fuso orario locale, questo non viene aggiornato fino a quando non chiudi la connessione e ne apri una nuova. Puoi impostare un fuso orario locale diverso per un'istanza database e una o più delle relative repliche di lettura. A tale scopo, utilizza un gruppo di parametri diverso per l'istanza database e la replica o le repliche e imposta il parametro `time_zone` in ogni gruppo di parametri su un fuso orario locale diverso. Se esegui la replica tra Regioni AWS, l'istanza database di origine e la replica di lettura utilizzano gruppi di parametri diversi (i gruppi di parametri sono univoci per una Regione AWS). Per utilizzare lo stesso fuso orario locale per ogni istanza, imposta il parametro `time_zone` nei gruppi di parametri dell'istanza e della replica di lettura. Quando ripristini un'istanza database da uno snapshot DB, il fuso orario locale è impostato su UTC. Puoi aggiornare il fuso orario impostandolo sul fuso orario locale dopo il completamento del ripristino. Se ripristini un'istanza database a un punto nel tempo, il fuso orario locale per l'istanza database ripristinata corrisponde all'impostazione del fuso orario per il gruppo di parametri dell'istanza database ripristinata. Internet Assigned Numbers Authority (IANA) pubblica nuovi fusi orari all'indirizzo [https://www.iana.org/time-zones](https://www.iana.org/time-zones) più volte all'anno. Ogni volta che RDS rilascia una nuova versione di manutenzione secondaria di MySQL, la versione viene fornita con i dati sul fuso orario più recenti al momento del rilascio. Quando utilizzi le versioni più recenti di RDS per MySQL, hai a disposizione i dati recenti relativi ai fusi orari di RDS. Per assicurarti che l'istanza DB disponga dei dati più aggiornati relativi ai fusi orari, ti consigliamo di eseguire l'aggiornamento a una versione superiore del motore DB. In alternativa, puoi modificare manualmente le tabelle dei fusi orari nelle istanze DB MariaDB. A tale scopo, puoi utilizzare i comandi SQL o eseguire lo strumento [mysql\$1tzinfo\$1to\$1sql](https://dev.mysql.com/doc/refman/8.0/en/mysql-tzinfo-to-sql.html) in un client SQL. Dopo l'aggiornamento manuale dei dati dei fusi orari, avvia l'istanza database per applicare le modifiche. RDS non modifica né ripristina i dati dei fusi orari delle istanze DB in esecuzione. I nuovi dati dei fusi orari vengono installati solo quando si esegue un aggiornamento della versione del motore di database. Puoi impostare il fuso orario locale su uno dei valori seguenti. | Zona | Time zone (Fuso orario) | | --- | --- | | Africa | Africa/Cairo, Africa/Casablanca, Africa/Harare, Africa/Monrovia, Africa/Nairobi, Africa/Tripoli, Africa/Windhoek | | America | America/Araguaina, America/Asuncion, America/Bogota, America/Buenos\$1Aires, America/Caracas, America/Chihuahua, America/Cuiaba, America/Denver, America/Fortaleza, America/Guatemala, America/Halifax, America/Manaus, America/Matamoros, America/Monterrey, America/Montevideo, America/Phoenix, America/Santiago, America/Tijuana | | Asia | Asia/Amman, Asia/Ashgabat, Asia/Baghdad, Asia/Baku, Asia/Bangkok, Asia/Beirut, Asia/Calcutta, Asia/Damasco, Asia/Dhaka, Asia/Irkutsk, Asia/Gerusalemme, Asia/Kabul, Asia/Karachi, Asia/Kathmandu, Asia/Krasnoyarsk, Asia/Magadan, Asia/Muscat, Asia/Novosibirsk, Asia/Riyadh, Asia/Seoul, Asia/Shanghai, Asia/Singapore, Asia/Taipei, Asia/Tehran, Asia/Tokyo, Asia/Ulaanbaatar, Asia/Vladivostok, Asia/Yakutsk, Asia/Yerevan | | Atlantico | Atlantico/Azzorre | | Australia | Australia/Adelaide, Australia/Brisbane, Australia/Darwin, Australia/Hobart, Australia/Perth, Australia/Sydney | | Brasile | Brasile/DeNoronha, Brasile/Est | | Canada | Canada/Newfoundland, Canada/Saskatchewan, Canda/Yukon | | Europa | Europa/Amsterdam, Europa/Atene, Europa/Dublino, Europa/Helsinki, Europa/Istanbul, Europa/Kaliningrad Europa/Mosca, Europa/Parigi, Europa/Praga, Europe/Sarajevo | | Pacifico | Pacifico/Auckland, Pacifico/Fiji, Pacifico/Guam, Pacifico/Honolulu, Pacifico/Samoa | | USA | Stati Uniti/Alaska, Stati Uniti/Centrali, Stati Uniti/Est-Indiana, Stati Uniti/Orientali, Stati Uniti/Pacifico | | UTC | UTC | # Problemi e limitazioni note per Amazon RDS for MySQL I problemi e le limitazioni note per l’utilizzo di Amazon RDS for MySQL sono sotto riportarti. **Topics** + [ ## Parola riservata InnoDB ](#MySQL.Concepts.KnownIssuesAndLimitations.InnodbDatabaseName) + [ ## Comportamento in caso di storage pieno per Amazon RDS for MySQL ](#MySQL.Concepts.StorageFullBehavior) + [ ## Dimensione del pool di buffer Innodb incoerente ](#MySQL.Concepts.KnownIssuesAndLimitations.InnodbBufferPoolSize) + [ ## L'ottimizzazione dell'unione dell'indice restituisce risultati errati ](#MySQL.Concepts.KnownIssuesAndLimitations.IndexMergeOptimization) + [ ## Eccezioni dei parametri di MySQL per le istanze database Amazon RDS ](#MySQL.Concepts.ParameterNotes) + [ ## Limiti delle dimensioni dei file MySQL in Amazon RDS ](#MySQL.Concepts.Limits.FileSize) + [ ## Plugin Keyring MySQL non supportato ](#MySQL.Concepts.Limits.KeyRing) + [ ## Porte personalizzate ](#MySQL.Concepts.KnownIssuesAndLimitations.CustomPorts) + [ ## Limitazioni delle stored procedure di MySQL ](#MySQL.Concepts.KnownIssuesAndLimitations.KillProcedures) + [ ## Replica basata su GTID con un'istanza di origine esterna ](#MySQL.Concepts.KnownIssuesAndLimitations.GTID) + [ ## Plugin di autenticazione MySQL predefinito ](#MySQL.Concepts.KnownIssuesAndLimitations.authentication-plugin) + [ ## Sovrascrivere innodb\$1buffer\$1pool\$1size ](#MySQL.Concepts.KnownIssuesAndLimitations.innodb-bp-size) + [ ## Aggiornamento da MySQL 5.7 a MySQL 8.4 ](#MySQL.Concepts.KnownIssuesAndLimitations.upgrade-8-4) + [ ## Compressione di pagine InnoDB ](#MySQL.Concepts.KnownIssuesAndLimitations.innodb-page-compression) ## Parola riservata InnoDB `InnoDB` è una parola riservata per RDS per MySQL. Non è possibile utilizzare questo nome per un database MySQL. ## Comportamento in caso di storage pieno per Amazon RDS for MySQL Quando lo storage diventa pieno per un'istanza di database MySQL, possono verificarsi delle incongruenze di metadati, disallineamenti del dizionario e tabelle orfane. Per evitare questi problemi, Amazon RDS interrompe automaticamente un'istanza database che raggiunge lo stato `storage-full`. Un'istanza MySQL database raggiunge lo stato `storage-full` nei seguenti casi: + L'istanza database ha meno di 20.000 MiB di storage e lo storage disponibile raggiunge almeno 200 MiB. + L'istanza database ha più di 102.400 MiB di storage e lo storage disponibile raggiunge 1024 MiB o meno. + L'istanza database ha tra 20.000 MiB e 102.400 MiB di storage e ha meno dell'1% di storage disponibile. Dopo che Amazon RDS interrompe automaticamente un'istanza database perché ha raggiunto lo stato `storage-full`, è comunque possibile modificarla. Per riavviare l'istanza database, completa almeno una delle seguenti operazioni: + Modifica l'istanza database per abilitare il dimensionamento automatico dello storage. Per ulteriori informazioni sul dimensionamento automatico dello storage, consulta [Gestione della capacità automaticamente con Auto Scaling dello storage Amazon RDS](USER_PIOPS.Autoscaling.md). + Modifica l'istanza database per aumentarne la capacità di storage. Per ulteriori informazioni sull'aumento della capacità di storage, consulta [Aumento della capacità di storage dell'istanza database](USER_PIOPS.ModifyingExisting.md). Dopo aver apportato una di queste modifiche, l'istanza database viene riavviata automaticamente. Per ulteriori informazioni sulla modifica di un'istanza di database, consulta [Modifica di un'istanza database Amazon RDS](Overview.DBInstance.Modifying.md). ## Dimensione del pool di buffer Innodb incoerente Per MySQL 5.7, esiste attualmente un bug nel modo in cui viene gestita la dimensione del pool di buffer InnoDB. MySQL 5.7 potrebbe regolare il valore del parametro `innodb_buffer_pool_size` in un valore maggiore che possa far sì che il pool di buffer InnoDB diventi troppo grande e utilizzi troppa memoria. Questo effetto può causare l'arresto del motore database MySQL o impedirne l'avvio. Questo problema è più comune per le classi di istanze database con meno memoria disponibile. Per risolvere questo problema, impostare il valore del parametro `innodb_buffer_pool_size` su un multiplo del prodotto del valore del parametro `innodb_buffer_pool_instances` e del valore del parametro `innodb_buffer_pool_chunk_size`. Ad esempio, si potrebbe impostare il valore del parametro `innodb_buffer_pool_size` su un multiplo di otto volte del prodotto del valore del parametro `innodb_buffer_pool_instances` e `innodb_buffer_pool_chunk_size`, come mostrato nel seguente esempio. ``` innodb_buffer_pool_chunk_size = 536870912 innodb_buffer_pool_instances = 4 innodb_buffer_pool_size = (536870912 * 4) * 8 = 17179869184 ``` [Per i dettagli su questo bug di MySQL 5.7, vedi /bug.php? https://bugs.mysql.com id=79379 nella documentazione](https://bugs.mysql.com/bug.php?id=79379) di MySQL. ## L'ottimizzazione dell'unione dell'indice restituisce risultati errati Le query che utilizzano l’ottimizzazione dell’unione degli indici possono restituire risultati errati a causa di un bug nello strumento di ottimizzazione delle query MySQL introdotto in MySQL 5.5.37. Quando esegui una query su una tabella con più indici, lo strumento di ottimizzazione analizza gli intervalli di riga in base a più indici, ma non unisce i risultati correttamente. Per ulteriori informazioni sul bug di Query Optimizer, consulta [http://bugs.mysql.com/bug.php?id=72745](https://bugs.mysql.com/bug.php?id=72745) e [http://bugs.mysql.com/bug.php?id=68194](https://bugs.mysql.com/bug.php?id=68194) nel database dei bug di MySQL. Ad esempio, si consideri una query su una tabella con due indici in cui gli argomenti di ricerca fanno riferimento alle colonne indicizzate. ``` 1. SELECT * FROM table1 2. WHERE indexed_col1 = 'value1' AND indexed_col2 = 'value2'; ``` In questo caso, la ricerca verrà effettuata su entrambi gli indici. A causa del bug, tuttavia, i risultati uniti non sono corretti. Per risolvere il problema, è possibile procedere in uno dei seguenti modi: + Imposta il parametro `optimizer_switch` su `index_merge=off` nel gruppo di parametri di database per l'istanza di database MySQL. Per informazioni sull'impostazione dei parametri appartenenti a un gruppo di parametri di database, consulta [Gruppi di parametri per Amazon RDS](USER_WorkingWithParamGroups.md). + Aggiorna l'istanza database MySQL a MySQL versione 5.7 o 8.0. Per ulteriori informazioni, consulta [Aggiornamenti del motore di database RDS per MySQL](USER_UpgradeDBInstance.MySQL.md). + Se non riesci ad aggiornare l'istanza o a modificare il parametro `optimizer_switch`, puoi aggirare il bug identificando in modo esplicito un indice per la query, ad esempio: ``` 1. SELECT * FROM table1 2. USE INDEX covering_index 3. WHERE indexed_col1 = 'value1' AND indexed_col2 = 'value2'; ``` Per ulteriori informazioni, consulta [Index merge optimization](https://dev.mysql.com/doc/refman/8.0/en/index-merge-optimization.html) nella documentazione di MySQL. ## Eccezioni dei parametri di MySQL per le istanze database Amazon RDS Alcuni parametri MySQL richiedono considerazioni speciali quando vengono utilizzati con un'istanza database Amazon RDS. ### lower\$1case\$1table\$1names Poiché Amazon RDS usa un file system che fa distinzione tra maiuscole e minuscole, l'impostazione del valore del parametro server `lower_case_table_names` su 2 (nomi archiviati come dati ma confrontati in lettere minuscole) non è supportata. Di seguito sono riportati i valori supportati per le istanze database Amazon RDS for MySQL: + 0 (nomi archiviati come dati e confronti con distinzione tra minuscole e maiuscole) è supportato per tutte le versioni di per MySQL. + 1 (nomi memorizzati in minuscolo e confronti non fanno distinzione tra maiuscole e minuscole) è supportato per RDS per MySQL versione 5.7, versione 8.0.28, versioni successive alla 8.0 e versione 8.4. Prima di creare un'istanza database, il parametro `lower_case_table_names` dovrebbe essere impostato come parte di un gruppo di parametri database personalizzato. Quindi, specificare il gruppo di parametri database personalizzato quando viene creata l'istanza database. Quando un gruppo di parametri è associato a un'istanza database MySQL con una versione inferiore a 8.0, si consiglia di evitare di modificare il parametro `lower_case_table_names` nel gruppo di parametri. La modifica potrebbe causare incongruenze nei backup di ripristino e nella lettura delle istanze DB di replica. point-in-time Quando un gruppo di parametri è associato a un’istanza database MySQL versione 8.0 o 8.4, non è possibile modificare il parametro `lower_case_table_names` nel gruppo di parametri. Le repliche di lettura dovrebbero sempre usare lo stesso valore del parametro `lower_case_table_names` in qualità di istanza DB di origine. ### long\$1query\$1time È possibile impostare il parametro `long_query_time` su un valore del punto variabile che consenta di registrare query lente nel log delle query lente MySQL con risoluzione al microsecondo. È possibile impostare un valore come 0,1 secondi, che sarebbe 100 millisecondi, per aiutare durante il debug delle transazioni lente che richiedono meno di un secondo. ## Limiti delle dimensioni dei file MySQL in Amazon RDS Per le istanze database MySQL versione 8.0 e successive, la dimensione massima del file è di 16 TiB. Quando si utilizzano file-per-table i tablespace, la dimensione massima del file limita la dimensione di una tabella InnoDB a 16 TiB. I file-per-table tablespace InnoDB (con tabelle ciascuna nel proprio tablespace) sono impostati di default per le istanze DB MySQL. Per ulteriori informazioni, consulta [InnoDB Limits](https://dev.mysql.com/doc/refman/8.0/en/innodb-limits.html) nella documentazione MySQL. **Nota** Alcune istanze database esistenti hanno un limite inferiore. Ad esempio, le istanze database MySQL create prima di aprile 2014 hanno un limite di dimensioni di file e tabelle di 2 TB. Questo limite di 2 TB delle dimensioni si applica anche alle istanze database o alle repliche di lettura create da snapshot DB effettuati prima di aprile 2014, a prescindere dalla data di creazione dell'istanza database. L'utilizzo dei file-per-table tablespace InnoDB presenta vantaggi e svantaggi, a seconda dell'applicazione. Per determinare l'approccio migliore per la tua applicazione, consulta i [File-per-table tablespace](https://dev.mysql.com/doc/refman/8.0/en/innodb-file-per-table-tablespaces.html) nella documentazione di MySQL. Non è consigliabile consentire alle tabelle di crescere fino alla dimensione massima del file. In generale, una pratica migliore consiste nel partizionare i dati in tabelle più piccole, che possano migliorare le prestazioni e i tempi di ripristino. Un'opzione che è possibile utilizzare per suddividere una tabella di grandi dimensioni in tabelle più piccole è rappresentata dal partizionamento. Il partizionamento distribuisce porzioni della tabella di grandi dimensioni in file separati in base alle regole specificate. Ad esempio, se si archiviano le transazioni per data, è possibile creare regole di partizionamento che distribuiscono le transazioni meno recenti in file separati mediante il partizionamento. Quindi, periodicamente, è possibile archiviare i dati storici della transazione che non devono essere prontamente disponibili per l'applicazione. Per ulteriori informazioni, consulta [Partitioning](https://dev.mysql.com/doc/refman/8.0/en/partitioning.html) nella documentazione MySQL. Poiché non esiste un'unica tabella o vista di sistema che fornisca le dimensioni di tutte le tabelle e dello spazio tabella del sistema InnoDB, è necessario eseguire query su più tabelle per determinare la dimensione degli spazi tabella. **Determinazione della dimensione dello spazio tabella del sistema InnoDB e dello spazio tabella del dizionario dati** + Utilizza il seguente comando SQL per stabilire se qualche spazio tabella supera le dimensioni consentite e può essere scelta per il partizionamento. **Nota** Il tablespace del dizionario dati è specifico di MySQL 8.0 e versioni successive. ``` 1. select FILE_NAME,TABLESPACE_NAME, ROUND(((TOTAL_EXTENTS*EXTENT_SIZE) 2. /1024/1024/1024), 2) as "File Size (GB)" from information_schema.FILES 3. where tablespace_name in ('mysql','innodb_system'); ``` **Determinazione della dimensione delle tabelle utente di InnoDB al di fuori dello spazio tabella del sistema InnoDB (per le versioni 5.7 di MySQL)** + Utilizza il seguente comando SQL per stabilire se qualche tabella supera le dimensioni consentite e può essere scelta per il partizionamento. ``` 1. SELECT SPACE,NAME,ROUND((ALLOCATED_SIZE/1024/1024/1024), 2) 2. as "Tablespace Size (GB)" 3. FROM information_schema.INNODB_SYS_TABLESPACES ORDER BY 3 DESC; ``` **Determinazione della dimensione delle tabelle utente di InnoDB al di fuori del tablespace di sistema InnoDB (per MySQL 8.0 e versioni successive)** + Utilizza il seguente comando SQL per stabilire se qualche tabella supera le dimensioni consentite e può essere scelta per il partizionamento. ``` 1. SELECT SPACE,NAME,ROUND((ALLOCATED_SIZE/1024/1024/1024), 2) 2. as "Tablespace Size (GB)" 3. FROM information_schema.INNODB_TABLESPACES ORDER BY 3 DESC; ``` **Determinazione della dimensione delle tabelle utente non InnoDB** + Utilizza il seguente comando SQL per stabilire se qualche tabella utente non InnoDB ha dimensioni eccessive. ``` SELECT TABLE_SCHEMA, TABLE_NAME, round(((DATA_LENGTH + INDEX_LENGTH+DATA_FREE) / 1024 / 1024/ 1024), 2) As "Approximate size (GB)" FROM information_schema.TABLES WHERE TABLE_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema') and ENGINE<>'InnoDB'; ``` **Per abilitare i tablespace InnoDB file-per-table** + Imposta il parametro *innodb\$1file\$1per\$1table* su `1` nel gruppo di parametri dell'istanza database. **Per disabilitare i tablespace InnoDB file-per-table** + Imposta il parametro *innodb\$1file\$1per\$1table* su `0` nel gruppo di parametri dell'istanza database. Per informazioni sull'aggiornamento di un gruppo di parametri database, consulta [Gruppi di parametri per Amazon RDS](USER_WorkingWithParamGroups.md). Dopo aver abilitato o disabilitato file-per-table i tablespace InnoDB, puoi emettere un `ALTER TABLE` comando per spostare una tabella dal tablespace globale al proprio tablespace o dal proprio tablespace al tablespace globale come mostrato nell'esempio seguente: ``` ALTER TABLE table_name TABLESPACE=innodb_file_per_table; ``` ## Plugin Keyring MySQL non supportato Al momento, Amazon RDS per MySQL non supporta il plugin Keyring Amazon Web Services MySQL `keyring_aws`. ## Porte personalizzate Amazon RDS blocca le connessioni alla porta personalizzata 33060 per il motore MySQL. Scegli una porta diversa per il motore MySQL. ## Limitazioni delle stored procedure di MySQL Le stored procedure [mysql.rds\$1kill](mysql-stored-proc-ending.md#mysql_rds_kill) e [mysql.rds\$1kill\$1query](mysql-stored-proc-ending.md#mysql_rds_kill_query) non possono terminare sessioni o query di proprietà di utenti MySQL con nomi utente più lunghi di 16 caratteri nelle seguenti versioni di RDS per MySQL: + 8.0.32 e versioni precedenti alla 8 + 5.7.41 e versioni precedenti alla 5.7 ## Replica basata su GTID con un'istanza di origine esterna Amazon RDS supporta la replica basata su identificatori di transazione globali (GTIDs) da un'istanza MySQL esterna in un'istanza DB Amazon RDS for MySQL che richiede l'impostazione di GTID\$1PURGED durante la configurazione. Tuttavia, solo RDS per MySQL 8.0.37 e versioni successive supportano questa funzionalità. ## Plugin di autenticazione MySQL predefinito RDS per MySQL versione 8.0.34 e versioni successive alla 8.0 utilizzano il plugin `mysql_native_password`. Non è possibile modificare l'impostazione `default_authentication_plugin`. RDS per MySQL versione 8.4 e versioni successive utilizzano `caching_sha2_password` come plugin di autenticazione predefinito. È possibile modificare il plugin di autenticazione predefinito per MySQL 8.4. Il plugin `mysql_native_password` funziona ancora in MySQL 8.4, ma il relativo supporto termina con questa versione di MySQL. Per modificare il plugin di autenticazione predefinito, creare un gruppo di parametri personalizzato e modificare il valore `authentication_policy`. Per ulteriori informazioni, consulta [Gruppi di parametri predefiniti e personalizzati](parameter-groups-overview.md#parameter-groups-overview.custom). ## Sovrascrivere innodb\$1buffer\$1pool\$1size Con classi di istanze database micro o piccole, il valore predefinito per il parametro `innodb_buffer_pool_size` potrebbe differire da quello restituito eseguendo questo comando: ``` mysql> SELECT @@innodb_buffer_pool_size; ``` Questa differenza può verificarsi quando Amazon RDS deve sovrascrivere il valore predefinito nell’ambito della gestione delle classi di istanze database. Se necessario, si può sovrascrivere il valore predefinito e impostarlo su un valore supportato dalla classe dell’istanza database. Per determinare un valore valido, aggiungi l’utilizzo della memoria e la memoria totale disponibile all’istanza database. Per ulteriori informazioni, consulta [Tipi di istanza Amazon RDS](https://aws.amazon.com/rds/instance-types/). Se l’istanza database in uso ha solo 4 GB di memoria, non è possibile impostare il parametro `innodb_buffer_pool_size` su 8 GB, ma potrebbe essere possibile impostarlo su 3 GB, in base alle quantità di memoria allocata per altri parametri. Se il valore immesso è troppo grande, Amazon RDS lo riduce ai seguenti limiti: + Classi di istanze database micro: 256 MB + Classi di istanze database db.t4g.micro: 128 MB ## Aggiornamento da MySQL 5.7 a MySQL 8.4 Non è possibile eseguire l’aggiornamento direttamente da MySQL 5.7 a MySQL 8.4, ma è necessario eseguire prima l’aggiornamento da MySQL 5.7 a MySQL 8.0 e successivamente da MySQL 8.0 a MySQL 8.4. Per ulteriori informazioni, consulta [Aggiornamenti a versioni principali per RDS per MySQL](USER_UpgradeDBInstance.MySQL.Major.md). ## Compressione di pagine InnoDB La compressione delle pagine InnoDB non funziona con le istanze database di Amazon RDS con una dimensione di blocco del file system di 16 KB perché tale dimensione deve essere inferiore a quella della pagina InnoDB. A partire da febbraio 2024, tutte le istanze database di nuova creazione hanno una dimensione di blocco del file system di 16 KB, che aumenta il throughput e riduce il consumo di IOPS durante lo svuotamento delle pagine. # Riferimento delle stored procedure RDS per MySQL In questi argomenti vengono descritte le stored procedure di sistema disponibili per le istanze Amazon RDS che eseguono il motore di database MySQL. La procedura deve essere eseguita dall'utente master. **Topics** + [ # Raccolta e gestione della cronologia dello stato globale ](mysql-stored-proc-gsh.md) + [ # Configurazione, avvio e arresto della replica dei log binari (binlog) ](mysql-stored-proc-replicating.md) + [ # Terminare una sessione o una query ](mysql-stored-proc-ending.md) + [ # Gestione di cluster attivi-attivi ](mysql-stored-proc-active-active-clusters.md) + [ # Gestione della replica da più origini ](mysql-stored-proc-multi-source-replication.md) + [ # Replica delle transazioni utilizzando GTIDs ](mysql-stored-proc-gtid.md) + [ # Rotazione dei log di query ](mysql-stored-proc-logging.md) + [ # Impostazione e visualizzazione della configurazione dei log binari ](mysql-stored-proc-configuring.md) + [ # Precaricamento della cache di InnoDB ](mysql-stored-proc-warming.md) # Raccolta e gestione della cronologia dello stato globale Amazon RDS fornisce una serie di procedure che acquisiscono uno snapshot dei valori di queste variabili di stato nel tempo e li scrivono in una tabella insieme alle modifiche eseguite dopo l'ultimo snapshot. Questa infrastruttura si chiama cronologia di stato globale. Per ulteriori informazioni, consulta [Gestione della cronologia dello stato globale per RDS per MySQL](Appendix.MySQL.CommonDBATasks.GoSH.md). Le seguenti stored procedure gestiscono il modo in cui la cronologia di stato globale viene raccolta e gestita. **Topics** + [ ## mysql.rds\$1collect\$1global\$1status\$1history ](#mysql_rds_collect_global_status_history) + [ ## mysql.rds\$1disable\$1gsh\$1collector ](#mysql_rds_disable_gsh_collector) + [ ## mysql.rds\$1disable\$1gsh\$1rotation ](#mysql_rds_disable_gsh_rotation) + [ ## mysql.rds\$1enable\$1gsh\$1collector ](#mysql_rds_enable_gsh_collector) + [ ## mysql.rds\$1enable\$1gsh\$1rotation ](#mysql_rds_enable_gsh_rotation) + [ ## mysql.rds\$1rotate\$1global\$1status\$1history ](#mysql_rds_rotate_global_status_history) + [ ## mysql.rds\$1set\$1gsh\$1collector ](#mysql_rds_set_gsh_collector) + [ ## mysql.rds\$1set\$1gsh\$1rotation ](#mysql_rds_set_gsh_rotation) ## mysql.rds\$1collect\$1global\$1status\$1history Acquisisce uno snapshot on demand per la cronologia di stato globale. ### Sintassi ``` CALL mysql.rds_collect_global_status_history; ``` ## mysql.rds\$1disable\$1gsh\$1collector Disabilita gli snapshot creati mediante la cronologia di stato globale. ### Sintassi ``` CALL mysql.rds_disable_gsh_collector; ``` ## mysql.rds\$1disable\$1gsh\$1rotation Disattiva la rotazione della tabella `mysql.global_status_history`. ### Sintassi ``` CALL mysql.rds_disable_gsh_rotation; ``` ## mysql.rds\$1enable\$1gsh\$1collector Abilita la cronologia di stato globale per acquisire snapshot predefiniti agli intervalli specificati da `rds_set_gsh_collector`. ### Sintassi ``` CALL mysql.rds_enable_gsh_collector; ``` ## mysql.rds\$1enable\$1gsh\$1rotation Attiva la rotazione dei contenuti della tabella `mysql.global_status_history` su `mysql.global_status_history_old` agli intervalli specificati da `rds_set_gsh_rotation`. ### Sintassi ``` CALL mysql.rds_enable_gsh_rotation; ``` ## mysql.rds\$1rotate\$1global\$1status\$1history Ruota i contenuti della tabella `mysql.global_status_history` su `mysql.global_status_history_old` a richiesta. ### Sintassi ``` CALL mysql.rds_rotate_global_status_history; ``` ## mysql.rds\$1set\$1gsh\$1collector Specifica l'intervallo, espresso in minuti, tra gli snapshot acquisiti mediante la cronologia di stato globale. ### Sintassi ``` CALL mysql.rds_set_gsh_collector(intervalPeriod); ``` ### Parametri *intervalPeriod* L'intervallo, in minuti, tra gli snapshot. Il valore predefinito è `5`. ## mysql.rds\$1set\$1gsh\$1rotation Specifica l'intervallo, in giorni, tra le conversioni della tabella `mysql.global_status_history`. ### Sintassi ``` CALL mysql.rds_set_gsh_rotation(intervalPeriod); ``` ### Parametri *intervalPeriod* L'intervallo, in giorni, tra le conversioni delle tabelle. Il valore predefinito è `7`. # Configurazione, avvio e arresto della replica dei log binari (binlog) Queste stored procedure controllano il modo in cui le transazioni vengono replicate da un database esterno in RDS per MySQL o viceversa. Quando si utilizzano queste stored procedure per gestire la replica con un utente di replica configurato con `caching_sha2_password`, è necessario configurare TLS specificando `SOURCE_SSL=1`. `caching_sha2_password` è il plugin di autenticazione predefinito per RDS per MySQL 8.4. Per ulteriori informazioni, consulta [Crittografia con SSL/TLS](mysql-ssl-connections.md). Per informazioni sulla configurazione, l’utilizzo e la gestione delle repliche di lettura, consulta [Uso delle repliche di lettura MySQL](USER_MySQL.Replication.ReadReplicas.md). **Topics** + [ ## ](#mysql_rds_next_master_log) + [ ## mysql.rds\$1next\$1source\$1log (RDS per MySQL versioni principali 8.4 e successive) ](#mysql_rds_next_source_log) + [ ## mysql.rds\$1reset\$1external\$1master (RDS per MariaDB e RDS per MySQL versioni principali 8.0 e precedenti) ](#mysql_rds_reset_external_master) + [ ## mysql.rds\$1reset\$1external\$1source (RDS per MySQL versioni principali 8.4 e successive) ](#mysql_rds_reset_external_source) + [ ## mysql.rds\$1set\$1external\$1master (RDS per MariaDB e RDS per MySQL versioni principali 8.0 e precedenti) ](#mysql_rds_set_external_master) + [ ## mysql.rds\$1set\$1external\$1source (RDS per MySQL versioni principali 8.4 e successive) ](#mysql_rds_set_external_source) + [ ## mysql.rds\$1set\$1external\$1master\$1with\$1auto\$1position (RDS per MySQL versioni principali 8.0 e precedenti) ](#mysql_rds_set_external_master_with_auto_position) + [ ## mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position (RDS per MySQL versioni principali 8.4 e successive) ](#mysql_rds_set_external_source_with_auto_position) + [ ## mysql.rds\$1set\$1external\$1master\$1with\$1delay (RDS per MariaDB e RDS per MySQL versioni principali 8.0 e precedenti) ](#mysql_rds_set_external_master_with_delay) + [ ## mysql.rds\$1set\$1external\$1source\$1with\$1delay (RDS per MySQL versioni principali 8.4 e successive) ](#mysql_rds_set_external_source_with_delay) + [ ## mysql.rds\$1set\$1external\$1source\$1gtid\$1purged ](#mysql_rds_set_external_source_gtid_purged) + [ ## ](#mysql_rds_set_master_auto_position) + [ ## mysql.rds\$1set\$1source\$1auto\$1position (RDS per MySQL versioni principali 8.4 e successive) ](#mysql_rds_set_source_auto_position) + [ ## mysql.rds\$1set\$1source\$1delay ](#mysql_rds_set_source_delay) + [ ## mysql.rds\$1skip\$1repl\$1error ](#mysql_rds_skip_repl_error) + [ ## mysql.rds\$1start\$1replication ](#mysql_rds_start_replication) + [ ## ](#mysql_rds_start_replication_until) + [ ## mysql.rds\$1stop\$1replication ](#mysql_rds_stop_replication) ## Cambia la posizione del log dell'istanza database di origine all'inizio del successivo log binario nell'istanza database di origine. Utilizzate questa procedura solo se ricevete l'errore di replica 1236 I/O su una replica di lettura. ### Sintassi ``` CALL mysql.rds_next_master_log( curr_master_log ); ``` ### Parameters *curr\$1master\$1log* L'indice del file di log master corrente. Ad esempio, se il file corrente è denominato `mysql-bin-changelog.012345`, l’indice è 12345. Per determinare il nome del file di log master corrente, esegui il comando `SHOW REPLICA STATUS` e visualizza il campo `Master_Log_File`. ### Note per l’utilizzo La procedura `mysql.rds_next_master_log` deve essere eseguita dall’utente master. **avvertimento** Effettua la chiamata `mysql.rds_next_master_log` solo se la replica fallisce dopo un failover di un'istanza DB Multi-AZ che è l'origine della replica e il campo riporta l'errore 1236. `Last_IO_Errno` `SHOW REPLICA STATUS` I/O La chiamata di `mysql.rds_next_master_log` può comportare una perdita di dati nella replica di lettura se le transazioni nell’istanza di origine non sono state scritte nel log binario sul disco prima dell’evento di failover. Si può diminuire la possibilità che si verifichi una situazione di questo tipo impostando i parametri dell’istanza di origine `sync_binlog` e `innodb_support_xa` su `1`, anche se ciò può compromettere le prestazioni. Per ulteriori informazioni, consulta [Risoluzione dei problemi relativi a una replica di lettura MySQL](USER_ReadRepl.Troubleshooting.md). ### Esempi Supponi che una replica di lettura RDS per MySQL non riesca. L’esecuzione di `SHOW REPLICA STATUS\G` nella replica di lettura restituisce il risultato seguente: ``` *************************** 1. row *************************** Replica_IO_State: Source_Host: myhost.XXXXXXXXXXXXXXX.rr-rrrr-1.rds.amazonaws.com Source_User: MasterUser Source_Port: 3306 Connect_Retry: 10 Source_Log_File: mysql-bin-changelog.012345 Read_Source_Log_Pos: 1219393 Relay_Log_File: relaylog.012340 Relay_Log_Pos: 30223388 Relay_Source_Log_File: mysql-bin-changelog.012345 Replica_IO_Running: No Replica_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Source_Log_Pos: 30223232 Relay_Log_Space: 5248928866 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Source_SSL_Allowed: No Source_SSL_CA_File: Source_SSL_CA_Path: Source_SSL_Cert: Source_SSL_Cipher: Source_SSL_Key: Seconds_Behind_Master: NULL Source_SSL_Verify_Server_Cert: No Last_IO_Errno: 1236 Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Client requested master to start replication from impossible position; the first event 'mysql-bin-changelog.013406' at 1219393, the last event read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4, the last byte read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4.' Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Source_Server_Id: 67285976 ``` Il campo `Last_IO_Errno` mostra che l'istanza riceve l'errore I/O 1236. Il campo `Master_Log_File` mostra che il nome di file è `mysql-bin-changelog.012345`, il che significa che l'indice del file di log è `12345`. Per risolvere il problema, puoi chiamare `mysql.rds_next_master_log` con il seguente parametro: ``` CALL mysql.rds_next_master_log(12345); ``` ## mysql.rds\$1next\$1source\$1log (RDS per MySQL versioni principali 8.4 e successive) Cambia la posizione del log dell'istanza database di origine all'inizio del successivo log binario nell'istanza database di origine. Utilizzare questa procedura solo se si riceve l' I/O errore di replica 1236 su una replica di lettura. ### Sintassi ``` CALL mysql.rds_next_source_log( curr_source_log ); ``` ### Parameters *curr\$1source\$1log* L'indice del file di log di origine corrente. Ad esempio, se il file corrente è denominato `mysql-bin-changelog.012345`, l’indice è 12345. Per determinare il nome del file di log di origine corrente, esegui il comando `SHOW REPLICA STATUS` e visualizza il campo `Source_Log_File`. ### Note per l’utilizzo L’utente amministrativo deve eseguire la procedura `mysql.rds_next_source_log`. **avvertimento** Effettua la chiamata `mysql.rds_next_source_log` solo se la replica fallisce dopo un failover di un'istanza DB Multi-AZ che è l'origine della replica e il campo riporta l'errore 1236. `Last_IO_Errno` `SHOW REPLICA STATUS` I/O La chiamata di `mysql.rds_next_source_log` può comportare una perdita di dati nella replica di lettura se le transazioni nell’istanza di origine non sono state scritte nel log binario sul disco prima dell’evento di failover. Si può diminuire la possibilità che si verifichi una situazione di questo tipo impostando i parametri dell’istanza di origine `sync_binlog` e `innodb_support_xa` su `1`, anche se ciò può compromettere le prestazioni. Per ulteriori informazioni, consulta [Risoluzione dei problemi relativi a una replica di lettura MySQL](USER_ReadRepl.Troubleshooting.md). ### Esempi Supponi che una replica di lettura RDS per MySQL non riesca. L’esecuzione di `SHOW REPLICA STATUS\G` nella replica di lettura restituisce il risultato seguente: ``` *************************** 1. row *************************** Replica_IO_State: Source_Host: myhost.XXXXXXXXXXXXXXX.rr-rrrr-1.rds.amazonaws.com Source_User: MasterUser Source_Port: 3306 Connect_Retry: 10 Source_Log_File: mysql-bin-changelog.012345 Read_Source_Log_Pos: 1219393 Relay_Log_File: relaylog.012340 Relay_Log_Pos: 30223388 Relay_Source_Log_File: mysql-bin-changelog.012345 Replica_IO_Running: No Replica_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Source_Log_Pos: 30223232 Relay_Log_Space: 5248928866 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Source_SSL_Allowed: No Source_SSL_CA_File: Source_SSL_CA_Path: Source_SSL_Cert: Source_SSL_Cipher: Source_SSL_Key: Seconds_Behind_Source: NULL Source_SSL_Verify_Server_Cert: No Last_IO_Errno: 1236 Last_IO_Error: Got fatal error 1236 from source when reading data from binary log: 'Client requested source to start replication from impossible position; the first event 'mysql-bin-changelog.013406' at 1219393, the last event read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4, the last byte read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4.' Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Source_Server_Id: 67285976 ``` Il campo `Last_IO_Errno` mostra che l'istanza riceve l'errore I/O 1236. Il campo `Source_Log_File` mostra che il nome di file è `mysql-bin-changelog.012345`, il che significa che l'indice del file di log è `12345`. Per risolvere il problema, puoi chiamare `mysql.rds_next_source_log` con il seguente parametro: ``` CALL mysql.rds_next_source_log(12345); ``` ## mysql.rds\$1reset\$1external\$1master (RDS per MariaDB e RDS per MySQL versioni principali 8.0 e precedenti) Riconfigura un'istanza database RDS per MySQL affinché non sia più una replica di lettura di un'istanza di MySQL in esecuzione all'esterno di Amazon RDS. **Importante** Per eseguire questa procedura, è necessario abilitare `autocommit`. Per abilitarlo, impostare il parametro `autocommit` su `1`. Per ulteriori informazioni sulla modifica dei parametri, consulta [Modifica dei parametri in un gruppo di parametri database in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). ### Sintassi ``` CALL mysql.rds_reset_external_master; ``` ### Note per l’utilizzo La procedura `mysql.rds_reset_external_master` deve essere eseguita dall'utente master. Questa procedura deve essere eseguita sull’istanza database MySQL da rimuovere come replica di lettura di un’istanza MySQL eseguita esternamente a Amazon RDS. **Nota** Ti consigliamo di usare le repliche di lettura per gestire la replica tra due istanze database di Amazon RDS. In questo caso, si consiglia di usare solo questa e altre stored procedure correlate alla replica. Questo consente di usare topologie di replica più complesse tra le istanze database Amazon RDS. Queste stored procedure sono fornite principalmente per abilitare la replica con le istanze MySQL eseguite esternamente a Amazon RDS. Per ulteriori informazioni sulla gestione della replica tra istanze database Amazon RDS, consulta [Uso delle repliche di lettura dell'istanza database](USER_ReadRepl.md). Per ulteriori informazioni sull’uso della replica per importare dati da un’istanza di MySQL in esecuzione all’esterno di Amazon RDS, consulta [Configurazione della replica della posizione del file di log binario con un'istanza di origine esterna.](MySQL.Procedural.Importing.External.Repl.md). ## mysql.rds\$1reset\$1external\$1source (RDS per MySQL versioni principali 8.4 e successive) Riconfigura un'istanza database RDS per MySQL affinché non sia più una replica di lettura di un'istanza di MySQL in esecuzione all'esterno di Amazon RDS. **Importante** Per eseguire questa procedura, è necessario abilitare `autocommit`. Per abilitarlo, impostare il parametro `autocommit` su `1`. Per ulteriori informazioni sulla modifica dei parametri, consulta [Modifica dei parametri in un gruppo di parametri database in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). ### Sintassi ``` CALL mysql.rds_reset_external_source; ``` ### Note per l’utilizzo L’utente amministrativo deve eseguire la procedura `mysql.rds_reset_external_source`. Questa procedura deve essere eseguita sull’istanza database MySQL da rimuovere come replica di lettura di un’istanza MySQL eseguita esternamente a Amazon RDS. **Nota** Ti consigliamo di usare le repliche di lettura per gestire la replica tra due istanze database di Amazon RDS. In questo caso, si consiglia di usare solo questa e altre stored procedure correlate alla replica. Questo consente di usare topologie di replica più complesse tra le istanze database Amazon RDS. Queste stored procedure sono fornite principalmente per abilitare la replica con le istanze MySQL eseguite esternamente a Amazon RDS. Per ulteriori informazioni sulla gestione della replica tra istanze database Amazon RDS, consulta [Uso delle repliche di lettura dell'istanza database](USER_ReadRepl.md). Per ulteriori informazioni sull'uso della replica per importare dati da un'istanza di MySQL in esecuzione all'esterno di Amazon RDS, consulta [Configurazione della replica della posizione del file di log binario con un'istanza di origine esterna.](MySQL.Procedural.Importing.External.Repl.md). ## mysql.rds\$1set\$1external\$1master (RDS per MariaDB e RDS per MySQL versioni principali 8.0 e precedenti) Configura un'istanza database RDS per MySQL come replica di lettura di un'istanza di MySQL in esecuzione all'esterno di Amazon RDS. **Importante** Per eseguire questa procedura, è necessario abilitare `autocommit`. Per abilitarlo, impostare il parametro `autocommit` su `1`. Per ulteriori informazioni sulla modifica dei parametri, consulta [Modifica dei parametri in un gruppo di parametri database in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). **Nota** Puoi usare la procedura archiviata [mysql.rds\$1set\$1external\$1master\$1with\$1delay (RDS per MariaDB e RDS per MySQL versioni principali 8.0 e precedenti)](#mysql_rds_set_external_master_with_delay) per configurare un’istanza database di origine esterna e una replica ritardata. ### Sintassi ``` CALL mysql.rds_set_external_master ( host_name , host_port , replication_user_name , replication_user_password , mysql_binary_log_file_name , mysql_binary_log_file_location , ssl_encryption ); ``` ### Parameters *host\$1name* Il nome host o l'indirizzo IP dell'istanza di MySQL eseguita esternamente a Amazon RDS per diventare l’istanza database di origine. *host\$1port* La porta utilizzata dall'istanza di MySQL eseguita esternamente a Amazon RDS e da configurare come istanza database di origine. Se la configurazione della rete include la replica della porta Secure Shell (SSH) che converte il numero di porta, specifica il numero di porta esposto da SSH. *replication\$1user\$1name* L'ID di un utente con autorizzazioni `REPLICATION CLIENT` e `REPLICATION SLAVE` nell'istanza di MySQL eseguita esternamente a Amazon RDS. Ti consigliamo di fornire un account utilizzato unicamente per la replica con l'istanza esterna. *replication\$1user\$1password* La password dell'ID utente specificata in `replication_user_name`. *mysql\$1binary\$1log\$1file\$1name* Il nome del log binario sull’istanza database di origine che contiene le informazioni relative alla replica. *mysql\$1binary\$1log\$1file\$1location* La posizione nel log binario `mysql_binary_log_file_name` a partire dalla quale la replica inizia a leggere le informazioni a essa relative. È possibile determinare il nome e la posizione del file binlog in esecuzione `SHOW MASTER STATUS` sull'istanza del database di origine. *ssl\$1encryption* Un valore che specifica se la crittografia Secure Socket Layer (SSL) è utilizzata sulla connessione di replica. 1 indica che la crittografia SSL deve essere utilizzata; 0 specifica che la crittografia non deve essere utilizzata. Il valore predefinito è 0. L’opzione `MASTER_SSL_VERIFY_SERVER_CERT` non è supportata. Questa opzione è impostata su 0, il che significa che la connessione è crittografata, ma i certificati non sono verificati. ### Note per l’utilizzo La procedura `mysql.rds_set_external_master` deve essere eseguita dall'utente master. Questa procedura deve essere eseguita sull’istanza database MySQL da configurare come replica di lettura di un’istanza MySQL eseguita esternamente a Amazon RDS. Prima di eseguire `mysql.rds_set_external_master`, devi configurare l’istanza di MySQL in esecuzione all’esterno di Amazon RDS come istanza database di origine. Per connetterti all'istanza MySQL in esecuzione all'esterno di Amazon RDS, devi specificare i valori di `replication_user_name` e `replication_user_password` che indicano un utente della replica dotato delle autorizzazioni `REPLICATION CLIENT` e `REPLICATION SLAVE` per l'istanza esterna di MySQL. **Per configurare un'istanza esterna di MySQL come istanza database di origine** 1. Mediante il client MySQL scelto, eseguire la connessione all'istanza esterna di MySQL e creare un account utente da utilizzare per la replica. Di seguito è riportato un esempio di : **MySQL 5.7** ``` CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password'; ``` **MySQL 8.0** ``` CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED WITH mysql_native_password BY 'password'; ``` **Nota** Specifica una password diversa dal prompt mostrato qui come best practice per la sicurezza. 1. Nell’istanza esterna di MySQL, concedere i privilegi `REPLICATION CLIENT` e `REPLICATION SLAVE` all’utente della replica. L’esempio seguente concede i privilegi `REPLICATION CLIENT` e `REPLICATION SLAVE` su tutti i database per l’utente “repl\$1user” del dominio: **MySQL 5.7** ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com' IDENTIFIED BY 'password'; ``` **MySQL 8.0** ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com'; ``` Per utilizzare la replica crittografata, configura l'istanza database di origine per utilizzare le connessioni SSL. **Nota** Ti consigliamo di usare le repliche di lettura per gestire la replica tra due istanze database di Amazon RDS. In questo caso, si consiglia di usare solo questa e altre stored procedure correlate alla replica. Questo consente di usare topologie di replica più complesse tra le istanze database Amazon RDS. Queste stored procedure sono fornite principalmente per abilitare la replica con le istanze MySQL eseguite esternamente a Amazon RDS. Per ulteriori informazioni sulla gestione della replica tra istanze database Amazon RDS, consulta [Uso delle repliche di lettura dell'istanza database](USER_ReadRepl.md). Dopo aver chiamato `mysql.rds_set_external_master` per configurare un’istanza database di Amazon RDS come replica di lettura, puoi chiamare [mysql.rds\$1start\$1replication](#mysql_rds_start_replication) nella replica di lettura per avviare il processo di replica. Puoi chiamare [mysql.rds\$1reset\$1external\$1master (RDS per MariaDB e RDS per MySQL versioni principali 8.0 e precedenti)](#mysql_rds_reset_external_master) per rimuovere la configurazione della replica di lettura. Quando `mysql.rds_set_external_master` viene chiamato, Amazon RDS registra l'ora, l'utente e un'operazione di `set master` nelle tabelle `mysql.rds_history` e `mysql.rds_replication_status`. ### Esempi Nel caso di esecuzione su un’istanza database MySQL, l’esempio seguente configura l’istanza database come replica di lettura di un’istanza di MySQL eseguita esternamente a Amazon RDS. ``` call mysql.rds_set_external_master( 'Externaldb.some.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.0777', 120, 1); ``` ## mysql.rds\$1set\$1external\$1source (RDS per MySQL versioni principali 8.4 e successive) Configura un'istanza database RDS per MySQL come replica di lettura di un'istanza di MySQL in esecuzione all'esterno di Amazon RDS. **Importante** Per eseguire questa procedura, è necessario abilitare `autocommit`. Per abilitarlo, impostare il parametro `autocommit` su `1`. Per ulteriori informazioni sulla modifica dei parametri, consulta [Modifica dei parametri in un gruppo di parametri database in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). ### Sintassi ``` CALL mysql.rds_set_external_source ( host_name , host_port , replication_user_name , replication_user_password , mysql_binary_log_file_name , mysql_binary_log_file_location , ssl_encryption ); ``` ### Parameters *host\$1name* Il nome host o l'indirizzo IP dell'istanza di MySQL eseguita esternamente a Amazon RDS per diventare l’istanza database di origine. *host\$1port* La porta utilizzata dall'istanza di MySQL eseguita esternamente a Amazon RDS e da configurare come istanza database di origine. Se la configurazione della rete include la replica della porta Secure Shell (SSH) che converte il numero di porta, specifica il numero di porta esposto da SSH. *replication\$1user\$1name* L'ID di un utente con autorizzazioni `REPLICATION CLIENT` e `REPLICATION SLAVE` nell'istanza di MySQL eseguita esternamente a Amazon RDS. Ti consigliamo di fornire un account utilizzato unicamente per la replica con l'istanza esterna. *replication\$1user\$1password* La password dell'ID utente specificata in `replication_user_name`. *mysql\$1binary\$1log\$1file\$1name* Il nome del log binario sull’istanza database di origine che contiene le informazioni relative alla replica. *mysql\$1binary\$1log\$1file\$1location* La posizione nel log binario `mysql_binary_log_file_name` a partire dalla quale la replica inizia a leggere le informazioni a essa relative. È possibile determinare il nome e la posizione del file binlog in esecuzione `SHOW MASTER STATUS` sull'istanza del database di origine. *ssl\$1encryption* Un valore che specifica se la crittografia Secure Socket Layer (SSL) è utilizzata sulla connessione di replica. 1 indica che la crittografia SSL deve essere utilizzata; 0 specifica che la crittografia non deve essere utilizzata. Il valore predefinito è 0. L’opzione `SOURCE_SSL_VERIFY_SERVER_CERT` non è supportata. Questa opzione è impostata su 0, il che significa che la connessione è crittografata, ma i certificati non sono verificati. ### Note per l’utilizzo L’utente amministrativo deve eseguire la procedura `mysql.rds_set_external_source`. Questa procedura deve essere eseguita nell’istanza database RDS per MySQL da configurare come replica di lettura di un’istanza MySQL eseguita esternamente ad Amazon RDS. Prima di eseguire `mysql.rds_set_external_source`, devi configurare l’istanza di MySQL in esecuzione all’esterno di Amazon RDS come istanza database di origine. Per connetterti all'istanza MySQL in esecuzione all'esterno di Amazon RDS, devi specificare i valori di `replication_user_name` e `replication_user_password` che indicano un utente della replica dotato delle autorizzazioni `REPLICATION CLIENT` e `REPLICATION SLAVE` per l'istanza esterna di MySQL. **Per configurare un'istanza esterna di MySQL come istanza database di origine** 1. Mediante il client MySQL scelto, eseguire la connessione all'istanza esterna di MySQL e creare un account utente da utilizzare per la replica. Di seguito è riportato un esempio di : ``` CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password'; ``` **Nota** Specifica una password diversa dal prompt mostrato qui come best practice per la sicurezza. 1. Nell’istanza esterna di MySQL, concedere i privilegi `REPLICATION CLIENT` e `REPLICATION SLAVE` all’utente della replica. L’esempio seguente concede i privilegi `REPLICATION CLIENT` e `REPLICATION SLAVE` su tutti i database per l’utente “repl\$1user” del dominio: ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com'; ``` Per utilizzare la replica crittografata, configura l'istanza database di origine per utilizzare le connessioni SSL. Importa inoltre il certificato dell'autorità di certificazione, il certificato client e la chiave client nell'istanza database o nel cluster database utilizzando la procedura [mysql.rds\$1import\$1binlog\$1ssl\$1material](url-rds-user;mysql_rds_import_binlog_ssl_material.html). **Nota** Ti consigliamo di usare le repliche di lettura per gestire la replica tra due istanze database di Amazon RDS. In questo caso, si consiglia di usare solo questa e altre stored procedure correlate alla replica. Questo consente di usare topologie di replica più complesse tra le istanze database Amazon RDS. Queste stored procedure sono fornite principalmente per abilitare la replica con le istanze MySQL eseguite esternamente a Amazon RDS. Per ulteriori informazioni sulla gestione della replica tra istanze database Amazon RDS, consulta [Uso delle repliche di lettura dell'istanza database](USER_ReadRepl.md). Dopo aver chiamato `mysql.rds_set_external_source` per configurare un’istanza database RDS per MySQL come replica di lettura, è possibile chiamare [mysql.rds\$1start\$1replication](#mysql_rds_start_replication) sulla replica di lettura per avviare il processo di replica. Puoi chiamare [mysql.rds\$1reset\$1external\$1source (RDS per MySQL versioni principali 8.4 e successive)](#mysql_rds_reset_external_source) per rimuovere la configurazione della replica di lettura. Quando `mysql.rds_set_external_source` viene chiamato, Amazon RDS registra l'ora, l'utente e un'operazione di `set master` nelle tabelle `mysql.rds_history` e `mysql.rds_replication_status`. ### Esempi Se in esecuzione in un’istanza database RDS per MySQL, l’esempio seguente configura l’istanza database come replica di lettura di un’istanza di MySQL eseguita esternamente ad Amazon RDS. ``` call mysql.rds_set_external_source( 'Externaldb.some.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.0777', 120, 1); ``` ## mysql.rds\$1set\$1external\$1master\$1with\$1auto\$1position (RDS per MySQL versioni principali 8.0 e precedenti) Configura un’istanza database RDS per MySQL come replica di lettura di un’istanza di MySQL eseguita esternamente a Amazon RDS. Questa procedura configura anche la replica ritardata e la replica in base agli identificatori di transazione globali (). GTIDs **Importante** Per eseguire questa procedura, è necessario abilitare `autocommit`. Per abilitarlo, impostare il parametro `autocommit` su `1`. Per ulteriori informazioni sulla modifica dei parametri, consulta [Modifica dei parametri in un gruppo di parametri database in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). ### Sintassi ``` CALL mysql.rds_set_external_master_with_auto_position ( host_name , host_port , replication_user_name , replication_user_password , ssl_encryption , delay ); ``` ### Parameters *host\$1name* Il nome host o l'indirizzo IP dell'istanza di MySQL eseguita esternamente a Amazon RDS per diventare l’istanza database di origine. *host\$1port* La porta utilizzata dall'istanza di MySQL eseguita esternamente a Amazon RDS e da configurare come istanza database di origine. Se la configurazione della rete include la replica della porta Secure Shell (SSH) che converte il numero di porta, specifica il numero di porta esposto da SSH. *replication\$1user\$1name* L'ID di un utente con autorizzazioni `REPLICATION CLIENT` e `REPLICATION SLAVE` nell'istanza di MySQL eseguita esternamente a Amazon RDS. Ti consigliamo di fornire un account utilizzato unicamente per la replica con l'istanza esterna. *replication\$1user\$1password* La password dell'ID utente specificata in `replication_user_name`. *ssl\$1encryption* Un valore che specifica se la crittografia Secure Socket Layer (SSL) è utilizzata sulla connessione di replica. 1 indica che la crittografia SSL deve essere utilizzata; 0 specifica che la crittografia non deve essere utilizzata. Il valore predefinito è 0. L’opzione `MASTER_SSL_VERIFY_SERVER_CERT` non è supportata. Questa opzione è impostata su 0, il che significa che la connessione è crittografata, ma i certificati non sono verificati. *delay* Numero minimo di secondi per ritardare la replica dall'istanza database di origine. Il limite per questo parametro è un giorno (86400 secondi). ### Note per l’utilizzo La procedura `mysql.rds_set_external_master_with_auto_position` deve essere eseguita dall'utente master. Questa procedura deve essere eseguita sull’istanza database MySQL da configurare come replica di lettura di un’istanza MySQL eseguita esternamente a Amazon RDS. Questa procedura è supportata per tutte le versioni di RDS per MySQL 5.7 e per RDS per MySQL 8.0.26 e versioni successive alla 8.0. Prima di eseguire `mysql.rds_set_external_master_with_auto_position`, devi configurare l'istanza di MySQL in esecuzione all'esterno di Amazon RDS come istanza database di origine. Per connetterti all'istanza MySQL in esecuzione all'esterno di Amazon RDS, devi specificare i valori per `replication_user_name` e `replication_user_password`. Questi valori devono indicare un utente di replica che dispone delle autorizzazioni `REPLICATION CLIENT` e `REPLICATION SLAVE` sull'istanza esterna di MySQL. **Per configurare un'istanza esterna di MySQL come istanza database di origine** 1. Mediante il client MySQL scelto, eseguire la connessione all'istanza esterna di MySQL e creare un account utente da utilizzare per la replica. Di seguito è riportato un esempio. ``` CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd' ``` 1. Nell'istanza esterna di MySQL, concedere i privilegi `REPLICATION CLIENT` e `REPLICATION SLAVE` all'utente della replica. L'esempio seguente concede i privilegi `REPLICATION CLIENT` e `REPLICATION SLAVE` su tutti i database per l'utente `'repl_user'` per il dominio. ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd' ``` Per ulteriori informazioni, consulta [Configurazione della replica della posizione del file di log binario con un'istanza di origine esterna.](MySQL.Procedural.Importing.External.Repl.md). **Nota** Ti consigliamo di usare le repliche di lettura per gestire la replica tra due istanze database di Amazon RDS. In questo caso, si consiglia di usare solo questa e altre stored procedure correlate alla replica. Questo consente di usare topologie di replica più complesse tra le istanze database Amazon RDS. Queste stored procedure sono fornite principalmente per abilitare la replica con le istanze MySQL eseguite esternamente a Amazon RDS. Per ulteriori informazioni sulla gestione della replica tra istanze database Amazon RDS, consulta [Uso delle repliche di lettura dell'istanza database](USER_ReadRepl.md). Prima di chiamare `mysql.rds_set_external_master_with_auto_position`, assicurati di chiamare [mysql.rds\$1set\$1external\$1source\$1gtid\$1purged](#mysql_rds_set_external_source_gtid_purged) per impostare la variabile di sistema `gtid_purged` con un intervallo di GTID specificato da un’origine esterna. Dopo aver chiamato `mysql.rds_set_external_master_with_auto_position` per configurare un’istanza database di Amazon RDS come replica di lettura, puoi chiamare [mysql.rds\$1start\$1replication](#mysql_rds_start_replication) nella replica di lettura per avviare il processo di replica. Puoi chiamare [mysql.rds\$1reset\$1external\$1master (RDS per MariaDB e RDS per MySQL versioni principali 8.0 e precedenti)](#mysql_rds_reset_external_master) per rimuovere la configurazione della replica di lettura. Quando viene chiamato `mysql.rds_set_external_master_with_auto_position`, Amazon RDS registra l'ora, l'utente e un'operazione `set master` nelle tabelle `mysql.rds_history` e `mysql.rds_replication_status`. Per il disaster recovery puoi usare questa procedura con la stored procedure [](#mysql_rds_start_replication_until) o [](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid). Per effettuare il roll forward delle modifiche a una replica di lettura ritardata al momento immediatamente precedente a un errore, puoi eseguire la procedura `mysql.rds_set_external_master_with_auto_position`. Dopo che la procedura `mysql.rds_start_replication_until_gtid` arresta la replica, puoi promuovere la replica di lettura come nuova istanza database primaria seguendo le istruzioni in [Promozione di una replica di lettura a istanza database standalone](USER_ReadRepl.Promote.md). Per usare la procedura `mysql.rds_rds_start_replication_until_gtid`, è necessario che sia abilitata la replica basata su GTID. Per passare a una specifica transazione basata su GTID che notoriamente causa un problema, puoi usare la stored procedure [](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid). Per ulteriori informazioni sull'utilizzo della replica basata su GTID, consulta [Utilizzo della replica basata su GTID](mysql-replication-gtid.md). ### Esempi Nel caso di esecuzione su un’istanza database MySQL, l’esempio seguente configura l’istanza database come replica di lettura di un’istanza di MySQL eseguita esternamente a Amazon RDS. Imposta il ritardo di replica minimo su un’ora (3600 secondi) nell’istanza database MySQL. Una modifica dall’istanza database di origine MySQL in esecuzione all’esterno di Amazon RDS non viene applicata nella replica di lettura dell’istanza database MySQL per almeno un’ora. ``` call mysql.rds_set_external_master_with_auto_position( 'Externaldb.some.com', 3306, 'repl_user', 'SomePassW0rd', 1, 3600); ``` ## mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position (RDS per MySQL versioni principali 8.4 e successive) Configura un’istanza database RDS per MySQL come replica di lettura di un’istanza di MySQL eseguita esternamente a Amazon RDS. Questa procedura configura anche la replica ritardata e la replica in base agli identificatori di transazione globali (). GTIDs **Importante** Per eseguire questa procedura, è necessario abilitare `autocommit`. Per abilitarlo, impostare il parametro `autocommit` su `1`. Per ulteriori informazioni sulla modifica dei parametri, consulta [Modifica dei parametri in un gruppo di parametri database in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). ### Sintassi ``` CALL mysql.rds_set_external_source_with_auto_position ( host_name , host_port , replication_user_name , replication_user_password , ssl_encryption , delay ); ``` ### Parameters *host\$1name* Il nome host o l'indirizzo IP dell'istanza di MySQL eseguita esternamente a Amazon RDS per diventare l’istanza database di origine. *host\$1port* La porta utilizzata dall'istanza di MySQL eseguita esternamente a Amazon RDS e da configurare come istanza database di origine. Se la configurazione della rete include la replica della porta Secure Shell (SSH) che converte il numero di porta, specifica il numero di porta esposto da SSH. *replication\$1user\$1name* L'ID di un utente con autorizzazioni `REPLICATION CLIENT` e `REPLICATION SLAVE` nell'istanza di MySQL eseguita esternamente a Amazon RDS. Ti consigliamo di fornire un account utilizzato unicamente per la replica con l'istanza esterna. *replication\$1user\$1password* La password dell'ID utente specificata in `replication_user_name`. *ssl\$1encryption* Un valore che specifica se la crittografia Secure Socket Layer (SSL) è utilizzata sulla connessione di replica. 1 indica che la crittografia SSL deve essere utilizzata; 0 specifica che la crittografia non deve essere utilizzata. Il valore predefinito è 0. L’opzione `SOURCE_SSL_VERIFY_SERVER_CERT` non è supportata. Questa opzione è impostata su 0, il che significa che la connessione è crittografata, ma i certificati non sono verificati. *delay* Numero minimo di secondi per ritardare la replica dall'istanza database di origine. Il limite per questo parametro è un giorno (86400 secondi). ### Note per l’utilizzo L’utente amministrativo deve eseguire la procedura `mysql.rds_set_external_source_with_auto_position`. Questa procedura deve essere eseguita sull’istanza database MySQL da configurare come replica di lettura di un’istanza MySQL eseguita esternamente a Amazon RDS. Prima di eseguire `mysql.rds_set_external_source_with_auto_position`, devi configurare l'istanza di MySQL in esecuzione all'esterno di Amazon RDS come istanza database di origine. Per connetterti all'istanza MySQL in esecuzione all'esterno di Amazon RDS, devi specificare i valori per `replication_user_name` e `replication_user_password`. Questi valori devono indicare un utente di replica che dispone delle autorizzazioni `REPLICATION CLIENT` e `REPLICATION SLAVE` sull'istanza esterna di MySQL. **Per configurare un'istanza esterna di MySQL come istanza database di origine** 1. Mediante il client MySQL scelto, eseguire la connessione all'istanza esterna di MySQL e creare un account utente da utilizzare per la replica. Di seguito è riportato un esempio. ``` CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd' ``` 1. Nell'istanza esterna di MySQL, concedere i privilegi `REPLICATION CLIENT` e `REPLICATION SLAVE` all'utente della replica. L'esempio seguente concede i privilegi `REPLICATION CLIENT` e `REPLICATION SLAVE` su tutti i database per l'utente `'repl_user'` per il dominio. ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd' ``` Per ulteriori informazioni, consulta [Configurazione della replica della posizione del file di log binario con un'istanza di origine esterna.](MySQL.Procedural.Importing.External.Repl.md). **Nota** Ti consigliamo di usare le repliche di lettura per gestire la replica tra due istanze database di Amazon RDS. In questo caso, si consiglia di usare solo questa e altre stored procedure correlate alla replica. Questo consente di usare topologie di replica più complesse tra le istanze database Amazon RDS. Queste stored procedure sono fornite principalmente per abilitare la replica con le istanze MySQL eseguite esternamente a Amazon RDS. Per ulteriori informazioni sulla gestione della replica tra istanze database Amazon RDS, consulta [Uso delle repliche di lettura dell'istanza database](USER_ReadRepl.md). Prima di chiamare `mysql.rds_set_external_source_with_auto_position`, assicurati di chiamare [mysql.rds\$1set\$1external\$1source\$1gtid\$1purged](#mysql_rds_set_external_source_gtid_purged) per impostare la variabile di sistema `gtid_purged` con un intervallo di GTID specificato da un’origine esterna. Dopo aver chiamato `mysql.rds_set_external_source_with_auto_position` per configurare un’istanza database di Amazon RDS come replica di lettura, puoi chiamare [mysql.rds\$1start\$1replication](#mysql_rds_start_replication) nella replica di lettura per avviare il processo di replica. Puoi chiamare [mysql.rds\$1reset\$1external\$1source (RDS per MySQL versioni principali 8.4 e successive)](#mysql_rds_reset_external_source) per rimuovere la configurazione della replica di lettura. Quando viene chiamato `mysql.rds_set_external_source_with_auto_position`, Amazon RDS registra l'ora, l'utente e un'operazione `set master` nelle tabelle `mysql.rds_history` e `mysql.rds_replication_status`. Per il disaster recovery puoi usare questa procedura con la stored procedure [](#mysql_rds_start_replication_until) o [](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid). Per effettuare il roll forward delle modifiche a una replica di lettura ritardata al momento immediatamente precedente a un errore, puoi eseguire la procedura `mysql.rds_set_external_source_with_auto_position`. Dopo che la procedura `mysql.rds_start_replication_until_gtid` arresta la replica, puoi promuovere la replica di lettura come nuova istanza database primaria seguendo le istruzioni in [Promozione di una replica di lettura a istanza database standalone](USER_ReadRepl.Promote.md). Per usare la procedura `mysql.rds_rds_start_replication_until_gtid`, è necessario che sia abilitata la replica basata su GTID. Per passare a una specifica transazione basata su GTID che notoriamente causa un problema, puoi usare la stored procedure [](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid). Per ulteriori informazioni sull'utilizzo della replica basata su GTID, consulta [Utilizzo della replica basata su GTID](mysql-replication-gtid.md). ### Esempi Nel caso di esecuzione su un’istanza database MySQL, l’esempio seguente configura l’istanza database come replica di lettura di un’istanza di MySQL eseguita esternamente a Amazon RDS. Imposta il ritardo di replica minimo su un’ora (3600 secondi) nell’istanza database MySQL. Una modifica dall’istanza database di origine MySQL in esecuzione all’esterno di Amazon RDS non viene applicata nella replica di lettura dell’istanza database MySQL per almeno un’ora. ``` call mysql.rds_set_external_source_with_auto_position( 'Externaldb.some.com', 3306, 'repl_user', 'SomePassW0rd', 1, 3600); ``` ## mysql.rds\$1set\$1external\$1master\$1with\$1delay (RDS per MariaDB e RDS per MySQL versioni principali 8.0 e precedenti) Configura un'istanza database RDS for MySQL come replica di lettura di un'istanza di MySQL in esecuzione all'esterno di Amazon RDS e configura la replica ritardata. **Importante** Per eseguire questa procedura, è necessario abilitare `autocommit`. Per abilitarlo, impostare il parametro `autocommit` su `1`. Per ulteriori informazioni sulla modifica dei parametri, consulta [Modifica dei parametri in un gruppo di parametri database in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). ### Sintassi ``` CALL mysql.rds_set_external_master_with_delay( host_name , host_port , replication_user_name , replication_user_password , mysql_binary_log_file_name , mysql_binary_log_file_location , ssl_encryption , delay ); ``` ### Parameters *host\$1name* Nome host o indirizzo IP dell'istanza MySQL in esecuzione all'esterno di Amazon RDS che diventerà l'istanza database di origine. *host\$1port* La porta utilizzata dall'istanza di MySQL eseguita esternamente a Amazon RDS e da configurare come istanza database di origine. Se la configurazione della rete include la replica della porta SSH che converte il numero di porta, specifica il numero di porta esposto da SSH. *replication\$1user\$1name* L'ID di un utente con autorizzazioni `REPLICATION CLIENT` e `REPLICATION SLAVE` nell'istanza di MySQL eseguita esternamente a Amazon RDS. Ti consigliamo di fornire un account utilizzato unicamente per la replica con l'istanza esterna. *replication\$1user\$1password* La password dell'ID utente specificata in `replication_user_name`. *mysql\$1binary\$1log\$1file\$1name* Il nome del log binario sull’istanza database di origine contiene le informazioni relative alla replica. *mysql\$1binary\$1log\$1file\$1location* Posizione nel log binario `mysql_binary_log_file_name` a partire dalla quale la replica inizierà a leggere le informazioni di replica. È possibile determinare il nome e la posizione del file binlog in esecuzione `SHOW MASTER STATUS` sull'istanza del database di origine. *ssl\$1encryption* Un valore che specifica se la crittografia Secure Socket Layer (SSL) è utilizzata sulla connessione di replica. 1 indica che la crittografia SSL deve essere utilizzata; 0 specifica che la crittografia non deve essere utilizzata. Il valore predefinito è 0. L’opzione `MASTER_SSL_VERIFY_SERVER_CERT` non è supportata. Questa opzione è impostata su 0, il che significa che la connessione è crittografata, ma i certificati non sono verificati. *delay* Numero minimo di secondi per ritardare la replica dall'istanza database di origine. Il limite per questo parametro è un giorno (86400 secondi). ### Note per l’utilizzo La procedura `mysql.rds_set_external_master_with_delay` deve essere eseguita dall'utente master. Questa procedura deve essere eseguita sull’istanza database MySQL da configurare come replica di lettura di un’istanza MySQL eseguita esternamente a Amazon RDS. Prima di eseguire `mysql.rds_set_external_master_with_delay`, devi configurare l'istanza di MySQL in esecuzione all'esterno di Amazon RDS come istanza database di origine. Per connetterti all'istanza MySQL in esecuzione all'esterno di Amazon RDS, devi specificare i valori per `replication_user_name` e `replication_user_password`. Questi valori devono indicare un utente di replica che dispone delle autorizzazioni `REPLICATION CLIENT` e `REPLICATION SLAVE` sull'istanza esterna di MySQL. **Per configurare un'istanza esterna di MySQL come istanza database di origine** 1. Mediante il client MySQL scelto, eseguire la connessione all'istanza esterna di MySQL e creare un account utente da utilizzare per la replica. Di seguito è riportato un esempio. ``` CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd' ``` 1. Nell'istanza esterna di MySQL, concedere i privilegi `REPLICATION CLIENT` e `REPLICATION SLAVE` all'utente della replica. L'esempio seguente concede i privilegi `REPLICATION CLIENT` e `REPLICATION SLAVE` su tutti i database per l'utente `'repl_user'` per il dominio. ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd' ``` Per ulteriori informazioni, consulta [Configurazione della replica della posizione del file di log binario con un'istanza di origine esterna.](MySQL.Procedural.Importing.External.Repl.md). **Nota** Ti consigliamo di usare le repliche di lettura per gestire la replica tra due istanze database di Amazon RDS. In questo caso, si consiglia di usare solo questa e altre stored procedure correlate alla replica. Questo consente di usare topologie di replica più complesse tra le istanze database Amazon RDS. Queste stored procedure sono fornite principalmente per abilitare la replica con le istanze MySQL eseguite esternamente a Amazon RDS. Per ulteriori informazioni sulla gestione della replica tra istanze database Amazon RDS, consulta [Uso delle repliche di lettura dell'istanza database](USER_ReadRepl.md). Dopo aver chiamato `mysql.rds_set_external_master_with_delay` per configurare un'istanza database di Amazon RDS come replica di lettura, puoi chiamare [mysql.rds\$1start\$1replication](#mysql_rds_start_replication) nella replica di lettura per avviare il processo di replica. Puoi chiamare [mysql.rds\$1reset\$1external\$1master (RDS per MariaDB e RDS per MySQL versioni principali 8.0 e precedenti)](#mysql_rds_reset_external_master) per rimuovere la configurazione della replica di lettura. Quando viene chiamato `mysql.rds_set_external_master_with_delay`, Amazon RDS registra l'ora, l'utente e un'operazione `set master` nelle tabelle `mysql.rds_history` e `mysql.rds_replication_status`. Per il disaster recovery puoi usare questa procedura con la stored procedure [](#mysql_rds_start_replication_until) o [](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid). Per effettuare il roll forward delle modifiche a una replica di lettura ritardata al momento immediatamente precedente a un errore, puoi eseguire la procedura `mysql.rds_set_external_master_with_delay`. Dopo che la procedura `mysql.rds_start_replication_until` arresta la replica, puoi promuovere la replica di lettura come nuova istanza database primaria seguendo le istruzioni in [Promozione di una replica di lettura a istanza database standalone](USER_ReadRepl.Promote.md). Per usare la procedura `mysql.rds_rds_start_replication_until_gtid`, è necessario che sia abilitata la replica basata su GTID. Per passare a una specifica transazione basata su GTID che notoriamente causa un problema, puoi usare la stored procedure [](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid). Per ulteriori informazioni sull'utilizzo della replica basata su GTID, consulta [Utilizzo della replica basata su GTID](mysql-replication-gtid.md). La procedura `mysql.rds_set_external_master_with_delay` è disponibile nelle seguenti versioni di RDS per MySQL: + MySQL 8.0.26 e versioni successive alla 8.0 + Tutte le versioni 5.7 ### Esempi Nel caso di esecuzione su un’istanza database MySQL, l’esempio seguente configura l’istanza database come replica di lettura di un’istanza di MySQL eseguita esternamente a Amazon RDS. Imposta il ritardo di replica minimo su un’ora (3600 secondi) nell’istanza database MySQL. Una modifica dall’istanza database di origine MySQL in esecuzione all’esterno di Amazon RDS non viene applicata nella replica di lettura dell’istanza database MySQL per almeno un’ora. ``` call mysql.rds_set_external_master_with_delay( 'Externaldb.some.com', 3306, 'repl_user', 'SomePassW0rd', 'mysql-bin-changelog.000777', 120, 1, 3600); ``` ## mysql.rds\$1set\$1external\$1source\$1with\$1delay (RDS per MySQL versioni principali 8.4 e successive) Configura un'istanza database RDS for MySQL come replica di lettura di un'istanza di MySQL in esecuzione all'esterno di Amazon RDS e configura la replica ritardata. **Importante** Per eseguire questa procedura, è necessario abilitare `autocommit`. Per abilitarlo, impostare il parametro `autocommit` su `1`. Per ulteriori informazioni sulla modifica dei parametri, consulta [Modifica dei parametri in un gruppo di parametri database in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). ### Sintassi ``` CALL mysql.rds_set_external_source_with_delay ( host_name , host_port , replication_user_name , replication_user_password , mysql_binary_log_file_name , mysql_binary_log_file_location , ssl_encryption , delay ); ``` ### Parameters *host\$1name* Nome host o indirizzo IP dell'istanza MySQL in esecuzione all'esterno di Amazon RDS che diventerà l'istanza database di origine. *host\$1port* La porta utilizzata dall'istanza di MySQL eseguita esternamente a Amazon RDS e da configurare come istanza database di origine. Se la configurazione della rete include la replica della porta SSH che converte il numero di porta, specifica il numero di porta esposto da SSH. *replication\$1user\$1name* L'ID di un utente con autorizzazioni `REPLICATION CLIENT` e `REPLICATION SLAVE` nell'istanza di MySQL eseguita esternamente a Amazon RDS. Ti consigliamo di fornire un account utilizzato unicamente per la replica con l'istanza esterna. *replication\$1user\$1password* La password dell'ID utente specificata in `replication_user_name`. *mysql\$1binary\$1log\$1file\$1name* Il nome del log binario sull’istanza database di origine contiene le informazioni relative alla replica. *mysql\$1binary\$1log\$1file\$1location* Posizione nel log binario `mysql_binary_log_file_name` a partire dalla quale la replica inizierà a leggere le informazioni di replica. È possibile determinare il nome e la posizione del file binlog in esecuzione `SHOW MASTER STATUS` sull'istanza del database di origine. *ssl\$1encryption* Un valore che specifica se la crittografia Secure Socket Layer (SSL) è utilizzata sulla connessione di replica. 1 indica che la crittografia SSL deve essere utilizzata; 0 specifica che la crittografia non deve essere utilizzata. Il valore predefinito è 0. L’opzione `SOURCE_SSL_VERIFY_SERVER_CERT` non è supportata. Questa opzione è impostata su 0, il che significa che la connessione è crittografata, ma i certificati non sono verificati. *delay* Numero minimo di secondi per ritardare la replica dall'istanza database di origine. Il limite per questo parametro è un giorno (86400 secondi). ### Note per l’utilizzo L’utente amministrativo deve eseguire la procedura `mysql.rds_set_external_source_with_delay`. Questa procedura deve essere eseguita sull’istanza database MySQL da configurare come replica di lettura di un’istanza MySQL eseguita esternamente a Amazon RDS. Prima di eseguire `mysql.rds_set_external_source_with_delay`, devi configurare l'istanza di MySQL in esecuzione all'esterno di Amazon RDS come istanza database di origine. Per connetterti all'istanza MySQL in esecuzione all'esterno di Amazon RDS, devi specificare i valori per `replication_user_name` e `replication_user_password`. Questi valori devono indicare un utente di replica che dispone delle autorizzazioni `REPLICATION CLIENT` e `REPLICATION SLAVE` sull'istanza esterna di MySQL. **Per configurare un'istanza esterna di MySQL come istanza database di origine** 1. Mediante il client MySQL scelto, eseguire la connessione all'istanza esterna di MySQL e creare un account utente da utilizzare per la replica. Di seguito è riportato un esempio. ``` CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd' ``` 1. Nell'istanza esterna di MySQL, concedere i privilegi `REPLICATION CLIENT` e `REPLICATION SLAVE` all'utente della replica. L'esempio seguente concede i privilegi `REPLICATION CLIENT` e `REPLICATION SLAVE` su tutti i database per l'utente `'repl_user'` per il dominio. ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com' IDENTIFIED BY 'SomePassW0rd' ``` Per ulteriori informazioni, consulta [Configurazione della replica della posizione del file di log binario con un'istanza di origine esterna.](MySQL.Procedural.Importing.External.Repl.md). **Nota** Ti consigliamo di usare le repliche di lettura per gestire la replica tra due istanze database di Amazon RDS. In questo caso, si consiglia di usare solo questa e altre stored procedure correlate alla replica. Questo consente di usare topologie di replica più complesse tra le istanze database Amazon RDS. Queste stored procedure sono fornite principalmente per abilitare la replica con le istanze MySQL eseguite esternamente a Amazon RDS. Per ulteriori informazioni sulla gestione della replica tra istanze database Amazon RDS, consulta [Uso delle repliche di lettura dell'istanza database](USER_ReadRepl.md). Dopo aver chiamato `mysql.rds_set_external_source_with_delay` per configurare un'istanza database di Amazon RDS come replica di lettura, puoi chiamare [mysql.rds\$1start\$1replication](#mysql_rds_start_replication) nella replica di lettura per avviare il processo di replica. Puoi chiamare [mysql.rds\$1reset\$1external\$1source (RDS per MySQL versioni principali 8.4 e successive)](#mysql_rds_reset_external_source) per rimuovere la configurazione della replica di lettura. Quando viene chiamato `mysql.rds_set_external_source_with_delay`, Amazon RDS registra l'ora, l'utente e un'operazione `set master` nelle tabelle `mysql.rds_history` e `mysql.rds_replication_status`. Per il disaster recovery puoi usare questa procedura con la stored procedure [](#mysql_rds_start_replication_until) o [](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid). Per effettuare il roll forward delle modifiche a una replica di lettura ritardata al momento immediatamente precedente a un errore, puoi eseguire la procedura `mysql.rds_set_external_source_with_delay`. Dopo che la procedura `mysql.rds_start_replication_until` arresta la replica, puoi promuovere la replica di lettura come nuova istanza database primaria seguendo le istruzioni in [Promozione di una replica di lettura a istanza database standalone](USER_ReadRepl.Promote.md). Per usare la procedura `mysql.rds_rds_start_replication_until_gtid`, è necessario che sia abilitata la replica basata su GTID. Per passare a una specifica transazione basata su GTID che notoriamente causa un problema, puoi usare la stored procedure [](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid). Per ulteriori informazioni sull'utilizzo della replica basata su GTID, consulta [Utilizzo della replica basata su GTID](mysql-replication-gtid.md). ### Esempi Nel caso di esecuzione su un’istanza database MySQL, l’esempio seguente configura l’istanza database come replica di lettura di un’istanza di MySQL eseguita esternamente a Amazon RDS. Imposta il ritardo di replica minimo su un’ora (3600 secondi) nell’istanza database MySQL. Una modifica dall’istanza database di origine MySQL in esecuzione all’esterno di Amazon RDS non viene applicata nella replica di lettura dell’istanza database MySQL per almeno un’ora. ``` call mysql.rds_set_external_source_with_delay( 'Externaldb.some.com', 3306, 'repl_user', 'SomePassW0rd', 'mysql-bin-changelog.000777', 120, 1, 3600); ``` ## mysql.rds\$1set\$1external\$1source\$1gtid\$1purged Imposta la variabile di sistema [gtid\$1purged](https://dev.mysql.com/doc/refman/8.0/en/replication-options-gtids.html#sysvar_gtid_purged) con un intervallo GTID specificato da un’origine esterna. Il valore `gtid_purged` è necessario per configurare la replica basata su GTID per riprendere la replica utilizzando il posizionamento automatico. **Importante** Per eseguire questa procedura, è necessario abilitare `autocommit`. Per abilitarlo, impostare il parametro `autocommit` su `1`. Per ulteriori informazioni sulla modifica dei parametri, consulta [Modifica dei parametri in un gruppo di parametri database in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). ### Sintassi ``` CALL mysql.rds_set_external_source_gtid_purged( server_uuid , start_pos , end_pos ); ``` ### Parameters *server\$1uuid* Identificatore univoco universale (UUID) del server esterno da cui viene importato l’intervallo GTID. *start\$1pos* Posizione iniziale dell’intervallo GTID da impostare. *end\$1pos* Posizione finale dell’intervallo GTID da impostare. ### Note per l’utilizzo La procedura `mysql.rds_set_external_source_gtid_purged` è disponibile solo con MySQL 8.0.37 e versioni successive alla 8.0. Chiama `mysql.rds_set_external_source_gtid_purged` prima di chiamare [mysql.rds\$1set\$1external\$1master\$1with\$1auto\$1position (RDS per MySQL versioni principali 8.0 e precedenti)](#mysql_rds_set_external_master_with_auto_position), [mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position (RDS per MySQL versioni principali 8.4 e successive)](#mysql_rds_set_external_source_with_auto_position) o [mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position\$1for\$1channel](mysql-stored-proc-multi-source-replication.md#mysql_rds_set_external_source_with_auto_position_for_channel). Prima di chiamare `mysql.rds_set_external_source_gtid_purged`, assicurati di arrestare tutti i canali di replica attivi per il database. Per controllare lo stato di un canale, usa l’istruzione `SHOW REPLICA STATUS` MySQL. Per arrestare la replica su un canale, chiama [mysql.rds\$1stop\$1replication\$1for\$1channel](mysql-stored-proc-multi-source-replication.md#mysql_rds_stop_replication_for_channel). L’intervallo GTID specificato deve essere un superset del valore `GTID_PURGED` esistente. Prima di impostare il valore `GTID_PURGED`, la stored procedure esegue i controlli seguenti: + `server_uuid` deve essere valido. + Il valore di `start_pos` deve essere maggiore di `0` e minore del valore di `end_pos`. + Il valore di `end_pos` deve essere maggiore di o uguale al valore di `start_pos`. Se il GTID impostato sul server esterno contiene più intervalli di valori, prendi in considerazione la possibilità di chiamare la procedura più volte con valori di GTID diversi. Quando si chiama `mysql.rds_set_external_source_gtid_purged`, Amazon RDS registra l’ora, l’utente e un’operazione `set gtid_purged` nella tabella `mysql.rds_history`. L’impostazione non appropriata del valore `gtid_purged` per il backup utilizzato per la replica può comportare transazioni mancanti o duplicate durante il processo di replica. Per impostare il valore `gtid_purged` corretto, esegui queste operazioni. **Per impostare il valore gtid\$1purged nella replica** 1. Determina il punto temporale o il file di backup specifico da utilizzare come punto di partenza per la replica. Potrebbe trattarsi di un backup logico (file mysqldump) o di un backup fisico (snapshot Amazon RDS). 1. Determina il valore `gtid_executed`. Questo valore rappresenta l'insieme di tutto ciò GTIDs che è stato eseguito sul server. Per recuperare questo valore, sull’istanza di origine, procedi in uno dei modi seguenti: + Esegui l’istruzione SQL `SELECT @@GLOBAL.GTID_EXECUTED;` nel momento in cui è stato eseguito il backup. + Se nella rispettiva utilità di backup sono incluse opzioni correlate, estrai il valore dal file di backup. Per ulteriori informazioni, consulta l'[set-gtid-purged](https://dev.mysql.com/doc/refman/8.4/en/mysqldump.html#option_mysqldump_set-gtid-purged)opzione nella documentazione di MySQL. 1. Determina il valore `gtid_purged` da utilizzare per la chiamata a `mysql.rds_set_external_source_gtid_purged`. Il `gtid_purged` valore dovrebbe includere tutto ciò GTIDs che è stato eseguito sull'istanza di origine e non è più necessario per la replica. Di conseguenza, il valore `gtid_purged` deve essere un sottoinsieme del valore `gtid_executed` ottenuto nel passaggio precedente. Per determinare il `gtid_purged` valore, identifica quelli GTIDs che non sono inclusi nel backup e non sono più necessari per la replica. È possibile farlo analizzando i log binari o utilizzando uno strumento come mysqlbinlog per trovare quelli che sono stati eliminati dai log binari. GTIDs In alternativa, se si dispone di un backup coerente che include tutti i log binari fino al punto di backup, è possibile impostare il valore `gtid_purged` in modo che sia uguale al valore `gtid_executed` nel punto di backup. 1. Dopo aver determinato il valore `gtid_purged` appropriato coerente con il backup, chiama la stored procedure `mysql.rds_set_external_source_gtid_purged` nell’istanza database RDS per MySQL per impostare il valore. ### Esempi Se eseguito in un’istanza database MySQL, l’esempio seguente imposta l’intervallo GTID da un server MySQL esterno con l’UUID `12345678-abcd-1234-efgh-123456789abc`, una posizione iniziale di `1` e una posizione finale di `100`. Il valore GTID risultante è impostato su `+12345678-abcd-1234-efgh-123456789abc:1-100`. ``` CALL mysql.rds_set_external_source_gtid_purged('12345678-abcd-1234-efgh-123456789abc', 1, 100); ``` ## Imposta la modalità di replica in modo che sia basata sulle posizioni dei file di registro binari o sugli identificatori globali delle transazioni (). GTIDs ### Sintassi ``` CALL mysql.rds_set_master_auto_position ( auto_position_mode ); ``` ### Parameters *auto\$1position\$1mode* Valore che indica se usare la replica basata sulla posizione del file di log o la replica basata su GTID: + `0` – Usa il metodo di replica basato sulla posizione del file di log binario. Il valore di default è `0`. + `1` – Usa il metodo di replica basato su GTID. ### Note per l’utilizzo La procedura `mysql.rds_set_master_auto_position` deve essere eseguita dall’utente master. Questa procedura è supportata per tutte le versioni di RDS per MySQL 5.7 e per RDS per MySQL 8.0.26 e versioni successive alla 8.0. ## mysql.rds\$1set\$1source\$1auto\$1position (RDS per MySQL versioni principali 8.4 e successive) Imposta la modalità di replica in modo che sia basata sulle posizioni dei file di registro binari o sugli identificatori globali delle transazioni (). GTIDs ### Sintassi ``` CALL mysql.rds_set_source_auto_position (auto_position_mode); ``` ### Parameters *auto\$1position\$1mode* Valore che indica se usare la replica basata sulla posizione del file di log o la replica basata su GTID: + `0` – Usa il metodo di replica basato sulla posizione del file di log binario. Il valore di default è `0`. + `1` – Usa il metodo di replica basato su GTID. ### Note per l'utilizzo L'utente amministrativo deve eseguire la procedura `mysql.rds_set_source_auto_position`. ## mysql.rds\$1set\$1source\$1delay Imposta il numero minimo di secondi per ritardare la replica dall'istanza database di origine alla replica di lettura corrente. Usa questa procedura in presenza di una connessione a una replica di lettura per ritardare la replica rispetto all’istanza database di origine. ### Sintassi ``` CALL mysql.rds_set_source_delay( delay ); ``` ### Parameters *delay* Numero minimo di secondi per ritardare la replica dall'istanza database di origine. Il limite per questo parametro è un giorno (86400 secondi). ### Note per l’utilizzo La procedura `mysql.rds_set_source_delay` deve essere eseguita dall'utente master. Per il disaster recovery puoi usare questa procedura con la stored procedure [](#mysql_rds_start_replication_until) o [](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid). Per effettuare il roll forward delle modifiche a una replica di lettura ritardata al momento immediatamente precedente a un errore, puoi eseguire la procedura `mysql.rds_set_source_delay`. Dopo che la procedura `mysql.rds_start_replication_until` o `mysql.rds_start_replication_until_gtid` arresta la replica, puoi promuovere la replica di lettura come nuova istanza database master seguendo le istruzioni in [Promozione di una replica di lettura a istanza database standalone](USER_ReadRepl.Promote.md). Per usare la procedura `mysql.rds_rds_start_replication_until_gtid`, è necessario che sia abilitata la replica basata su GTID. Per passare a una specifica transazione basata su GTID che notoriamente causa un problema, puoi usare la stored procedure [](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid). Per ulteriori informazioni sulla replica basata su GTID, consulta [Utilizzo della replica basata su GTID](mysql-replication-gtid.md). La procedura `mysql.rds_set_source_delay` è disponibile nelle seguenti versioni di RDS for MySQL: + Tutte le versioni di RDS per MySQL 8.4 + MySQL 8.0.26 e versioni successive alla 8.0 + Tutte le versioni 5.7 ### Esempi Per ritardare la replica rispetto all’istanza database di origine nella replica di lettura corrente per almeno un'ora (3600 secondi), puoi chiamare `mysql.rds_set_source_delay` con il parametro seguente: ``` CALL mysql.rds_set_source_delay(3600); ``` ## mysql.rds\$1skip\$1repl\$1error Ignora ed elimina un errore di replica su una replica di lettura database MySQL. ### Sintassi ``` CALL mysql.rds_skip_repl_error; ``` ### Note per l’utilizzo La procedura `mysql.rds_skip_repl_error` deve essere eseguita dall'utente master su una replica di lettura. Per ulteriori informazioni su questa procedura, consulta [Chiamata della procedura mysql.rds\$1skip\$1repl\$1error](Appendix.MySQL.CommonDBATasks.SkipError.md#Appendix.MySQL.CommonDBATasks.SkipError.procedure). Per determinare se ci sono errori, esegui il comando MySQL `SHOW REPLICA STATUS\G`. Se un errore di replica non è critico, puoi eseguire `mysql.rds_skip_repl_error` per ignorare l'errore. Se vi sono più errori, `mysql.rds_skip_repl_error` elimina il primo, quindi informa della presenza di altri errori. Puoi quindi utilizzare `SHOW REPLICA STATUS\G` per determinare l'operazione corretta per l'errore successivo. Per informazioni sui valori restituiti, consulta [Istruzione SHOW REPLICA STATUS](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html) nella documentazione di MySQL. Per ulteriori informazioni sulla risoluzione degli errori di replica con Amazon RDS, consulta [Risoluzione dei problemi relativi a una replica di lettura MySQL](USER_ReadRepl.Troubleshooting.md). #### Errore di replica interrotta Quando si chiama la procedura `mysql.rds_skip_repl_error`, è possibile che venga visualizzato un messaggio di errore che indica che la replica è inattiva o disattivata. Questo messaggio di errore viene visualizzato se si esegue la procedura sull'istanza primaria anziché sulla replica di lettura. È necessario eseguire questa procedura sulla replica di lettura affinché funzioni. Questo messaggio di errore può essere visualizzato anche quando si esegue la procedura sulla replica di lettura, ma la replica non viene riavviata correttamente. Se devi ignorare un numero elevato di errori, il ritardo della replica potrebbe superare il periodo di retention predefinito per i file di log binari (binlog). In questo caso può verificarsi un errore irreversibile causato dall’eliminazione dei file binlog prima della loro riproduzione nella replica di lettura. Questa eliminazione causa l'arresto della replica e non è più possibile chiamare il comando `mysql.rds_skip_repl_error` per ignorare errori di replica. Puoi limitare questo problema aumentando il numero di ore di retention dei file binlog nell’istanza database di origine. Una volta aumentato il tempo di retention dei file binlog, puoi riavviare la replica e chiamare il comando `mysql.rds_skip_repl_error` secondo necessità. Per impostare il periodo di retention dei file binlog, usa la procedura [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) e specifica un parametro di configurazione di `'binlog retention hours'` insieme al numero di ore di retention dei file binlog nel cluster di database. Nell'esempio seguente il periodo di retention dei file binlog è impostato su 48 ore. ``` CALL mysql.rds_set_configuration('binlog retention hours', 48); ``` ## mysql.rds\$1start\$1replication Avvia la replica da un'istanza database RDS per MySQL. **Nota** Puoi usare la stored procedure [](#mysql_rds_start_replication_until) o [](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid) per avviare la replica da un'istanza database RDS per MySQL e arrestare la replica in corrispondenza della posizione del file di log binario specificato. ### Sintassi ``` CALL mysql.rds_start_replication; ``` ### Note per l’utilizzo La procedura `mysql.rds_start_replication` deve essere eseguita dall’utente master. Per importare dati da un’istanza MySQL in esecuzione all’esterno di Amazon RDS, chiama `mysql.rds_start_replication` nella replica di lettura per avviare il processo di replica dopo aver chiamato [mysql.rds\$1set\$1external\$1master (RDS per MariaDB e RDS per MySQL versioni principali 8.0 e precedenti)](#mysql_rds_set_external_master) o [mysql.rds\$1set\$1external\$1source (RDS per MySQL versioni principali 8.4 e successive)](#mysql_rds_set_external_source) per creare la configurazione della replica. Per ulteriori informazioni, consulta [Ripristino di un backup in un’istanza database Amazon RDS per MySQL](MySQL.Procedural.Importing.md). Per esportare dati in un'istanza di MySQL in esecuzione all'esterno di Amazon RDS, devi chiamare `mysql.rds_start_replication` e `mysql.rds_stop_replication` nella replica di lettura per controllare alcune operazioni di replica, come l'eliminazione di log binari. Per ulteriori informazioni, consulta [Esportazione di dati da un'istanza database MySQL tramite la replica](MySQL.Procedural.Exporting.NonRDSRepl.md). Puoi anche chiamare `mysql.rds_start_replication` nella replica di lettura per riavviare un processo di replica arrestato in precedenza chiamando `mysql.rds_stop_replication`. Per ulteriori informazioni, consulta [Uso delle repliche di lettura dell'istanza database](USER_ReadRepl.md). ## Avvia la replica da un'istanza database RDS per MySQL e la arresta in corrispondenza della posizione del file di log binario specificato. ### Sintassi ``` CALL mysql.rds_start_replication_until ( replication_log_file , replication_stop_point ); ``` ### Parameters *replication\$1log\$1file* Il nome del log binario sull’istanza database di origine che contiene le informazioni relative alla replica. *replication\$1stop\$1point * Posizione nel log binario `replication_log_file` in corrispondenza di cui la replica verrà arrestata. ### Note per l’utilizzo La procedura `mysql.rds_start_replication_until` deve essere eseguita dall'utente master. La procedura `mysql.rds_start_replication_until` è disponibile nelle seguenti versioni di RDS for MySQL: + Tutte le versioni di RDS per MySQL 8.4 + MySQL 8.0.26 e versioni successive alla 8.0 + Tutte le versioni 5.7 Puoi usare questa procedura archiviata con la replica ritardata per il disaster recovery. Se hai configurato la replica ritardata, puoi usare questa procedura archiviata per effettuare il roll forward delle modifiche a una replica di lettura ritardata al momento immediatamente precedente a un errore. Dopo che questa procedura archiviata arresta la replica, puoi promuovere la replica di lettura come nuova istanza database primaria seguendo le istruzioni in [Promozione di una replica di lettura a istanza database standalone](USER_ReadRepl.Promote.md). Puoi configurare la replica ritardata usando le procedure archiviate seguenti: + [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) + [mysql.rds\$1set\$1external\$1master\$1with\$1delay (RDS per MariaDB e RDS per MySQL versioni principali 8.0 e precedenti)](#mysql_rds_set_external_master_with_delay) + [mysql.rds\$1set\$1external\$1source\$1with\$1delay (RDS per MySQL versioni principali 8.4 e successive)](#mysql_rds_set_external_source_with_delay) + [mysql.rds\$1set\$1source\$1delay](#mysql_rds_set_source_delay) Il nome file specificato per il parametro `replication_log_file` deve corrispondere al nome file binlog dell'istanza database di origine. Quando il parametro `replication_stop_point` specifica una posizione di arresto nel passato, la replica viene arrestata immediatamente. ### Esempi L'esempio seguente avvia la replica e replica le modifiche fino a raggiungere la posizione `120` nel file di log binario `mysql-bin-changelog.000777`. ``` call mysql.rds_start_replication_until( 'mysql-bin-changelog.000777', 120); ``` ## mysql.rds\$1stop\$1replication Arresta la replica da un'istanza database MySQL. ### Sintassi ``` CALL mysql.rds_stop_replication; ``` ### Note per l’utilizzo La procedura `mysql.rds_stop_replication` deve essere eseguita dall'utente master. Se configuri la replica per importare dati da un'istanza di MySQL in esecuzione all'esterno di Amazon RDS, puoi chiamare `mysql.rds_stop_replication` nella replica di lettura per arrestare il processo di replica al termine dell'importazione. Per ulteriori informazioni, consulta [Ripristino di un backup in un’istanza database Amazon RDS per MySQL](MySQL.Procedural.Importing.md). Se configuri la replica per esportare dati in un'istanza di MySQL esterna ad Amazon RDS, devi chiamare `mysql.rds_start_replication` e `mysql.rds_stop_replication` nella replica di lettura per controllare alcune operazioni di replica, come l'eliminazione di log binari. Per ulteriori informazioni, consulta [Esportazione di dati da un'istanza database MySQL tramite la replica](MySQL.Procedural.Exporting.NonRDSRepl.md). Puoi usare `mysql.rds_stop_replication` anche per arrestare la replica tra due istanze database Amazon RDS. In genere si arresta una replica per eseguire un'operazione di lunga durata nella replica di lettura, come la creazione di un indice di grandi dimensioni nella replica di lettura. Puoi riavviare qualsiasi processo di replica arrestato chiamando [mysql.rds\$1start\$1replication](#mysql_rds_start_replication) nella replica di lettura. Per ulteriori informazioni, consulta [Uso delle repliche di lettura dell'istanza database](USER_ReadRepl.md). # Terminare una sessione o una query Le seguenti stored procedure terminano una sessione o una query. **Topics** + [ ## mysql.rds\$1kill ](#mysql_rds_kill) + [ ## mysql.rds\$1kill\$1query ](#mysql_rds_kill_query) ## mysql.rds\$1kill Termina una connessione al server MySQL. ### Sintassi ``` CALL mysql.rds_kill(processID); ``` ### Parametri *processID* L'identità del thread di connessione da terminare. ### Note per l'utilizzo Ogni connessione al server MySQL viene eseguita in un thread distinto. Per terminare una connessione, utilizza la procedura `mysql.rds_kill` e passa l'ID di thread di quella connessione. Per ottenere l'ID di thread, utilizza il comando MySQL [SHOW PROCESSLIST](https://dev.mysql.com/doc/refman/8.0/en/show-processlist.html). Per informazioni sulle limitazioni, consulta [Limitazioni delle stored procedure di MySQL](MySQL.KnownIssuesAndLimitations.md#MySQL.Concepts.KnownIssuesAndLimitations.KillProcedures). ### Esempi L'esempio seguente termina una connessione con l'ID di thread 4243: ``` CALL mysql.rds_kill(4243); ``` ## mysql.rds\$1kill\$1query Termina una query in esecuzione sul server MySQL. ### Sintassi ``` CALL mysql.rds_kill_query(processID); ``` ### Parametri *processID* L'identità del processo o del thread che esegue la query da terminare. ### Note per l'utilizzo Per arrestare una query in esecuzione nel server MySQL, utilizza la procedura `mysql_rds_kill_query` e invia l'ID di connessione del thread che sta eseguendo la query. La procedura termina quindi la connessione. Per ottenere l'ID, esegui una query sulla [tabella INFORMATION\$1SCHEMA PROCESSLIST](https://dev.mysql.com/doc/refman/8.0/en/information-schema-processlist-table.html) MySQL o utilizza il comando MySQL [SHOW PROCESSLIST](https://dev.mysql.com/doc/refman/8.0/en/show-processlist.html). Il valore nella colonna ID da `SHOW PROCESSLIST` o `SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST` è *processID*. Per informazioni sulle limitazioni, consulta [Limitazioni delle stored procedure di MySQL](MySQL.KnownIssuesAndLimitations.md#MySQL.Concepts.KnownIssuesAndLimitations.KillProcedures). ### Esempi L'esempio seguente arresta una query con l'ID di thread di query 230040: ``` CALL mysql.rds_kill_query(230040); ``` # Gestione di cluster attivi-attivi Le stored procedure seguenti configurano e gestiscono i cluster attivi-attivi RDS per MySQL. Per ulteriori informazioni, consulta [Configurazione di cluster attivi-attivi in RDS per MySQL](mysql-active-active-clusters.md). Tali stored procedure sono disponibili solo con le istanze database RDS per MySQL che eseguono le versioni seguenti: + Tutte le versioni di MySQL 8.4 + MySQL 8.0.35 e versioni secondarie successive **Topics** + [ ## mysql.rds\$1group\$1replication\$1advance\$1gtid ](#mysql_rds_group_replication_advance_gtid) + [ ## mysql.rds\$1group\$1replication\$1create\$1user ](#mysql_rds_group_replication_create_user) + [ ## mysql.rds\$1group\$1replication\$1set\$1recovery\$1channel ](#mysql_rds_group_replication_set_recovery_channel) + [ ## mysql.rds\$1group\$1replication\$1start ](#mysql_rds_group_replication_start) + [ ## mysql.rds\$1group\$1replication\$1stop ](#mysql_rds_group_replication_stop) ## mysql.rds\$1group\$1replication\$1advance\$1gtid Crea GTID segnaposto sull’istanza database corrente. ### Sintassi ``` CALL mysql.rds_group_replication_advance_gtid( begin_id , end_id , server_uuid ); ``` ### Parametri *begin\$1id* ID della transazione iniziale da creare. *end\$1id* ID della transazione finale da creare. *begin\$1id* `group_replication_group_name` della transazione da creare. `group_replication_group_name` è specificato come UUID nel gruppo di parametri di database associato all’istanza database. ### Note per l'utilizzo In un cluster attivo-attivo, affinché un’istanza database possa unirsi a un gruppo, tutte le transazioni GTID eseguite nella nuova istanza database devono esistere negli altri membri del cluster. In casi insoliti, per una nuova istanza database potrebbero esistere più transazioni quando queste ultime sono eseguite prima di aggiungere l’istanza al gruppo. In questo caso, non è possibile rimuovere alcuna transazione esistente, ma si può utilizzare questa procedura per creare i GTID segnaposto corrispondenti nelle altre istanze database del gruppo. Prima di eseguire questa operazione, verificare che le transazioni *non influiscano sui dati replicati*. Quando si chiama questa procedura, le transazioni GTID di `server_uuid:begin_id-end_id` vengono create con contenuto vuoto. Per evitare problemi di replica, non utilizzare questa procedura in altre condizioni. **Importante** Evitare di chiamare la procedura quando il cluster attivo-attivo funziona normalmente. Non chiamare questa procedura se non si comprendono le possibili conseguenze delle transazioni in fase di creazione. Quando si chiama questa procedura, è possibile che vengano generati dati non coerenti. ### Esempio L’esempio seguente crea GTID segnaposto sull’istanza database corrente: ``` CALL mysql.rds_group_replication_advance_gtid(5, 6, '11111111-2222-3333-4444-555555555555'); ``` ## mysql.rds\$1group\$1replication\$1create\$1user Crea l’utente di replica `rdsgrprepladmin` per la replica di gruppo nell’istanza database. ### Sintassi ``` CALL mysql.rds_group_replication_create_user( replication_user_password ); ``` ### Parametri *replication\$1user\$1password* Password dell’utente di replica `rdsgrprepladmin`. ### Note per l'utilizzo + La password dell’utente di replica `rdsgrprepladmin` deve essere la stessa su tutte le istanze database di un cluster attivo-attivo. + Il nome utente `rdsgrprepladmin` è riservato per le connessioni di replica di gruppo e non può essere assegnato ad alcun altro utente, incluso l’utente master. ### Esempio L’esempio seguente crea l’utente di replica `rdsgrprepladmin` per la replica di gruppo sull’istanza database: ``` CALL mysql.rds_group_replication_create_user('password'); ``` ## mysql.rds\$1group\$1replication\$1set\$1recovery\$1channel Imposta il canale `group_replication_recovery` per un cluster attivo-attivo. La procedura utilizza l’utente `rdsgrprepladmin` riservato per configurare il canale. ### Sintassi ``` CALL mysql.rds_group_replication_set_recovery_channel( replication_user_password); ``` ### Parametri *replication\$1user\$1password* Password dell’utente di replica `rdsgrprepladmin`. ### Note per l'utilizzo La password dell’utente di replica `rdsgrprepladmin` deve essere la stessa su tutte le istanze database di un cluster attivo-attivo. Una chiamata a `mysql.rds_group_replication_create_user` specifica la password. ### Esempio L’esempio seguente imposta il canale `group_replication_recovery` per un cluster attivo-attivo: ``` CALL mysql.rds_group_replication_set_recovery_channel('password'); ``` ## mysql.rds\$1group\$1replication\$1start Avvia la replica di gruppo sull’istanza database corrente. ### Sintassi ``` CALL mysql.rds_group_replication_start( bootstrap ); ``` ### Parametri *bootstrap* Valore che specifica se inizializzare un nuovo gruppo o unirsi a un gruppo esistente. `1` inizializza un nuovo gruppo con l’istanza database corrente. `0` unisce l’istanza database corrente a un gruppo esistente connettendosi agli endpoint definiti nel parametro `group_replication_group_seeds` del gruppo di parametri di database associato all’istanza database. ### Esempio L’esempio seguente inizializza un nuovo gruppo con l’istanza database corrente: ``` CALL mysql.rds_group_replication_start(1); ``` ## mysql.rds\$1group\$1replication\$1stop Arresta la replica di gruppo sull’istanza database corrente. ### Sintassi ``` CALL mysql.rds_group_replication_stop(); ``` ### Note per l'utilizzo L’arresto di una replica su un’istanza database non influisce su alcun’altra istanza database nel cluster attivo-attivo. # Gestione della replica da più origini Le stored procedure seguenti configurano e gestiscono i canali di replica su una replica da più origini RDS per MySQL. Per ulteriori informazioni, consulta [Configurazione multi-source-replication per Amazon RDS for MySQL](mysql-multi-source-replication.md). Tali stored procedure sono disponibili solo con le istanze database RDS per MySQL che eseguono le versioni del motore seguenti: + Tutte le versioni 8.4 + 8.0.35 e versioni secondarie successive + 5.7.44 e versioni secondarie successive Quando si utilizzano queste stored procedure per gestire la replica con un utente di replica configurato con `caching_sha2_passwword`, è necessario configurare TLS specificando `SOURCE_SSL=1`. `caching_sha2_password` è il plugin di autenticazione predefinito per RDS per MySQL 8.4. **Nota** Sebbene questa documentazione faccia riferimento alle istanze database di origine, ad esempio le istanze database RDS per MySQL, queste procedure funzionano anche per le istanze MySQL eseguite esternamente ad Amazon RDS. **Topics** + [ ## mysql.rds\$1next\$1source\$1log\$1for\$1channel ](#mysql_rds_next_source_log_for_channel) + [ ## mysql.rds\$1reset\$1external\$1source\$1for\$1channel ](#mysql_rds_reset_external_source_for_channel) + [ ## mysql.rds\$1set\$1external\$1source\$1for\$1channel ](#mysql_rds_set_external_source_for_channel) + [ ## mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position\$1for\$1channel ](#mysql_rds_set_external_source_with_auto_position_for_channel) + [ ## mysql.rds\$1set\$1external\$1source\$1with\$1delay\$1for\$1channel ](#mysql_rds_set_external_source_with_delay_for_channel) + [ ## mysql.rds\$1set\$1source\$1auto\$1position\$1for\$1channel ](#mysql_rds_set_source_auto_position_for_channel) + [ ## mysql.rds\$1set\$1source\$1delay\$1for\$1channel ](#mysql_rds_set_source_delay_for_channel) + [ ## mysql.rds\$1skip\$1repl\$1error\$1for\$1channel ](#mysql_rds_skip_repl_error_for_channel) + [ ## mysql.rds\$1start\$1replication\$1for\$1channel ](#mysql_rds_start_replication_for_channel) + [ ## mysql.rds\$1start\$1replication\$1until\$1for\$1channel ](#mysql_rds_start_replication_until_for_channel) + [ ## mysql.rds\$1start\$1replication\$1until\$1gtid\$1for\$1channel ](#mysql_rds_start_replication_until_gtid_for_channel) + [ ## mysql.rds\$1stop\$1replication\$1for\$1channel ](#mysql_rds_stop_replication_for_channel) ## mysql.rds\$1next\$1source\$1log\$1for\$1channel Cambia la posizione del log dell’istanza database di origine all’inizio del successivo log binario nell’istanza database di origine per il canale. Utilizza questa procedura solo se ricevi un errore I/O di replica 1236 su una replica da più origini. ### Sintassi ``` CALL mysql.rds_next_source_log_for_channel( curr_master_log, channel_name ); ``` ### Parametri *curr\$1master\$1log* L'indice del file di log di origine corrente. Ad esempio, se il file corrente è denominato `mysql-bin-changelog.012345`, l'indice è 12345. Per determinare il nome del file di log di origine corrente, esegui il comando `SHOW REPLICA STATUS FOR CHANNEL 'channel_name'` e visualizza il campo `Source_Log_File`. *channel\$1name* Nome del canale di replica sulla replica da più origini. Ogni canale di replica riceve gli eventi del log binario da un’unica istanza database RDS per MySQL di origine in esecuzione su un host e una porta specifici. ### Note per l'utilizzo La procedura `mysql.rds_next_source_log_for_channel` deve essere eseguita dall'utente master. Se si verifica un errore IO\$1Thread, ad esempio, è possibile utilizzare questa procedura per ignorare tutti gli eventi nel file di log binario corrente e riprendere la replica dal file di log binario successivo per il canale specificato in `channel_name`. ### Esempio Supponiamo che si verifichi un errore di replica su un canale per una replica da più origini. L’esecuzione di `SHOW REPLICA STATUS FOR CHANNEL 'channel_1'\G` nella replica da più origini restituisce il risultato seguente: ``` mysql> SHOW REPLICA STATUS FOR CHANNEL 'channel_1'\G *************************** 1. row *************************** Replica_IO_State: Waiting for source to send event Source_Host: myhost.XXXXXXXXXXXXXXX.rr-rrrr-1.rds.amazonaws.com Source_User: ReplicationUser Source_Port: 3306 Connect_Retry: 60 Source_Log_File: mysql-bin-changelog.012345 Read_Source_Log_Pos: 1219393 Relay_Log_File: replica-relay-bin.000003 Relay_Log_Pos: 30223388 Relay_Source_Log_File: mysql-bin-changelog.012345 Replica_IO_Running: No Replica_SQL_Running: Yes Replicate_Do_DB:. . . Last_IO_Errno: 1236 Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Client requested master to start replication from impossible position; the first event 'mysql-bin-changelog.013406' at 1219393, the last event read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4, the last byte read from '/rdsdbdata/log/binlog/mysql-bin-changelog.012345' at 4.' Last_SQL_Errno: 0 Last_SQL_Error: . . Channel_name: channel_1 . . -- Some fields are omitted in this example output ``` Il campo `Last_IO_Errno` mostra che l'istanza riceve l'errore I/O 1236. Il campo `Source_Log_File` mostra che il nome di file è `mysql-bin-changelog.012345`, il che significa che l'indice del file di log è `12345`. Per risolvere il problema, puoi chiamare `mysql.rds_next_source_log_for_channel` con i parametri seguenti: ``` CALL mysql.rds_next_source_log_for_channel(12345,'channel_1'); ``` ## mysql.rds\$1reset\$1external\$1source\$1for\$1channel Arresta il processo di replica sul canale specificato e rimuove il canale e le configurazioni associate dalla replica da più origini. **Importante** Per eseguire questa procedura, è necessario abilitare `autocommit`. Per abilitarlo, impostare il parametro `autocommit` su `1`. Per ulteriori informazioni sulla modifica dei parametri, consulta [Modifica dei parametri in un gruppo di parametri database in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). ### Sintassi ``` CALL mysql.rds_reset_external_source_for_channel (channel_name); ``` ### Parametri *channel\$1name* Nome del canale di replica sulla replica da più origini. Ogni canale di replica riceve gli eventi del log binario da un’unica istanza database RDS per MySQL di origine in esecuzione su un host e una porta specifici. ### Note per l'utilizzo La procedura `mysql.rds_reset_external_source_for_channel` deve essere eseguita dall'utente master. Questa procedura elimina tutti i log di inoltro che appartengono al canale da rimuovere. ## mysql.rds\$1set\$1external\$1source\$1for\$1channel Configura un canale di replica su un’istanza database RDS per MySQL per replicare i dati da un’altra istanza database RDS per MySQL. **Importante** Per eseguire questa procedura, è necessario abilitare `autocommit`. Per abilitarlo, impostare il parametro `autocommit` su `1`. Per ulteriori informazioni sulla modifica dei parametri, consulta [Modifica dei parametri in un gruppo di parametri database in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). **Nota** È possibile utilizzare invece la stored procedure [mysql.rds\$1set\$1external\$1source\$1with\$1delay\$1for\$1channel](#mysql_rds_set_external_source_with_delay_for_channel) per configurare questo canale con la replica ritardata. ### Sintassi ``` CALL mysql.rds_set_external_source_for_channel ( host_name , host_port , replication_user_name , replication_user_password , mysql_binary_log_file_name , mysql_binary_log_file_location , ssl_encryption , channel_name ); ``` ### Parametri *host\$1name* Nome host o indirizzo IP dell’istanza database RDS per MySQL di origine. *host\$1port* Porta utilizzata dall’istanza database RDS per MySQL di origine. Se la configurazione della rete include la replica della porta Secure Shell (SSH) che converte il numero di porta, specifica il numero di porta esposto da SSH. *replication\$1user\$1name* ID di un utente con autorizzazioni `REPLICATION CLIENT` e `REPLICATION SLAVE` nell’istanza database RDS per MySQL di origine. Si consiglia di fornire un account utilizzato unicamente per la replica con l’istanza database di origine. *replication\$1user\$1password* La password dell'ID utente specificata in `replication_user_name`. *mysql\$1binary\$1log\$1file\$1name* Nome del log binario sull’istanza database di origine che contiene le informazioni relative alla replica. *mysql\$1binary\$1log\$1file\$1location* La posizione nel log binario `mysql_binary_log_file_name` a partire dalla quale la replica inizia a leggere le informazioni a essa relative. È possibile determinare il nome e la posizione del file binlog eseguendo `SHOW BINARY LOG STATUS` nell’istanza database di origine. Versioni precedenti di MySQL utilizzate `SHOW MASTER STATUS` al posto di `SHOW BINARY LOG STATUS`. Se si utilizza una versione MySQL precedente alla 8.4, utilizzare `SHOW MASTER STATUS`. *ssl\$1encryption* Un valore che specifica se la crittografia Secure Socket Layer (SSL) è utilizzata sulla connessione di replica. 1 indica che la crittografia SSL deve essere utilizzata; 0 specifica che la crittografia non deve essere utilizzata. Il valore predefinito è 0. L'opzione `SOURCE_SSL_VERIFY_SERVER_CERT` non è supportata. Questa opzione è impostata su 0, il che significa che la connessione è crittografata, ma i certificati non sono verificati. *channel\$1name* Nome del canale di replica. Ogni canale di replica riceve gli eventi del log binario da un’unica istanza database RDS per MySQL di origine in esecuzione su un host e una porta specifici. ### Note per l'utilizzo La procedura `mysql.rds_set_external_source_for_channel` deve essere eseguita dall'utente master. Questa procedura deve essere eseguita sull’istanza database RDS per MySQL di destinazione su cui si crea il canale di replica. Prima di eseguire `mysql.rds_set_external_source_for_channel`, configura un utente di replica sull’istanza database di origine con i privilegi richiesti per la replica da più origini. Per connettere la replica da più origini all’istanza database di origine, è necessario specificare i valori `replication_user_name` e `replication_user_password` di un utente di replica con autorizzazioni `REPLICATION CLIENT` e `REPLICATION SLAVE` nell’istanza database di origine. **Per configurare un utente di replica nell’istanza database di origine** 1. Utilizzando il client MySQL scelto, esegui la connessione all’istanza database di origine e crea un utente da utilizzare per la replica. Di seguito è riportato un esempio. **Importante** Come best practice per la sicurezza, specificare una password diversa dal valore segnaposto mostrato negli esempi seguenti. ``` CREATE USER 'repl_user'@'example.com' IDENTIFIED BY 'password'; ``` 1. Nell’istanza database di origine, concedi i privilegi `REPLICATION CLIENT` e `REPLICATION SLAVE` all’utente di replica. L'esempio seguente concede i privilegi `REPLICATION CLIENT` e `REPLICATION SLAVE` su tutti i database per l'utente "repl\$1user" del dominio: ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'example.com'; ``` Per utilizzare la replica crittografata, configura l’istanza database di origine per utilizzare le connessioni SSL. Dopo aver chiamato `mysql.rds_set_external_source_for_channel` per configurare il canale di replica, è possibile chiamare [mysql.rds\$1start\$1replication\$1for\$1channel](#mysql_rds_start_replication_for_channel) sulla replica per avviare il processo di replica sul canale. È anche possibile chiamare [mysql.rds\$1reset\$1external\$1source\$1for\$1channel](#mysql_rds_reset_external_source_for_channel) per arrestare la replica sul canale e rimuovere la configurazione del canale dalla replica. Quando si chiama `mysql.rds_set_external_source_for_channel`, Amazon RDS registra l’ora, l’utente e un’operazione di `set channel source` nella tabella `mysql.rds_history` senza dettagli specifici del canale e nella tabella `mysql.rds_replication_status` con il nome del canale. Queste informazioni vengono registrate solo per uso interno e a scopo di monitoraggio. Per registrare l’intera chiamata di procedura ai fini di audit, prendi in considerazione la possibilità di abilitare i log di audit o i log generali, in base ai requisiti specifici dell’applicazione. ### Esempi Se eseguito in un’istanza database RDS per MySQL, l’esempio seguente configura un canale di replica denominato `channel_1` sull’istanza database per replicare i dati dall’origine specificata dall’host `sourcedb.example.com` e dalla porta `3306`. ``` call mysql.rds_set_external_source_for_channel( 'sourcedb.example.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.0777', 120, 0, 'channel_1'); ``` ## mysql.rds\$1set\$1external\$1source\$1with\$1auto\$1position\$1for\$1channel Configura un canale di replica su un’istanza database RDS per MySQL con un ritardo di replica facoltativo. La replica si basa sugli ID di transazione globali (GTID). **Importante** Per eseguire questa procedura, è necessario abilitare `autocommit`. Per abilitarlo, impostare il parametro `autocommit` su `1`. Per ulteriori informazioni sulla modifica dei parametri, consulta [Modifica dei parametri in un gruppo di parametri database in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). ### Sintassi ``` CALL mysql.rds_set_external_source_with_auto_position_for_channel ( host_name , host_port , replication_user_name , replication_user_password , ssl_encryption , delay , channel_name ); ``` ### Parametri *host\$1name* Nome host o indirizzo IP dell’istanza database RDS per MySQL di origine. *host\$1port* Porta utilizzata dall’istanza database RDS per MySQL di origine. Se la configurazione della rete include la replica della porta Secure Shell (SSH) che converte il numero di porta, specifica il numero di porta esposto da SSH. *replication\$1user\$1name* ID di un utente con autorizzazioni `REPLICATION CLIENT` e `REPLICATION SLAVE` nell’istanza database RDS per MySQL di origine. Si consiglia di fornire un account utilizzato unicamente per la replica con l’istanza database di origine. *replication\$1user\$1password* La password dell'ID utente specificata in `replication_user_name`. *ssl\$1encryption* Un valore che specifica se la crittografia Secure Socket Layer (SSL) è utilizzata sulla connessione di replica. 1 indica che la crittografia SSL deve essere utilizzata; 0 specifica che la crittografia non deve essere utilizzata. Il valore predefinito è 0. L'opzione `SOURCE_SSL_VERIFY_SERVER_CERT` non è supportata. Questa opzione è impostata su 0, il che significa che la connessione è crittografata, ma i certificati non sono verificati. *delay* Numero minimo di secondi per ritardare la replica dall’istanza database di origine. Il limite per questo parametro è un giorno (86400 secondi). *channel\$1name* Nome del canale di replica. Ogni canale di replica riceve gli eventi del log binario da un’unica istanza database RDS per MySQL di origine in esecuzione su un host e una porta specifici. ### Note per l'utilizzo La procedura `mysql.rds_set_external_source_with_auto_position_for_channel` deve essere eseguita dall'utente master. Questa procedura deve essere eseguita sull’istanza database RDS per MySQL di destinazione su cui si crea il canale di replica. Prima di eseguire `rds_set_external_source_with_auto_position_for_channel`, configura un utente di replica sull’istanza database di origine con i privilegi richiesti per la replica da più origini. Per connettere la replica da più origini all’istanza database di origine, è necessario specificare i valori `replication_user_name` e `replication_user_password` di un utente di replica con autorizzazioni `REPLICATION CLIENT` e `REPLICATION SLAVE` nell’istanza database di origine. **Per configurare un utente di replica nell’istanza database di origine** 1. Utilizzando il client MySQL scelto, esegui la connessione all’istanza database di origine e crea un utente da utilizzare per la replica. Di seguito è riportato un esempio. **Importante** Come best practice per la sicurezza, specificare una password diversa dal valore segnaposto mostrato negli esempi seguenti. ``` CREATE USER 'repl_user'@'example.com' IDENTIFIED BY 'password'; ``` 1. Nell’istanza database di origine, concedi i privilegi `REPLICATION CLIENT` e `REPLICATION SLAVE` all’utente di replica. L'esempio seguente concede i privilegi `REPLICATION CLIENT` e `REPLICATION SLAVE` su tutti i database per l'utente "repl\$1user" del dominio: ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'example.com'; ``` Per utilizzare la replica crittografata, configura l’istanza database di origine per utilizzare le connessioni SSL. Prima di chiamare `mysql.rds_set_external_source_with_auto_position_for_channel`, assicurati di chiamare [mysql.rds\$1set\$1external\$1source\$1gtid\$1purged](mysql-stored-proc-replicating.md#mysql_rds_set_external_source_gtid_purged) per impostare la variabile di sistema `gtid_purged` con un intervallo di GTID specificato da un’origine esterna. Dopo aver chiamato `mysql.rds_set_external_source_with_auto_position_for_channel` per configurare un’istanza database di Amazon RDS come replica di lettura su un canale specifico, è possibile chiamare [mysql.rds\$1start\$1replication\$1for\$1channel](#mysql_rds_start_replication_for_channel) nella replica di lettura per avviare il processo di replica su tale canale. Dopo aver chiamato `mysql.rds_set_external_source_with_auto_position_for_channel` per configurare il canale di replica, è possibile chiamare [mysql.rds\$1start\$1replication\$1for\$1channel](#mysql_rds_start_replication_for_channel) sulla replica per avviare il processo di replica sul canale. È anche possibile chiamare [mysql.rds\$1reset\$1external\$1source\$1for\$1channel](#mysql_rds_reset_external_source_for_channel) per arrestare la replica sul canale e rimuovere la configurazione del canale dalla replica. ### Esempi Se eseguito in un’istanza database RDS per MySQL, l’esempio seguente configura un canale di replica `channel_1` denominato su questa istanza database per replicare i dati dall’origine specificata dall’host `sourcedb.example.com` e dalla porta `3306`. Il ritardo minimo di replica viene impostato a un’ora (3.600 secondi). Ciò significa che una modifica dall’istanza database RDS per MySQL di origine non viene applicata nella replica da più origini per almeno un’ora. ``` call mysql.rds_set_external_source_with_auto_position_for_channel( 'sourcedb.example.com', 3306, 'repl_user', 'password', 1, 3600, 'channel_1'); ``` ## mysql.rds\$1set\$1external\$1source\$1with\$1delay\$1for\$1channel Configura un canale di replica su un’istanza database RDS per MySQL con un ritardo di replica facoltativo. **Importante** Per eseguire questa procedura, è necessario abilitare `autocommit`. Per abilitarlo, impostare il parametro `autocommit` su `1`. Per ulteriori informazioni sulla modifica dei parametri, consulta [Modifica dei parametri in un gruppo di parametri database in Amazon RDS](USER_WorkingWithParamGroups.Modifying.md). ### Sintassi ``` CALL mysql.rds_set_external_source_with_delay_for_channel ( host_name , host_port , replication_user_name , replication_user_password , mysql_binary_log_file_name , mysql_binary_log_file_location , ssl_encryption , delay , channel_name ); ``` ### Parametri *host\$1name* Nome host o indirizzo IP dell’istanza database RDS per MySQL di origine. *host\$1port* Porta utilizzata dall’istanza database RDS per MySQL di origine. Se la configurazione della rete include la replica della porta Secure Shell (SSH) che converte il numero di porta, specifica il numero di porta esposto da SSH. *replication\$1user\$1name* ID di un utente con autorizzazioni `REPLICATION CLIENT` e `REPLICATION SLAVE` nell’istanza database RDS per MySQL di origine. Si consiglia di fornire un account utilizzato unicamente per la replica con l’istanza database di origine. *replication\$1user\$1password* La password dell'ID utente specificata in `replication_user_name`. *mysql\$1binary\$1log\$1file\$1name* Il nome del log binario sull’istanza database di origine contiene le informazioni relative alla replica. *mysql\$1binary\$1log\$1file\$1location* Posizione nel log binario `mysql_binary_log_file_name` a partire dalla quale la replica inizierà a leggere le informazioni di replica. È possibile determinare il nome e la posizione del file binlog in esecuzione `SHOW BINARY LOG STATUS` sull'istanza del database di origine. Versioni precedenti di MySQL utilizzate `SHOW MASTER STATUS` al posto di `SHOW BINARY LOG STATUS`. Se si utilizza una versione MySQL precedente alla 8.4, utilizzare `SHOW MASTER STATUS`. *ssl\$1encryption* Un valore che specifica se la crittografia Secure Socket Layer (SSL) è utilizzata sulla connessione di replica. 1 indica che la crittografia SSL deve essere utilizzata; 0 specifica che la crittografia non deve essere utilizzata. Il valore predefinito è 0. L'opzione `SOURCE_SSL_VERIFY_SERVER_CERT` non è supportata. Questa opzione è impostata su 0, il che significa che la connessione è crittografata, ma i certificati non sono verificati. *delay* Numero minimo di secondi per ritardare la replica dall’istanza database di origine. Il limite per questo parametro è un giorno (86400 secondi). *channel\$1name* Nome del canale di replica. Ogni canale di replica riceve gli eventi del log binario da un’unica istanza database RDS per MySQL di origine in esecuzione su un host e una porta specifici. ### Note per l'utilizzo La procedura `mysql.rds_set_external_source_with_delay_for_channel` deve essere eseguita dall'utente master. Questa procedura deve essere eseguita sull’istanza database RDS per MySQL di destinazione su cui si crea il canale di replica. Prima di eseguire `mysql.rds_set_external_source_with_delay_for_channel`, configura un utente di replica sull’istanza database di origine con i privilegi richiesti per la replica da più origini. Per connettere la replica da più origini all’istanza database di origine, è necessario specificare i valori `replication_user_name` e `replication_user_password` di un utente di replica con autorizzazioni `REPLICATION CLIENT` e `REPLICATION SLAVE` nell’istanza database di origine. **Per configurare un utente di replica nell’istanza database di origine** 1. Utilizzando il client MySQL scelto, esegui la connessione all’istanza database di origine e crea un utente da utilizzare per la replica. Di seguito è riportato un esempio. **Importante** Come best practice per la sicurezza, specificare una password diversa dal valore segnaposto mostrato negli esempi seguenti. ``` CREATE USER 'repl_user'@'example.com' IDENTIFIED BY 'password'; ``` 1. Nell’istanza database di origine, concedi i privilegi `REPLICATION CLIENT` e `REPLICATION SLAVE` all’utente di replica. L'esempio seguente concede i privilegi `REPLICATION CLIENT` e `REPLICATION SLAVE` su tutti i database per l'utente "repl\$1user" del dominio: ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'example.com'; ``` Per utilizzare la replica crittografata, configura l’istanza database di origine per utilizzare le connessioni SSL. Dopo aver chiamato `mysql.rds_set_external_source_with_delay_for_channel` per configurare il canale di replica, è possibile chiamare [mysql.rds\$1start\$1replication\$1for\$1channel](#mysql_rds_start_replication_for_channel) sulla replica per avviare il processo di replica sul canale. È anche possibile chiamare [mysql.rds\$1reset\$1external\$1source\$1for\$1channel](#mysql_rds_reset_external_source_for_channel) per arrestare la replica sul canale e rimuovere la configurazione del canale dalla replica. Quando si chiama `mysql.rds_set_external_source_with_delay_for_channel`, Amazon RDS registra l’ora, l’utente e un’operazione di `set channel source` nella tabella `mysql.rds_history` senza dettagli specifici del canale e nella tabella `mysql.rds_replication_status` con il nome del canale. Queste informazioni vengono registrate solo per uso interno e a scopo di monitoraggio. Per registrare l’intera chiamata di procedura ai fini di audit, prendi in considerazione la possibilità di abilitare i log di audit o i log generali, in base ai requisiti specifici dell’applicazione. ### Esempi Se eseguito in un’istanza database RDS per MySQL, l’esempio seguente configura un canale di replica `channel_1` denominato su questa istanza database per replicare i dati dall’origine specificata dall’host `sourcedb.example.com` e dalla porta `3306`. Il ritardo minimo di replica viene impostato a un’ora (3.600 secondi). Ciò significa che una modifica dall’istanza database RDS per MySQL di origine non viene applicata nella replica da più origini per almeno un’ora. ``` call mysql.rds_set_external_source_with_delay_for_channel( 'sourcedb.example.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.000777', 120, 1, 3600, 'channel_1'); ``` ## mysql.rds\$1set\$1source\$1auto\$1position\$1for\$1channel Imposta la modalità di replica in modo che sia basata sulle posizioni dei file di log binario o sugli ID di transazione globali (GTID). ### Sintassi ``` CALL mysql.rds_set_source_auto_position_for_channel ( auto_position_mode , channel_name ); ``` ### Parametri *auto\$1position\$1mode* Valore che indica se usare la replica basata sulla posizione del file di log o la replica basata su GTID: + `0` – Usa il metodo di replica basato sulla posizione del file di log binario. Il valore di default è `0`. + `1` – Usa il metodo di replica basato su GTID. *channel\$1name* Nome del canale di replica sulla replica da più origini. Ogni canale di replica riceve gli eventi del log binario da un’unica istanza database RDS per MySQL di origine in esecuzione su un host e una porta specifici. ### Note per l'utilizzo La procedura `mysql.rds_set_source_auto_position_for_channel` deve essere eseguita dall'utente master. Questa procedura riavvia la replica sul canale specificato per applicare la modalità di posizionamento automatico specificata. ### Esempi L’esempio seguente imposta la modalità di posizionamento automatico per channel\$11 per utilizzare il metodo di replica basato su GTID. ``` call mysql.rds_set_source_auto_position_for_channel(1,'channel_1'); ``` ## mysql.rds\$1set\$1source\$1delay\$1for\$1channel Imposta il numero minimo di secondi per ritardare la replica dall’istanza database di origine alla replica da più origini per il canale specificato. ### Sintassi ``` CALL mysql.rds_set_source_delay_for_channel(delay, channel_name); ``` ### Parametri *delay* Numero minimo di secondi per ritardare la replica dall’istanza database di origine. Il limite per questo parametro è un giorno (86400 secondi). *channel\$1name* Nome del canale di replica sulla replica da più origini. Ogni canale di replica riceve gli eventi del log binario da un’unica istanza database RDS per MySQL di origine in esecuzione su un host e una porta specifici. ### Note per l'utilizzo La procedura `mysql.rds_set_source_delay_for_channel` deve essere eseguita dall'utente master. Per utilizzare questa procedura, chiama prima `mysql.rds_stop_replication_for_channel` per arrestare la replica, quindi chiama la procedura per impostare il valore del ritardo di replica. Quando il ritardo è impostato, chiama `mysql.rds_start_replication_for_channel` per riavviare la replica. ### Esempi L’esempio seguente imposta il ritardo per la replica dall’istanza database di origine su `channel_1` della replica da più origini per almeno un’ora (3.600 secondi). ``` CALL mysql.rds_set_source_delay_for_channel(3600,'channel_1'); ``` ## mysql.rds\$1skip\$1repl\$1error\$1for\$1channel Ignora un evento del log binario ed elimina un errore di replica su una replica database MySQL da più origini per il canale specificato. ### Sintassi ``` CALL mysql.rds_skip_repl_error_for_channel(channel_name); ``` ### Parametri *channel\$1name* Nome del canale di replica sulla replica da più origini. Ogni canale di replica riceve gli eventi del log binario da un’unica istanza database RDS per MySQL di origine in esecuzione su un host e una porta specifici. ### Note per l'utilizzo La procedura `mysql.rds_skip_repl_error_for_channel` deve essere eseguita dall'utente master su una replica di lettura. È possibile utilizzare questa procedura in modo analogo a come si utilizza `mysql.rds_skip_repl_error` per evitare un errore in una replica di lettura. Per ulteriori informazioni, consulta [Chiamata della procedura mysql.rds\$1skip\$1repl\$1error](Appendix.MySQL.CommonDBATasks.SkipError.md#Appendix.MySQL.CommonDBATasks.SkipError.procedure). **Nota** Per evitare errori nella replica basata su GTID, si consiglia di utilizzare invece la procedura [](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid). Per determinare se ci sono errori, esegui il comando MySQL `SHOW REPLICA STATUS FOR CHANNEL 'channel_name'\G`. Se un errore di replica non è critico, puoi eseguire `mysql.rds_skip_repl_error_for_channel` per ignorare l'errore. Se sono presenti più errori, `mysql.rds_skip_repl_error_for_channel` elimina il primo sul canale di replica specificato, quindi informa della presenza di altri errori. Puoi quindi utilizzare `SHOW REPLICA STATUS FOR CHANNEL 'channel_name'\G` per determinare l'operazione corretta per l'errore successivo. Per informazioni sui valori restituiti, consulta [Istruzione SHOW REPLICA STATUS](https://dev.mysql.com/doc/refman/8.0/en/show-replica-status.html) nella documentazione di MySQL. ## mysql.rds\$1start\$1replication\$1for\$1channel Avvia la replica da un’istanza database RDS per MySQL a una replica da più origini sul canale specificato. **Nota** Puoi usare la stored procedure [mysql.rds\$1start\$1replication\$1until\$1for\$1channel](#mysql_rds_start_replication_until_for_channel) o [mysql.rds\$1start\$1replication\$1until\$1gtid\$1for\$1channel](#mysql_rds_start_replication_until_gtid_for_channel) per avviare la replica da un'istanza database RDS for MySQL e arrestare la replica in corrispondenza della posizione del file di log binario specificato. ### Sintassi ``` CALL mysql.rds_start_replication_for_channel(channel_name); ``` ### Parametri *channel\$1name* Nome del canale di replica sulla replica da più origini. Ogni canale di replica riceve gli eventi del log binario da un’unica istanza database RDS per MySQL di origine in esecuzione su un host e una porta specifici. ### Note per l'utilizzo La procedura `mysql.rds_start_replication_for_channel` deve essere eseguita dall'utente master. Dopo aver importato i dati dall’istanza database RDS per MySQL di origine, esegui questo comando sulla replica da più origini per avviare la replica sul canale specificato. ### Esempi L’esempio seguente avvia la replica su `channel_1` della replica da più origini. ``` CALL mysql.rds_start_replication_for_channel('channel_1'); ``` ## mysql.rds\$1start\$1replication\$1until\$1for\$1channel Avvia la replica da un’istanza database RDS per MySQL sul canale specificato e la arresta in corrispondenza della posizione del file di log binario specificato. ### Sintassi ``` CALL mysql.rds_start_replication_until_for_channel ( replication_log_file , replication_stop_point , channel_name ); ``` ### Parametri *replication\$1log\$1file* Il nome del log binario sull’istanza database di origine contiene le informazioni relative alla replica. *replication\$1stop\$1point * Posizione nel log binario `replication_log_file` in corrispondenza di cui la replica verrà arrestata. *channel\$1name* Nome del canale di replica sulla replica da più origini. Ogni canale di replica riceve gli eventi del log binario da un’unica istanza database RDS per MySQL di origine in esecuzione su un host e una porta specifici. ### Note per l'utilizzo La procedura `mysql.rds_start_replication_until_for_channel` deve essere eseguita dall'utente master. Con questa procedura, la replica viene avviata e successivamente arrestata quando viene raggiunta la posizione del file binlog specificata. La procedura arresta sia `SQL_THREAD` sia `IO_THREAD`. Il nome di file specificato per il parametro `replication_log_file` deve corrispondere al nome del file binlog dell’istanza database di origine. Quando il parametro `replication_stop_point` specifica una posizione di arresto nel passato, la replica viene arrestata immediatamente. ### Esempi L’esempio seguente avvia la replica su `channel_1` e replica le modifiche fino a quando non raggiunge la posizione `120` nel file di log binario `mysql-bin-changelog.000777`. ``` call mysql.rds_start_replication_until_for_channel( 'mysql-bin-changelog.000777', 120, 'channel_1' ); ``` ## mysql.rds\$1start\$1replication\$1until\$1gtid\$1for\$1channel Avvia la replica da un’istanza database RDS per MySQL e la arresta in corrispondenza dell’ID di transazione globale (GTID) specificato. ### Sintassi ``` CALL mysql.rds_start_replication_until_gtid_for_channel(gtid,channel_name); ``` ### Parametri *gtid* GTID dopo il quale arrestare la replica. *channel\$1name* Nome del canale di replica sulla replica da più origini. Ogni canale di replica riceve gli eventi del log binario da un’unica istanza database RDS per MySQL di origine in esecuzione su un host e una porta specifici. ### Note per l'utilizzo La procedura `mysql.rds_start_replication_until_gtid_for_channel` deve essere eseguita dall'utente master. La procedura avvia la replica sul canale specificato, applica tutte le modifiche fino al valore GTID specificato, quindi arresta la replica sul canale. Quando il parametro `gtid` specifica una transazione che è già stata eseguita dalla replica, la procedura viene arrestata immediatamente. Prima di eseguire la procedure, è necessario disabilitare la replica multi-thread impostando il valore di `replica_parallel_workers` o `slave_parallel_workers` su `0`. ### Esempi L’esempio seguente avvia la replica su `channel_1` e replica le modifiche fino a quando non raggiunge il GTID `3E11FA47-71CA-11E1-9E33-C80AA9429562:23`. ``` call mysql.rds_start_replication_until_gtid_for_channel('3E11FA47-71CA-11E1-9E33-C80AA9429562:23','channel_1'); ``` ## mysql.rds\$1stop\$1replication\$1for\$1channel Arresta la replica da un’istanza database MySQL sul canale specificato. ### Sintassi ``` CALL mysql.rds_stop_replication_for_channel(channel_name); ``` ### Parametri *channel\$1name* Nome del canale di replica sulla replica da più origini. Ogni canale di replica riceve gli eventi del log binario da un’unica istanza database RDS per MySQL di origine in esecuzione su un host e una porta specifici. ### Note per l'utilizzo La procedura `mysql.rds_stop_replication_for_channel` deve essere eseguita dall'utente master. ### Esempi L’esempio seguente arresta la replica su `channel_1` della replica da più origini. ``` CALL mysql.rds_stop_replication_for_channel('channel_1'); ``` # Replica delle transazioni utilizzando GTIDs Le seguenti stored procedure controllano il modo in cui le transazioni vengono replicate utilizzando gli identificatori di transazione globali (GTIDs) con RDS for MySQL. Per ulteriori informazioni sulla replica basata su GTIDs RDS for MySQL, vedere. [Utilizzo della replica basata su GTID](mysql-replication-gtid.md) Quando si utilizzano queste stored procedure per gestire la replica con un utente di replica configurato con `caching_sha2_password`, è necessario configurare TLS specificando `SOURCE_SSL=1`. `caching_sha2_password` è il plugin di autenticazione predefinito per RDS per MySQL 8.4. **Topics** + [ ## ](#mysql_rds_skip_transaction_with_gtid) + [ ## ](#mysql_rds_start_replication_until_gtid) ## Ignora la replica di una transazione con l'ID globale di transazione (GTID) specificato in un'istanza database MySQL. Puoi usare questa procedura per il ripristino di emergenza quando è noto che una specifica transazione GTID causa un problema. Usa questa stored procedure per saltare la transazione problematica. Esempi di transazioni problematiche includono le transazioni che disabilitano la replica, eliminano dati importanti o con le quali l'istanza database diventa non disponibile. ### Sintassi ``` CALL mysql.rds_skip_transaction_with_gtid ( gtid_to_skip ); ``` ### Parameters *gtid\$1to\$1skip* GTID della transazione di replica da ignorare. ### Note per l'utilizzo La procedura `mysql.rds_skip_transaction_with_gtid` deve essere eseguita dall’utente master. Questa procedura è supportata per tutte le versioni di RDS per MySQL 5.7, per tutte le versioni di RDS per MySQL 8.0 e per tutte le versioni di RDS per MySQL 8.4. ### Esempi Nell'esempio seguente viene ignorata la replica della transazione con il GTID `3E11FA47-71CA-11E1-9E33-C80AA9429562:23`. ``` CALL mysql.rds_skip_transaction_with_gtid('3E11FA47-71CA-11E1-9E33-C80AA9429562:23'); ``` ## Avvia la replica da un'istanza database RDS per MySQL e la arresta immediatamente dopo l'ID globale di transazione (GTID) specificato. ### Sintassi ``` CALL mysql.rds_start_replication_until_gtid(gtid); ``` ### Parameters *gtid* Il GTID dopo il quale deve essere arrestata la replica. ### Note per l'utilizzo La procedura `mysql.rds_start_replication_until_gtid` deve essere eseguita dall’utente master. Questa procedura è supportata per tutte le versioni di RDS per MySQL 5.7, per tutte le versioni di RDS per MySQL 8.0 e per tutte le versioni di RDS per MySQL 8.4. Puoi usare questa procedura archiviata con la replica ritardata per il disaster recovery. Se hai configurato la replica ritardata, puoi usare questa procedura archiviata per effettuare il roll forward delle modifiche a una replica di lettura ritardata al momento immediatamente precedente a un errore. Dopo che questa procedura archiviata arresta la replica, puoi promuovere la replica di lettura come nuova istanza database primaria seguendo le istruzioni in [Promozione di una replica di lettura a istanza database standalone](USER_ReadRepl.Promote.md). Puoi configurare la replica ritardata usando le procedure archiviate seguenti: + [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) + [mysql.rds\$1set\$1external\$1master\$1with\$1delay (RDS per MariaDB e RDS per MySQL versioni principali 8.0 e precedenti)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master_with_delay) + [mysql.rds\$1set\$1external\$1source\$1with\$1delay (RDS per MySQL versioni principali 8.4 e successive)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source_with_delay) + [mysql.rds\$1set\$1source\$1delay](mysql-stored-proc-replicating.md#mysql_rds_set_source_delay) Quando il parametro `gtid` specifica una transazione che è già stata eseguita dalla replica, la procedura viene arrestata immediatamente. ### Esempi L'esempio seguente avvia la replica e replica le modifiche finché non raggiunge il GTID `3E11FA47-71CA-11E1-9E33-C80AA9429562:23`. ``` call mysql.rds_start_replication_until_gtid('3E11FA47-71CA-11E1-9E33-C80AA9429562:23'); ``` # Rotazione dei log di query Le seguenti stored procedure ruotano i log MySQL nelle tabelle di backup. Per ulteriori informazioni, consulta [File di registro del database ](USER_LogAccess.Concepts.MySQL.md). **Topics** + [ ## mysql.rds\$1rotate\$1general\$1log ](#mysql_rds_rotate_general_log) + [ ## mysql.rds\$1rotate\$1slow\$1log ](#mysql_rds_rotate_slow_log) ## mysql.rds\$1rotate\$1general\$1log Converte la tabella `mysql.general_log` in una tabella di backup. ### Sintassi ``` CALL mysql.rds_rotate_general_log; ``` ### Note per l'utilizzo Puoi convertire la tabella `mysql.general_log` in una tabella di backup chiamando la procedura `mysql.rds_rotate_general_log`. Quando le tabelle di log sono convertite, la tabella di log corrente è copiata in una tabella di logo di backup e le voci nella tabella di log corrente sono eliminate. Se una tabella di log di backup esiste, viene eliminata prima che la tabella di log corrente sia copiata nel backup. Puoi eseguire una query sulla tabella di log di backup, se necessario. La tabella di log di backup per la tabella `mysql.general_log` è denominata `mysql.general_log_backup`. È possibile eseguire questa procedura solo quando il parametro `log_output` è impostato su `TABLE`. ## mysql.rds\$1rotate\$1slow\$1log Converte la tabella `mysql.slow_log` in una tabella di backup. ### Sintassi ``` CALL mysql.rds_rotate_slow_log; ``` ### Note per l'utilizzo Puoi convertire la tabella `mysql.slow_log` in una tabella di backup chiamando la procedura `mysql.rds_rotate_slow_log`. Quando le tabelle di log sono convertite, la tabella di log corrente è copiata in una tabella di logo di backup e le voci nella tabella di log corrente sono eliminate. Se una tabella di log di backup esiste, viene eliminata prima che la tabella di log corrente sia copiata nel backup. Puoi eseguire una query sulla tabella di log di backup, se necessario. La tabella di log di backup per la tabella `mysql.slow_log` è denominata `mysql.slow_log_backup`. # Impostazione e visualizzazione della configurazione dei log binari Le seguenti stored procedure impostano e mostrano i parametri di configurazione, ad esempio per la conservazione dei file di log binari. **Topics** + [ ## mysql.rds\$1set\$1configuration ](#mysql_rds_set_configuration) + [ ## mysql.rds\$1show\$1configuration ](#mysql_rds_show_configuration) ## mysql.rds\$1set\$1configuration Specifica il numero di ore di conservazione dei log binari o il numero di secondi di ritardo della replica. ### Sintassi ``` CALL mysql.rds_set_configuration(name,value); ``` ### Parameters *name* Il nome del parametro di configurazione da impostare. *value* Il valore del parametro di configurazione. ### Note per l'utilizzo la procedura archiviata `mysql.rds_set_configuration` supporta i parametri di configurazione seguenti: + [binlog retention hours](#mysql_rds_set_configuration-usage-notes.binlog-retention-hours) + [Ritardo dell'origine](#mysql_rds_set_configuration-usage-notes.source-delay) + [target delay](#mysql_rds_set_configuration-usage-notes.target-delay) I parametri di configurazione vengono archiviati in modo permanente e restano effettivi dopo qualsiasi riavvio o failover dell'istanza database. #### binlog retention hours Il parametro `binlog retention hours` viene utilizzato per specificare il numero di ore di conservazione dei file di log binari. Amazon RDS elimina in genere un log binario non appena possibile, tuttavia il log potrebbe continuare a essere necessario per la replica con un database MySQL esterno a RDS. Il valore predefinito di `binlog retention hours` è `NULL`. Per RDS per MySQL, `NULL` significa che i log binari non vengono mantenuti (0 ore). Per specificare il numero di ore per mantenere i log binari in un'istanza, usa la stored procedure `mysql.rds_set_configuration` e specifica un periodo con tempo sufficiente per l'esecuzione della replica, come mostrato nell'esempio seguente. `call mysql.rds_set_configuration('binlog retention hours', 24);` **Nota** Non puoi utilizzare il valore `0` per `binlog retention hours`. Per le istanze database MySQL, il valore `binlog retention hours` massimo è 168 (7 giorni). Dopo l'impostazione del periodo di retention, monitora l'utilizzo dello storage per l'istanza database per verificare che i log binari conservati non occupino troppo spazio di storage. Per le implementazioni di cluster di database Multi-AZ, è possibile configurare la conservazione dei log binari solo dall’istanza database di scrittura e l’impostazione viene propagata a tutte le istanze database di lettura in modo asincrono. Se i log binari nel cluster di database superano la metà dello spazio di archiviazione locale totale, Amazon RDS sposta automaticamente i log obsoleti nel volume EBS. I log più recenti, tuttavia, rimangono nell’archiviazione locale, quindi sono soggetti a perdita se si verifica un errore che richieda la sostituzione dell’host o se si aumenta o si riduce verticalmente il database. #### Ritardo dell'origine Usa il parametro `source delay` in una replica di lettura per specificare il numero di secondi per cui ritardare la replica di lettura rispetto all'istanza database di origine. Amazon RDS in genere replica le modifiche non appena possibile, ma in alcuni ambienti è possibile che la replica venga ritardata. Ritardando la replica, ad esempio, è possibile effettuare il roll forward di una replica di lettura ritardata al momento immediatamente precedente a un errore. Se una tabella viene eliminata accidentalmente, puoi usare la replica ritardata per recuperarla rapidamente. Il valore predefinito di `target delay` è `0` (la replica non viene ritardata). Quando utilizzato, questo parametro esegue [mysql.rds\$1set\$1source\$1delay](mysql-stored-proc-replicating.md#mysql_rds_set_source_delay) e applica CHANGE primary TO MASTER\$1DELAY = valore di input. In caso di esito positivo, la procedura salva il parametro `source delay` nella tabella `mysql.rds_configuration`. Per specificare il numero di secondi per cui Amazon RDS deve ritardare la replica in un'istanza database di origine, usa la stored procedure `mysql.rds_set_configuration` e specifica il numero di secondi per il ritardo della replica. Nell'esempio seguente la replica viene ritardata di almeno un'ora (3600 secondi). `call mysql.rds_set_configuration('source delay', 3600);` La procedura quindi esegue `mysql.rds_set_source_delay(3600)`. Il limite per il parametro `source delay` è un giorno (86400 secondi). #### target delay Usa il parametro `target delay` per specificare il numero di secondi per cui ritardare la replica tra un'istanza database e le repliche di lettura future gestite da RDS create dall'istanza. Questo parametro viene ignorato per le repliche di non-RDS-managed lettura. Amazon RDS in genere replica le modifiche non appena possibile, ma in alcuni ambienti è possibile che la replica venga ritardata. Ritardando la replica, ad esempio, è possibile effettuare il roll forward di una replica di lettura ritardata al momento immediatamente precedente a un errore. Se una tabella viene eliminata accidentalmente, puoi usare la replica ritardata per recuperarla rapidamente. Il valore predefinito di `target delay` è `0` (la replica non viene ritardata). Per il disaster recovery puoi usare questo parametro di configurazione con la stored procedure [](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until) o [](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid). Per effettuare il roll forward delle modifiche a una replica di lettura ritardata al momento immediatamente precedente a un errore, puoi eseguire la procedura `mysql.rds_set_configuration` con questo parametro impostato. Dopo che la procedura `mysql.rds_start_replication_until` o `mysql.rds_start_replication_until_gtid` arresta la replica, puoi promuovere la replica di lettura come nuova istanza database master seguendo le istruzioni in [Promozione di una replica di lettura a istanza database standalone](USER_ReadRepl.Promote.md). Per usare la procedura `mysql.rds_rds_start_replication_until_gtid`, è necessario che sia abilitata la replica basata su GTID. Per passare a una specifica transazione basata su GTID che notoriamente causa un problema, puoi usare la stored procedure [](mysql-stored-proc-gtid.md#mysql_rds_skip_transaction_with_gtid). Per ulteriori informazioni sull'utilizzo della replica basata su GTID, consulta [Utilizzo della replica basata su GTID](mysql-replication-gtid.md). Per specificare il numero di secondi per cui Amazon RDS deve ritardare la replica in una replica di lettura, usa la stored procedure `mysql.rds_set_configuration` e specifica il numero di secondi per il ritardo della replica. L'esempio seguente specifica che la replica viene ritardata di almeno un'ora (3600 secondi). `call mysql.rds_set_configuration('target delay', 3600);` Il limite per il parametro `target delay` è un giorno (86400 secondi). ## mysql.rds\$1show\$1configuration Il numero di ore di retention dei log binari. ### Sintassi ``` CALL mysql.rds_show_configuration; ``` ### Note per l'utilizzo Per verificare il numero di ore per cui Amazon RDS deve conservare i log binari, usa la stored procedure `mysql.rds_show_configuration`. ### Esempi L'esempio seguente visualizza il periodo di retention: ``` call mysql.rds_show_configuration; name value description binlog retention hours 24 binlog retention hours specifies the duration in hours before binary logs are automatically deleted. ``` # Precaricamento della cache di InnoDB Le seguenti stored procedure salvano, caricano o annullano il caricamento del pool di buffer di InnoDB nelle istanze database RDS per MySQL. Per ulteriori informazioni, consulta [Precaricamento della cache InnoDB per MySQL su Amazon RDS](MySQL.Concepts.FeatureSupport.md#MySQL.Concepts.InnoDBCacheWarming). **Topics** + [ ## mysql.rds\$1innodb\$1buffer\$1pool\$1dump\$1now ](#mysql_rds_innodb_buffer_pool_dump_now) + [ ## mysql.rds\$1innodb\$1buffer\$1pool\$1load\$1abort ](#mysql_rds_innodb_buffer_pool_load_abort) + [ ## mysql.rds\$1innodb\$1buffer\$1pool\$1load\$1now ](#mysql_rds_innodb_buffer_pool_load_now) ## mysql.rds\$1innodb\$1buffer\$1pool\$1dump\$1now Esegue il dump dello stato corrente del pool di buffer sul disco. ### Sintassi ``` CALL mysql.rds_innodb_buffer_pool_dump_now(); ``` ### Note per l'utilizzo La procedura `mysql.rds_innodb_buffer_pool_dump_now` deve essere eseguita dall'utente master. ## mysql.rds\$1innodb\$1buffer\$1pool\$1load\$1abort Annulla un caricamento in corso dello stato del pool di buffer salvato. ### Sintassi ``` CALL mysql.rds_innodb_buffer_pool_load_abort(); ``` ### Note per l'utilizzo La procedura `mysql.rds_innodb_buffer_pool_load_abort` deve essere eseguita dall'utente master. ## mysql.rds\$1innodb\$1buffer\$1pool\$1load\$1now Carica lo stato salvato del pool di buffer dal disco. ### Sintassi ``` CALL mysql.rds_innodb_buffer_pool_load_now(); ``` ### Note per l'utilizzo La procedura `mysql.rds_innodb_buffer_pool_load_now` deve essere eseguita dall'utente master.