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à.

Best practice per Amazon RDS

Scopri le best practice per l'utilizzo di Amazon RDS. Man mano che vengono identificate nuove best practice, aggiorneremo questa sezione.

Linee guida operative di base per Amazon RDS

Di seguito sono illustrate le linee guida operative di base e le best practice che tutti dovrebbero seguire durante l'utilizzo di Amazon RDS. Tieni presente che il contratto sul livello di servizio di Amazon RDS richiede che tu segua queste linee guida:

Suggerimenti relativi alla RAM per un'istanza di database

Una best practice per le prestazioni di Amazon RDS consiste nell'allocare RAM sufficiente in modo che il working set risieda quasi interamente nella memoria. Il working set è formato dai dati e dagli indici che vengono utilizzati spesso nell'istanza. Più utilizzi l'istanza DB, più il working set crescerà.

Per sapere se il tuo set di lavoro è quasi tutto in memoria, controlla la metrica ReadiOps (usando CloudWatch Amazon) mentre l'istanza DB è sotto carico. Il valore ReadIOPS dovrebbe essere di piccola entità e stabile. In alcuni casi, il passaggio della classe di istanza database a una classe con più RAM provoca un drastico calo di ReadIOPS. In questi casi, il set di lavoro non è completamente in memoria. Continua con l'incremento fino a quando il valore di ReadIOPS non diminuisce più drasticamente dopo un'operazione di dimensionamento o è di entità molto piccola. Per ulteriori informazioni sul monitoraggio dei parametri di un'istanza di database, consulta Visualizzazione dei parametri nella console Amazon RDS.

AWS driver di database

Consigliamo la AWS suite di driver per la connettività delle applicazioni. I driver sono stati progettati per fornire supporto per tempi di switchover e failover più rapidi e per l'autenticazione con AWS Secrets Manager, AWS Identity and Access Management (IAM) e Federated Identity. I AWS driver si basano sul monitoraggio dello stato dell'istanza DB e sulla conoscenza della topologia dell'istanza per determinare il nuovo writer. Questo approccio riduce i tempi di switchover e failover a secondi a una cifra, rispetto alle decine di secondi dei driver open source.

Con l'introduzione di nuove funzionalità di servizio, l'obiettivo della AWS suite di driver è disporre di un supporto integrato per queste funzionalità di servizio.

Per ulteriori informazioni, consulta Connessione alle istanze DB con i driver AWS.

Utilizzo del monitoraggio avanzato per identificare problemi del sistema operativo

Quando il monitoraggio avanzato è abilitato, Amazon RDS fornisce parametri in tempo reale per il sistema operativo (OS) su cui viene eseguita l'istanza database. È possibile visualizzare le metriche per l'istanza DB utilizzando la console. Puoi anche utilizzare l'output JSON di Enhanced Monitoring di Amazon CloudWatch Logs in un sistema di monitoraggio a tua scelta. Per ulteriori informazioni su Enhanced Monitoring, consult Monitoraggio dei parametri del sistema operativo con il monitoraggio avanzato.

Utilizzo di parametri per identificare problemi a livello di prestazioni

Per identificare problemi a livello di prestazioni causati da risorse insufficienti e altri colli di bottiglia comuni, puoi monitorare i parametri disponibili per l'istanza di database Amazon RDS.

Visualizzazione dei parametri relativi alle prestazioni

Dovresti monitorare regolarmente i parametri relativi alle prestazione per osservare i valori medi, massimi e minimi per vari intervalli di tempo. Ciò ti consente di identificare quando le prestazioni subiscono un calo. Puoi anche impostare CloudWatch allarmi Amazon per determinate soglie metriche in modo da essere avvisato se vengono raggiunte.

Per risolvere i problemi relativi alle prestazioni, è importante comprendere le prestazioni di base del sistema. Quando configuri un'istanza database e la esegui con un carico di lavoro tipico, acquisisci i valori medi, massimi e minimi di tutte le metriche delle prestazioni. Puoi farlo a diversi intervalli (ad esempio, un'ora, 24 ore, una settimana, due settimane) e ti permette di avere un quadro dei valori normali. Ciò aiuta anche a effettuare confronti delle attività durante le ore di punta e non di punta. Puoi quindi utilizzare queste informazioni per identificare quando le prestazioni scendono al di sotto dei livelli standard.

Se utilizzi cluster database multi-AZ, puoi monitorare la differenza di tempo tra l'ultima transazione sull'istanza database di scrittura e l'ultima transazione applicata su un'istanza database di lettura. Questa differenza è chiamata ritardo di replica. Per ulteriori informazioni, consulta Ritardo di replica e cluster di database Multi-AZ.

Puoi visualizzare la combinazione di Performance Insights e CloudWatch metriche nella dashboard di Performance Insights e monitorare la tua istanza DB. Per utilizzare questa visualizzazione di monitoraggio, Performance Insights deve essere attivato per l'istanza database specifica. Per ulteriori informazioni su questa visualizzazione di monitoraggio, consulta Visualizzazione delle metriche combinate nella console Amazon RDS.

È possibile creare un report di analisi delle prestazioni per un periodo di tempo specifico e visualizzare le informazioni dettagliate identificate e i suggerimenti per risolvere i problemi. Per ulteriori informazioni, consulta Creazione di un report di analisi delle prestazioni.

È possibile anche visualizzare i parametri relativi alle prestazioni mediante CLI o API. Per ulteriori informazioni, consulta Visualizzazione dei parametri nella console Amazon RDS.

L'allarme appare nella sezione CloudWatch Allarmi.

Valutazione dei parametri relativi alle prestazioni

Un'istanza di database include diverse categorie di parametri e il modo in cui stabilire valori accettabili dipende dal parametro.

Per descrizioni individuali più dettagliate dei parametri disponibili relativi alle prestazioni, consultare Monitoraggio dei parametri di Amazon RDS con Amazon CloudWatch.

In generale, i valori accettabili per i parametri relativi alle prestazioni dipendono dalla baseline e dall'attività dell'applicazione. Indagare le variazioni della baseline coerenti o che rappresentano dei trend. I seguenti sono alcuni suggerimenti su tipi di parametri specifici:

In caso di problemi relativi alle metriche delle prestazioni, puoi ottimizzare le query più utilizzate e più costose per migliorare le prestazioni. Ottimizzale per vedere se così facendo riduci la pressione sulle risorse di sistema. Per ulteriori informazioni, consulta Ottimizzazione di query.

Se le query sono state ottimizzate e il problema persiste, valuta la possibilità di eseguire l'upgrade delle Classi di istanze database Amazon RDS. Puoi passare a una classe con una quantità maggiore della risorsa correlata al problema (CPU, RAM, spazio su disco, larghezza di banda della rete, capacità I/O).

Ottimizzazione di query

Uno dei modi migliori per migliorare le prestazioni di un'istanza database consiste nell'ottimizzare le query più comuni e a uso più intensivo di risorse. Puoi ottimizzarle per renderle meno costose da eseguire. Per informazioni sul miglioramento delle query, utilizzare le risorse seguenti:

Best practice per l'utilizzo di MySQL

Sia le dimensioni delle tabelle che il numero di tabelle in un database MySQL possono influire sulle prestazioni.

Dimensione della tabella

In genere, i vincoli del sistema operativo sulle dimensioni dei file determinano la dimensione massima effettiva della tabella per i database MySQL. Quindi, i limiti di solito non sono determinati dai vincoli interni MySQL.

In un'istanza di database MySQL, evita che le tabelle nel database diventino troppo grandi. Sebbene il limite di storage generale sia 64 TiB, i limiti di storage forniti limitano la dimensione massima di un file di tabella MySQL a 16 TiB. Suddividi le tabelle più grandi in file di dimensioni ben al di sotto del limite di 16 TiB. Ciò può anche migliorare le prestazioni e i tempi di recupero. Per ulteriori informazioni, consulta Limiti delle dimensioni dei file MySQL in Amazon RDS.

Le tabelle di dimensioni molto grandi (maggiori di 100 GB) possono influire negativamente sulle prestazioni di lettura e scrittura (incluse le istruzioni DML e in particolare le istruzioni DDL). Gli indici sulle tabelle di grandi dimensioni possono migliorare significativamente le prestazioni selezionate, ma possono anche ridurre le prestazioni delle istruzioni DML. Le istruzioni DDL, ad esempio ALTER TABLE, possono essere significativamente più lente per le tabelle di grandi dimensioni perché tali operazioni potrebbero ricostruire completamente una tabella in alcuni casi. Queste istruzioni DDL potrebbero bloccare le tabelle per la durata dell'operazione.

La quantità di memoria richiesta da MySQL per le letture e le scritture dipende dalle tabelle coinvolte nelle operazioni. È una best practice avere almeno abbastanza RAM per contenere gli indici delle tabelle utilizzate attivamente . Per trovare le dieci tabelle e gli indici più grandi in un database, utilizzare la seguente query:

select table_schema, TABLE_NAME, dat, idx from 
(SELECT table_schema, TABLE_NAME, 
       ( data_length ) / 1024 / 1024 as dat,
       ( index_length ) / 1024 / 1024 as idx
FROM information_schema.TABLES
order by 3 desc ) a
order by 3 desc 
limit 10;

Numero di tabelle

Il file system sottostante può avere un limite al numero di file che rappresentano le tabelle. Tuttavia, MySQL non ha limiti per il numero di tabelle. Ciononostante, il numero totale di tabelle nel motore di archiviazione MySQL InnoDB può contribuire al deterioramento delle prestazioni, indipendentemente dalle dimensioni di tali tabelle. Per limitare l'impatto del sistema operativo, è possibile dividere le tabelle tra più database nella stessa istanza database MySQL. In questo modo potrebbe limitare il numero di file in una directory, ma non risolverà il problema generale.

Quando c'è un deterioramento delle prestazioni a causa di un gran numero di tabelle (più di 10 mila), è causato da MySQL che lavora con i file di archiviazione, inclusa l'apertura e la chiusura. Per risolvere questo problema, è possibile aumentare la dimensione dei parametri table_open_cache e table_definition_cache. Tuttavia, aumentare i valori di tali parametri potrebbe aumentare significativamente la quantità di memoria utilizzata da MySQL e potrebbe persino utilizzare tutta la memoria disponibile. Per ulteriori informazioni, consulta Apertura e chiusura delle tabelle in MySQL nella documentazione di MySQL.

Inoltre, troppe tabelle possono influenzare significativamente il tempo di avvio di MySQL. Possono essere interessati sia un arresto e un riavvio pulito che un ripristino da arresto anomalo, specialmente nelle versioni precedenti a MySQL 8.0.

Ti consigliamo di avere meno di 10.000 tabelle totali in tutti i database in un'istanza database. Per un caso d'uso con un gran numero di tabelle in un database MySQL, consulta Un milione di tabelle in MySQL 8.0.

Motore di storage

Le funzionalità di point-in-time ripristino e ripristino delle istantanee di Amazon RDS for MySQL richiedono un motore di storage ripristinabile in caso di arresto anomalo. Queste funzionalità sono supportate solo per il motore di archiviazione InnoDB. Sebbene MySQL supporti più motori di storage con funzionalità diverse, non tutti sono ottimizzati per il recupero da arresto anomalo e per la durata dei dati. Ad esempio, il motore di archiviazione MyISAM non supporta un ripristino affidabile in caso di arresto anomalo e potrebbe impedire il corretto funzionamento di point-in-time un ripristino o di uno snapshot. Ciò può causare la perdita o il danneggiamento dei dati quando si riavvia MySQL dopo un arresto anomalo.

InnoDB è il motore di storage consigliato e supportato per istanze di database MySQL su Amazon RDS. Inoltre, a differenza delle istanze MyISAM, è possibile effettuare la migrazione delle istanze InnoDB su Aurora. Tuttavia, MyISAM offre prestazioni migliori di InnoDB quando sono richieste solide funzionalità di ricerca full-text. Se scegli comunque di usare MyISAM con Amazon RDS, le fasi illustrate in Backup automatici con motori di storage MySQL non supportati possono essere utili in determinati scenari per la funzionalità di ripristino da uno snapshot.

Se desideri convertire le tabelle MyISAM esistenti in tabelle InnoDB, puoi utilizzare la procedura illustrata nella documentazione MySQL. MyISAM e InnoDB offrono diversi vantaggi e svantaggi, per cui dovresti valutare attentamente l'impatto di questa conversione sulle tue applicazioni prima di eseguirla.

Inoltre, il Federated Storage Engine non è attualmente supportato da Amazon RDS for MySQL.

Best practice per l'utilizzo di MariaDB

Sia le dimensioni delle tabelle che il numero di tabelle in un database MariaDB possono influire sulle prestazioni.

Dimensione della tabella

In genere, i vincoli del sistema operativo sulle dimensioni dei file determinano la dimensione massima effettiva della tabella per i database MariaDB. Quindi, i limiti di solito non sono determinati dai vincoli interni MariaDB.

In un'istanza database MariaDB, evita che le tabelle nel database diventino troppo grandi. Sebbene il limite di storage generale sia 64 TiB, i limiti di storage forniti limitano la dimensione massima di un file di tabella MariaDB a 16 TiB. Suddividi le tabelle più grandi in file di dimensioni ben al di sotto del limite di 16 TiB. Ciò può anche migliorare le prestazioni e i tempi di recupero.

Le tabelle di dimensioni molto grandi (maggiori di 100 GB) possono influire negativamente sulle prestazioni di lettura e scrittura (incluse le istruzioni DML e in particolare le istruzioni DDL). Gli indici sulle tabelle di grandi dimensioni possono migliorare significativamente le prestazioni selezionate, ma possono anche ridurre le prestazioni delle istruzioni DML. Le istruzioni DDL, ad esempio ALTER TABLE, possono essere significativamente più lente per le tabelle di grandi dimensioni perché tali operazioni potrebbero ricostruire completamente una tabella in alcuni casi. Queste istruzioni DDL potrebbero bloccare le tabelle per la durata dell'operazione.

La quantità di memoria richiesta da MariaDB per le letture e le scritture dipende dalle tabelle coinvolte nelle operazioni. È una best practice avere almeno abbastanza RAM per contenere gli indici delle tabelle utilizzate attivamente . Per trovare le dieci tabelle e gli indici più grandi in un database, utilizzare la seguente query:

select table_schema, TABLE_NAME, dat, idx from 
(SELECT table_schema, TABLE_NAME, 
       ( data_length ) / 1024 / 1024 as dat,
       ( index_length ) / 1024 / 1024 as idx
FROM information_schema.TABLES
order by 3 desc ) a
order by 3 desc 
limit 10;

Numero di tabelle

Il file system sottostante può avere un limite al numero di file che rappresentano le tabelle. Tuttavia, MariaDB non ha limiti per il numero di tabelle. Ciononostante, il numero totale di tabelle nel motore di archiviazione MariaDB InnoDB può contribuire al deterioramento delle prestazioni, indipendentemente dalle dimensioni di tali tabelle. Per limitare l'impatto del sistema operativo, è possibile dividere le tabelle tra più database nella stessa istanza database di MariaDB. In questo modo potrebbe limitare il numero di file in una directory, ma non risolve il problema generale.

Il deterioramento delle prestazioni a causa di un gran numero di tabelle (più di 10.000) è provocato da MariaDB che lavora con i file di archiviazione, compresa l'apertura e la chiusura dei file di archiviazione in MariaDB. Per risolvere questo problema, è possibile aumentare la dimensione dei parametri table_open_cache e table_definition_cache. Tuttavia, aumentando i valori di tali parametri potrebbe aumentare significativamente la quantità di memoria utilizzata da MariaDB e potrebbe anche utilizzare tutta la memoria disponibile. Per ulteriori informazioni, consulta Ottimizzazione di table_open_cache nella documentazione di MariaDB.

Inoltre, troppe tabelle possono influenzare significativamente il tempo di avvio di MariaDB. Possono essere interessati sia un arresto e un riavvio pulito che un ripristino di arresto anomalo del sistema. Si consiglia di avere meno di diecimila tabelle totali in tutti i database in un'istanza database.

Motore di storage

Le funzionalità di point-in-time ripristino e ripristino delle istantanee di Amazon RDS for MariaDB richiedono un motore di storage ripristinabile in caso di arresto anomalo. Sebbene MariaDB supporti più motori di storage con funzionalità diverse, non tutti sono ottimizzati per il recupero da arresto anomalo e per la durata dei dati. Ad esempio, sebbene Aria sia un sostituto sicuro di MyISAM, potrebbe comunque impedire che un point-in-time ripristino o un ripristino di istantanee funzionino come previsto. Ciò può causare la perdita o il danneggiamento dei dati quando si riavvia MariaDB dopo un arresto anomalo. InnoDB è il motore di storage consigliato e supportato per istanze di database MariaDB su Amazon RDS. Se scegli comunque di usare Aria con Amazon RDS, le fasi illustrate in Backup automatici con motori di storage MariaDB non supportati possono essere utili in determinati scenari per la funzionalità di ripristino da uno snapshot.

Se desideri convertire le tabelle MyISAM esistenti in tabelle InnoDB, puoi utilizzare la procedura illustrata nella documentazione di MariaDB. MyISAM e InnoDB offrono diversi vantaggi e svantaggi, per cui dovresti valutare attentamente l'impatto di questa conversione sulle tue applicazioni prima di eseguirla.

Best practice per l'utilizzo di Oracle

Per informazioni sulle best practice per l'uso di Amazon RDS for Oracle, consulta la pagina relativa alle best practice per l'esecuzione di Oracle Database su Amazon Web Services.

Un workshop AWS virtuale del 2020 includeva una presentazione sull'esecuzione dei database Oracle di produzione su Amazon RDS. Un video della presentazione è disponibile qui:

Best practice per l'utilizzo di PostgreSQL

Esistono due momenti importanti in cui puoi migliorare le prestazioni con RDS per PostgreSQL: uno è quando carichi i dati in un'istanza database e l'altro è quando usi la funzione di vacuum automatico di PostgreSQL. Le sezioni seguenti illustrano alcune delle prassi suggerite per queste aree.

Per informazioni su come Amazon RDS implementa altre attività comuni del DBA PostgreSQL, consulta Attività DBA comuni per Amazon RDS for PostgreSQL.

Caricamento di dati in un'istanza di database PostgreSQL

Durante il caricamento di dati in un'istanza database Amazon RDS per PostgreSQL, dovresti modificare le impostazioni dell'istanza database e i valori del gruppo di parametri del database per consentire un'importazione più efficace dei dati nell'istanza database.

Modifica i parametri dell'istanza database come segue:

Modifica il gruppo di parametri del database in modo da includere le seguenti impostazioni. Per individuare le impostazioni più efficienti per la tua istanza database è necessario testare le impostazioni dei parametri.

Utilizza i comandi pg_dump -Fc (compresso) o pg_restore -j (parallelo) con queste impostazioni.

Al termine dell'operazione di caricamento, ripristina le normali impostazioni dell'istanza database e dei parametri database.

Utilizzo della funzione di eliminazione automatica di PostgreSQL

La funzione di eliminazione automatica per i database di PostgreSQL è una funzione vivamente consigliata per mantenere l'integrità dell'istanza di database di PostgreSQL. La funzione di eliminazione automatica automatizza l'esecuzione dei comandi VACUUM e ANALYZE. Il suo utilizzo è richiesto da PostgreSQL, non imposto da Amazon RDS, ed è essenziale per garantire buone prestazioni. La funzione è abilitata per impostazione predefinita per tutte le nuove istanze database Amazon RDS per PostgreSQL e i relativi parametri di configurazione sono impostati in modo appropriato per impostazione predefinita.

L'amministratore del database è tenuto a conoscere e a comprendere questa operazione di manutenzione. Per la documentazione PostgreSQL sull'autovacuum, consulta The Autovacuum Daemon (Daemon di autovacuum).

La funzione di eliminazione automatica non è un'operazione "priva di risorse", ma viene eseguita in background e, per quanto possibile, assegna la precedenza alle operazioni dell'utente. Se abilitata, verifica la presenza di tabelle con un numero elevato di tuple aggiornate o eliminate. Inoltre, protegge dalla perdita di dati molto vecchi in seguito a wraparound dell'ID transazione. Per ulteriori informazioni, consulta Impedire gli errori di wraparound dell'ID transazione.

La funzione di eliminazione automatica non deve essere considerata un'operazione dal sovraccarico elevato che può essere limitata per migliorare le prestazioni. Al contrario, le tabelle con un'elevata velocità di aggiornamento ed eliminazione si deteriorano rapidamente nel tempo se non viene eseguita la funzione di eliminazione automatica.

I parametri della funzione di eliminazione automatica determinano quando viene eseguita e con quale intensità. I parametri autovacuum_vacuum_threshold e autovacuum_vacuum_scale_factor determinano quando viene eseguita la funzione di eliminazione automatica. I parametri autovacuum_max_workers, autovacuum_nap_time, autovacuum_cost_limit e autovacuum_cost_delay determinano con quale intensità viene eseguita la funzione di eliminazione automatica. Per ulteriori informazioni sull'autovacuum, su quando viene eseguito e sui parametri richiesti, consulta la Routine Vacuuming (Vacuum di routine) nella documentazione di PostgreSQL.

La seguente query mostra il numero di tuple "inattive" in una tabella denominata table1:

SELECT relname, n_dead_tup, last_vacuum, last_autovacuum FROM 
pg_catalog.pg_stat_all_tables 
WHERE n_dead_tup > 0 and relname = 'table1';

I risultati della query saranno simili a quelli nell'esempio seguente:

relname | n_dead_tup | last_vacuum | last_autovacuum
---------+------------+-------------+-----------------
 tasks   |   81430522 |             |
(1 row) 

Video su best practice di Amazon RDS for PostgreSQL

La conferenza AWS re:Invent 2020 ha incluso una presentazione sulle nuove funzionalità e le best practice per lavorare con PostgreSQL su Amazon RDS. Un video della presentazione è disponibile qui:

Best practice per l'utilizzo di SQL Server

Le best practice per un'implementazione Multi-AZ con un'istanza di database di SQL Server sono le seguenti:

Quando si utilizza un'implementazione Multi-AZ di SQL Server, ricordarsi che Amazon RDS crea le repliche per tutti i database SQL Server nell'istanza. Se non si desidera che database specifici abbiano repliche secondarie, impostare un'istanza database separata che non utilizza Multi-AZ per questi database.

Video su best practice di Amazon RDS for SQL Server

La conferenza AWS re:Invent 2019 ha incluso una presentazione sulle nuove funzionalità e sulle best practice per lavorare con SQL Server su Amazon RDS. Un video della presentazione è disponibile qui:

Utilizzo di gruppi di parametri di database

È consigliabile provare le modifiche al gruppo di parametri di database su un'istanza di database di test prima di applicarle a istanze di database di produzione. Un'impostazione non corretta dei parametri del motore di un database in un gruppo di parametri di database può avere ripercussioni negative non previste, tra cui prestazioni scadenti e instabilità del sistema. Fai sempre attenzione quando modifichi i parametri del motore di un database ed effettui il backup di un'istanza di database prima di modificare un gruppo di parametri di database.

Per ulteriori informazioni sul backup di un'istanza di database, consulta Backup, ripristino ed esportazione dei dati.

Best practice per automatizzare la creazione di istanze database

È una best practice di Amazon RDS creare un'istanza database con la versione secondaria preferita del motore di database. Puoi utilizzare l' AWS CLI API Amazon RDS o automatizzare la creazione AWS CloudFormation di istanze DB. Quando utilizzi questi metodi, puoi specificare solo la versione principale e Amazon RDS crea automaticamente l'istanza con la versione secondaria preferita. Ad esempio, se PostgreSQL 12.5 è la versione secondaria preferita e se si specifica la versione 12 con create-db-instance, l'istanza database sarà la versione 12.5.

Per determinare la versione secondaria preferita, è possibile eseguire il comando describe-db-engine-versions con l'opzione --default-only come mostrato nell'esempio seguente.

aws rds describe-db-engine-versions --default-only --engine postgres

{
    "DBEngineVersions": [
        {
            "Engine": "postgres",
            "EngineVersion": "12.5",
            "DBParameterGroupFamily": "postgres12",
            "DBEngineDescription": "PostgreSQL",
            "DBEngineVersionDescription": "PostgreSQL 12.5-R1",
            ...some output truncated...
        }
    ]
}

Per informazioni sulla creazione di istanze database a livello di programmazione, vedere le seguenti risorse:

Video sulle nuove funzionalità di Amazon RDS

La conferenza AWS re:Invent del 2023 ha incluso una presentazione sulle nuove funzionalità di Amazon RDS. Un video della presentazione è disponibile qui: