Le migliori pratiche per Amazon RDS

Scopri le best practice per lavorare con AmazonRDS. Man mano che vengono identificate nuove best practice, aggiorneremo questa sezione.

Nota

Per consigli comuni per AmazonRDS, consultaRaccomandazioni da RDS.

Linee guida operative RDS di base di Amazon

Di seguito sono riportate le linee guida operative di base che tutti dovrebbero seguire quando lavorano con AmazonRDS. Tieni presente che l'Amazon RDS Service Level Agreement richiede che tu segua queste linee guida:

• Utilizza i parametri per monitorare la memoriaCPU, il ritardo della replica e l'utilizzo dello storage. Puoi configurare Amazon in modo che ti CloudWatch avvisi quando i modelli di utilizzo cambiano o quando la tua distribuzione si avvicina ai limiti di capacità. Ciò consente di mantenere le prestazioni e la disponibilità del sistema.

• Incrementa la capacità dell'istanza database quando stai per raggiungere i limiti della capacità di storage. Avrai bisogno di memoria e storage aggiuntivi per soddisfare aumenti imprevisti della domanda delle tue applicazioni.

• Abilita i backup automatici e imposta la finestra di backup in modo che si verifichi durante il minimo giornaliero di scritturaIOPS. Questo quando un backup è meno dannoso per l'utilizzo del database.

• Se il carico di lavoro del database richiede più operazioni di I/O rispetto a quelle che hai assegnato, il ripristino dopo un failover o un errore del database sarà lento. Per aumentare la capacità I/O di un'istanza di database, effettua una o più delle seguenti operazioni:

  • Effettua la migrazione a una classe di istanza database con elevata capacità di I/O.

  • Esegui la conversione dallo storage magnetico allo IOPS storage General Purpose o Provisioned, a seconda dell'entità di incremento richiesta. Per informazioni sui tipi di storage disponibili, consulta Tipi RDS di storage Amazon.

    Se esegui la conversione allo IOPS storage Provisioned, assicurati di utilizzare anche una classe di istanza DB ottimizzata per Provisioned. IOPS Per informazioni su ProvisionedIOPS, vedere. IOPSSSDStorage assegnato

  • Se utilizzi già lo IOPS storage Provisioned, fornisci una capacità di throughput aggiuntiva.

• Se l'applicazione client memorizza nella cache i dati del Domain Name Service (DNS) delle istanze DB, impostate un valore time-to-live (TTL) inferiore a 30 secondi. L'indirizzo IP sottostante di un'istanza DB può cambiare dopo un failover. La memorizzazione nella cache DNS dei dati per un periodo prolungato può quindi causare errori di connessione. L'applicazione potrebbe tentare di connettersi a un indirizzo IP non più in uso.

• Prova il failover per l'istanza database per capire quanto tempo impiega il processo per il caso d'uso particolare. Inoltre, garantisci che l'applicazione che accede all'istanza database è in grado di connettersi automaticamente alla nuova istanza database dopo il failover.

Consigli sulle istanze DB RAM

Una best practice in termini di RDS prestazioni di Amazon consiste nell'allocare una quantità sufficiente RAM in modo che il set di lavoro risieda quasi completamente in 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 IOPS metrica Read (usando Amazon CloudWatch) mentre l'istanza DB è sotto carico. Il valore di Read IOPS dovrebbe essere piccolo e stabile. In alcuni casi, il ridimensionamento della classe di istanza DB a una classe con più RAM risultati comporta un calo drastico di IOPS Read. In questi casi, il set di lavoro non è completamente in memoria. Continua a scalare verso l'alto fino a quando la lettura IOPS non scenda più in modo drastico dopo un'operazione di ridimensionamento o finché la lettura non IOPS venga ridotta a una quantità molto piccola. Per ulteriori informazioni sul monitoraggio dei parametri di un'istanza di database, consulta Visualizzazione delle metriche nella console Amazon RDS.

AWS driver di database

Consigliamo il 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 l'autenticazione con AWS Secrets Manager, AWS Identity and Access Management (IAM) e Federated Identity. Il AWS i driver si affidano al monitoraggio dello stato dell'istanza DB e alla conoscenza della topologia dell'istanza per determinare il nuovo scrittore. 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 di AWS la suite di driver prevede il 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 Enhanced Monitoring è abilitato, Amazon RDS fornisce metriche in tempo reale per il sistema operativo (OS) su cui viene eseguita l'istanza DB. È possibile visualizzare le metriche per l'istanza DB utilizzando la console. Puoi anche utilizzare l'JSONoutput 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 i problemi di prestazioni causati da risorse insufficienti e altri colli di bottiglia comuni, puoi monitorare i parametri disponibili per la tua istanza Amazon DB. 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 con la dashboard Performance Insights.

È 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, consultare Creazione di un rapporto di analisi delle prestazioni in Performance Insights.

Per visualizzare i parametri relativi alle prestazioni

1. Accedi al AWS Management Console e apri la RDS console Amazon all'indirizzo https://console.aws.amazon.com/rds/.

2. Nel riquadro di navigazione, scegliere Databases (Database), quindi scegliere un'istanza database.

3. Selezionare Monitoring (Monitoraggio).

   Il pannello di controllo fornisce le metriche sulle prestazioni. L'impostazione predefinita delle metriche consente di visualizzare le informazioni relative alle ultime tre ore.

4. Utilizzare i pulsanti numerati in alto a destra per sfogliare le metriche aggiuntive o modificare le impostazioni per visualizzare altre metriche.

5. Scegliere un parametro relativo alle prestazioni per regolare l'intervallo di tempo per la visualizzazione dei dati per i giorni diversi da quello corrente. È possibile modificare i valori dei campi Statistic (Statistica), Time Range (Intervallo di tempo) e Period (Periodo) in base alle informazioni che si desidera visualizzare. Ad esempio, potresti voler visualizzare i valori di picco di un parametro per ogni giorno nelle ultime due settimane. In tal caso, imposta Statistic (Statistiche) su Maximum (Massimo), Time Range (Intervallo di tempo) su Last 2 Weeks (Ultime 2 settimane) e Period (Periodo) su Day (Giorno).

Puoi anche visualizzare le metriche delle prestazioni utilizzando CLI oAPI. Per ulteriori informazioni, consulta Visualizzazione delle metriche nella console Amazon RDS.

Per impostare una sveglia CloudWatch

1. Accedi a AWS Management Console e apri la RDS console Amazon all'indirizzo https://console.aws.amazon.com/rds/.

2. Nel riquadro di navigazione, scegliere Databases (Database), quindi scegliere un'istanza database.

3. Scegliere Logs & events (Log ed eventi).

4. Nella sezione CloudWatch allarmi, scegli Crea allarme.

   

5. Per Invia notifiche, scegli Sì e per Invia notifiche a, scegli Nuova email o SMS argomento.

6. In Topic name (Nome argomento) digitare un nome per la notifica e in With these recipients (Con questi destinatari) digitare un elenco separato da virgole con gli indirizzi e-mail e i numeri di telefono.

7. In Metric (Parametro) scegliere la statistica e il parametro dell'allarme da impostare.

8. In Threshold (Soglia) specificare se il parametro deve essere maggiore, minore o uguale alla soglia e specificare il valore di soglia.

9. In Evaluation period (Periodo di valutazione), scegli il periodo di valutazione per l'allarme. In consecutive period(s) of (periodo/i consecutivo/i di) scegli il periodo durante il quale si deve raggiungere la soglia per attivare l'allarme.

10. Per Nome dell'allarme, inserire un nome per l'allarme.

11. Scegli Crea Alarm (Crea allarme).

L'allarme viene visualizzato 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.

CPU

• CPUUtilizzo: percentuale della capacità di elaborazione del computer utilizzata.

Memoria

• Memoria liberabile: quanta quantità RAM è disponibile sull'istanza DB, in byte. La linea rossa nelle metriche della scheda Monitoraggio è contrassegnata al 75% per i CPU parametri di memoria e archiviazione. Se il consumo di memoria dell'istanza supera regolarmente questa linea, significa che è necessario controllare il carico di lavoro o aggiornare l'istanza.

• Utilizzo dello swap: la quantità di spazio di swap utilizzata dall'istanza DB, in byte.

Spazio su disco

• Spazio di storage libero: quantità di spazio su disco non attualmente utilizzato dall'istanza database, in megabyte.

Operazioni di input/output

• LetturaIOPS, scritturaIOPS: il numero medio di operazioni di lettura o scrittura su disco al secondo.

• Latenza di lettura, Latenza di scrittura: il tempo medio per un'operazione di lettura o scrittura, in millisecondi.

• Throughput di lettura, Throughput di scrittura: il numero medio di megabyte letti dal e scritti sul disco al secondo.

• Profondità coda: il numero di operazioni I/O in attesa di essere scritte sul o lette dal disco.

Traffico di rete

• Throughput di ricezione di rete, Throughput di trasmissione di rete – La velocità del traffico di rete verso e dall'istanza database in megabyte al secondo.

Connessioni database

• Connessioni DB: il numero di sessioni client connesse all'istanza database.

Per descrizioni individuali più dettagliate dei parametri disponibili relativi alle prestazioni, consultare Monitoraggio dei parametri di RDSAmazon 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:

• RAMConsumo elevatoCPU: valori CPU o RAM consumo elevati potrebbero essere appropriati. Ad esempio, se sono in linea con gli obiettivi dell'applicazione (come velocità di trasmissione effettiva o simultaneità) e sono previsti.

• Consumo dello spazio su disco: esamina il consumo dello spazio su disco se lo spazio usato supera costantemente l'85% dello spazio su disco totale. Verifica se è possibile eliminare dati dall'istanza o archiviare dati su un sistema diverso per liberare spazio.

• Traffico di rete – Per il traffico di rete, rivolgiti al tuo amministratore di sistema per identificare il throughput previsto per la rete del dominio e la connessione Internet. Indaga il traffico di rete se il throughput è costantemente al di sotto del valore previsto.

• Connessioni al database: valuta se limitare le connessioni al database se noti un numero elevato di connessioni utente e contemporaneamente un peggioramento delle prestazioni e del tempo di risposta delle istanze. Il numero ideale di connessioni utente per l'istanza di database dipende dalla classe di istanza e dalla complessità delle operazioni eseguite. Per determinare il numero di connessioni di database, associa l'istanza database a un gruppo di parametri. In questo gruppo, imposta il parametro User Connections (Connessioni utente) su un valore diverso da 0 (illimitate). Puoi utilizzare un gruppo di parametri esistente o crearne uno nuovo. Per ulteriori informazioni, consulta Gruppi di parametri per RDS.

• IOPSmetriche: i valori previsti per le IOPS metriche dipendono dalle specifiche del disco e dalla configurazione del server, quindi utilizza la linea di base per conoscere le caratteristiche tipiche. Verifica se i valori sono costantemente diversi dalla baseline. Per IOPS prestazioni ottimali, assicuratevi che il set di lavoro tipico si adatti alla memoria per ridurre al minimo le operazioni di lettura e scrittura.

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 tue domande vengono ottimizzate e il problema persiste, valuta la possibilità di aggiornare Amazon. RDS Classi di istanze DB Potresti aggiornarlo a uno con più risorse (CPU,, spazio su discoRAM, larghezza di banda di rete, capacità di I/O) correlate al problema.

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:

• MySQL: vedi le SELECTistruzioni di ottimizzazione nella documentazione My. SQL Per ulteriori risorse per l'ottimizzazione delle query, consulta Le mie risorse per l'ottimizzazione e l'ottimizzazione SQL delle prestazioni.

• Oracle: vedere Database SQL Tuning Guide nella documentazione di Oracle Database.

• SQLServer: vedere Analisi di una query nella documentazione Microsoft. È inoltre possibile utilizzare le viste di gestione dei dati relative all'esecuzione, all'indice e all'I/O (DMVs) descritte in System Dynamic Management Views nella documentazione Microsoft per risolvere i problemi relativi alle query SQL del server.

  Un aspetto comune dell'ottimizzazione delle query è la creazione di indici efficaci. Per potenziali miglioramenti dell'indice per l'istanza database, consulta Database Engine Tuning Advisor (Ottimizzazione guidata al motore di database) nella documentazione di Microsoft. Per informazioni sull'utilizzo di Tuning Advisor su for Server, consultaRDS. SQL Analisi del carico di lavoro del database su un'istanza DB di Amazon RDS for SQL Server con Database Engine Tuning Advisor

• PostgreSQL: consulta Using EXPLAIN nella SQL documentazione di Postgre per informazioni su come analizzare un piano di query. Puoi utilizzare queste informazioni per modificare una query o tabelle sottostanti in modo da migliorare le prestazioni della query.

  Per informazioni su come specificare i join nella query per ottenere le migliori prestazioni, vedi Controllo del planner con clausole esplicite. JOIN

• MariaDB – Consulta Query optimizations (Ottimizzazioni delle query) nella documentazione MariaDB.

Procedure consigliate per lavorare con My SQL

Sia le dimensioni delle tabelle che il numero di tabelle in un SQL database My 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. Pertanto, i limiti di solito non sono determinati dai vincoli interni di MySQL.

Su un'istanza My SQL DB, evita che le tabelle del database diventino troppo grandi. Sebbene il limite di archiviazione generale sia di 64 TiB, i limiti di archiviazione assegnati limitano la dimensione massima di un file My SQL table 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 I miei limiti di dimensione dei SQL file in Amazon RDS.

Tabelle molto grandi (di dimensioni superiori a 100 GB) possono influire negativamente sulle prestazioni sia in lettura che in scrittura (incluse le istruzioni e in particolare DML le istruzioni). DDL Gli indici su tabelle di grandi dimensioni possono migliorare in modo significativo le prestazioni di determinate istruzioni, ma possono anche ridurre le prestazioni delle istruzioni. DML DDLle istruzioni, ad esempioALTER TABLE, possono essere notevolmente più lente per le tabelle di grandi dimensioni perché in alcuni casi tali operazioni potrebbero ricostruire completamente una tabella. Queste DDL istruzioni potrebbero bloccare le tabelle per tutta la durata dell'operazione.

La quantità di memoria richiesta da My SQL per le letture e le scritture dipende dalle tabelle coinvolte nelle operazioni. È consigliabile disporre di almeno una quantità sufficiente 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, My non SQL ha limiti al numero di tabelle. Nonostante ciò, il numero totale di tabelle nel motore di archiviazione My SQL InnoDB può contribuire al degrado delle prestazioni, indipendentemente dalle dimensioni di tali tabelle. Per limitare l'impatto sul sistema operativo, puoi suddividere le tabelle su più database nella stessa istanza My SQL DB. In questo modo potrebbe limitare il numero di file in una directory, ma non risolverà il problema generale.

Quando si verifica un peggioramento delle prestazioni a causa di un numero elevato di tabelle (più di 10.000), ciò è causato dall'SQLutilizzo dei file di archiviazione da parte di My, inclusa l'apertura e la chiusura degli stessi. Per risolvere questo problema, è possibile aumentare la dimensione dei parametri table_open_cache e table_definition_cache. Tuttavia, l'aumento dei valori di tali parametri potrebbe aumentare in modo significativo la quantità di memoria SQL utilizzata da My e potrebbe persino utilizzare tutta la memoria disponibile. Per ulteriori informazioni, consulta How My SQL Opens and Closes Tables nella SQL documentazione personale.

Inoltre, troppe tabelle possono influire in modo significativo sul tempo di SQL avvio di My. Ciò può compromettere sia l'arresto e il riavvio da zero che il ripristino in caso di arresto anomalo, specialmente nelle versioni precedenti a My SQL 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 numero elevato di tabelle in un SQL database My, consulta One Million Tables in My 8.0. SQL

Motore di storage

Le funzionalità di point-in-time ripristino e ripristino delle istantanee di Amazon RDS for My SQL richiedono un motore di storage ripristinabile in caso di arresto anomalo. Queste funzionalità sono supportate solo per il motore di archiviazione InnoDB. Sebbene My SQL supporti più motori di archiviazione con funzionalità diverse, non tutti sono ottimizzati per il ripristino in caso di crash e la durabilità dei dati. Ad esempio, il motore di ISAM archiviazione My non supporta un ripristino affidabile in caso di arresto anomalo e potrebbe impedire che un point-in-time ripristino o un ripristino di istantanee funzionino come previsto. Ciò potrebbe causare la perdita o il danneggiamento dei dati al riavvio di My dopo SQL un arresto anomalo.

InnoDB è il motore di archiviazione consigliato e supportato per le istanze My SQL DB su Amazon. RDS Le istanze InnoDB possono anche essere migrate su Aurora, mentre le istanze ISAM My non possono essere migrate. Tuttavia, My ISAM offre prestazioni migliori di InnoDB se si richiede un'intensa capacità di ricerca di testo completo. Se scegli ancora di utilizzare My ISAM con AmazonRDS, seguire i passaggi descritti in alcuni scenari Backup automatici con motori di archiviazione My SQL non supportati può essere utile per la funzionalità di ripristino degli snapshot.

Se desideri convertire le ISAM tabelle My esistenti in tabelle InnoDB, puoi utilizzare il processo descritto in Conversione delle tabelle da My a ISAM InnoDB nella documentazione personale. SQL Io ISAM e InnoDB abbiamo diversi punti di forza e di debolezza, quindi dovresti valutare appieno l'impatto di questo passaggio sulle tue applicazioni prima di farlo.

Inoltre, 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.

Tabelle molto grandi (di dimensioni superiori a 100 GB) possono influire negativamente sulle prestazioni sia in lettura che in scrittura (incluse le istruzioni e in particolare DML DDL le istruzioni). Gli indici su tabelle di grandi dimensioni possono migliorare in modo significativo le prestazioni di determinate istruzioni, ma possono anche ridurre le prestazioni delle istruzioni. DML DDLle istruzioni, ad esempioALTER TABLE, possono essere notevolmente più lente per le tabelle di grandi dimensioni perché in alcuni casi tali operazioni potrebbero ricostruire completamente una tabella. Queste DDL istruzioni potrebbero bloccare le tabelle per tutta la durata dell'operazione.

La quantità di memoria richiesta da MariaDB per le letture e le scritture dipende dalle tabelle coinvolte nelle operazioni. È consigliabile disporre di almeno una quantità sufficiente 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 My, potrebbe comunque impedire che un ripristino o un ripristino di ISAM istantanee funzionino come previsto. point-in-time Ciò può causare la perdita o il danneggiamento dei dati quando si riavvia MariaDB dopo un arresto anomalo. InnoDB è il motore di archiviazione consigliato e supportato per le istanze DB di MariaDB su Amazon. RDS Se scegli ancora di utilizzare Aria con AmazonRDS, seguire i passaggi descritti in alcuni scenari Backup automatici con motori di storage MariaDB non supportati può essere utile per la funzionalità di ripristino delle istantanee.

Se desideri convertire le ISAM tabelle My esistenti in tabelle InnoDB, puoi utilizzare il processo descritto in Conversione delle tabelle da My a ISAM InnoDB nella documentazione di MariaDB. Io ISAM e InnoDB abbiamo diversi punti di forza e di debolezza, quindi dovresti valutare appieno l'impatto di questo passaggio sulle tue applicazioni prima di farlo.

Best practice per l'utilizzo di Oracle

Per informazioni sulle best practice per lavorare con Amazon RDS for Oracle, consulta Best practice per l'esecuzione di database Oracle su Amazon Web Services.

NEL 2020 AWS il workshop virtuale ha incluso una presentazione sull'esecuzione dei database Oracle di produzione su AmazonRDS. Un video della presentazione è disponibile qui:

Le migliori pratiche per lavorare con Postgre SQL

Tra le due aree importanti in cui è possibile migliorare le prestazioni con PostgreSQL, una RDS riguarda il caricamento dei dati in un'istanza DB. Un'altra è quando si utilizza la funzione di autovacuum di SQL Postgre. Le sezioni seguenti illustrano alcune delle prassi suggerite per queste aree.

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

Caricamento di dati in un'istanza DB Postgre SQL

Quando carichi dati in un'istanza SQL database Amazon RDS for Postgre, modifica le impostazioni dell'istanza DB e i valori del gruppo di parametri DB. per consentire un'importazione più efficace dei dati nell'istanza database.

Modifica i parametri dell'istanza database come segue:

• Disabilità i backup dell'istanza di database (imposta backup_retention su 0)

• Disabilita Multi-AZ.

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.

• Incrementa il valore del parametro maintenance_work_mem. Per ulteriori informazioni sui parametri di consumo SQL delle risorse di Postgre, consulta la documentazione di Postgre. SQL

• Aumentate il valore dei checkpoint_timeout parametri max_wal_size and per ridurre il numero di scritture nel log write-ahead log (). WAL

• Disabilitare il parametro synchronous_commit

• Disabilita il parametro SQL Postgree autovacuum.

• Verifica che tutte le tabelle che stai importando siano registrate. I dati memorizzati in tabelle non registrate potrebbero andare smarriti durante un failover. Per ulteriori informazioni, vedere. CREATETABLEUNLOGGED

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 Autovacuum di Postgre SQL

La funzionalità di autovacuum per i SQL database Postgre è una funzionalità che consigliamo vivamente di utilizzare per mantenere l'integrità dell'istanza DB di Postgre. SQL Autovacuum automatizza l'esecuzione del ANALYZE comando VACUUM and L'uso di autovacuum è richiesto da Postgre, SQL non imposto da AmazonRDS, e il suo utilizzo è fondamentale per ottenere buone prestazioni. La funzionalità è abilitata per impostazione predefinita per tutte le nuove istanze Amazon RDS for Postgre SQL DB 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 SQL documentazione di Postgre sull'autovacuum, consulta The Autovacuum Daemon.

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.

Importante

La mancata esecuzione della funzione di eliminazione automatica potrebbe comportare l'interruzione delle attività per eseguire un'operazione di eliminazione molto più intrusiva. In alcuni casi, un'istanza SQL DB RDS per Postgre potrebbe non essere disponibile a causa di un uso troppo conservativo dell'autovacuum. In questi casi, il database Postgre si chiude per proteggersiSQL. A quel punto, Amazon RDS deve eseguire un vuoto single-user-mode completo direttamente sull'istanza DB. la quale può comportare un'interruzione delle attività di diverse ore. Pertanto, è consigliabile non disattivare la funzione di eliminazione automatica, che è abilitata per impostazione predefinita.

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 Routine Vacuuming nella documentazione di Postgre. SQL

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 sulle SQL migliori pratiche di Amazon RDS for Postgree

Il 2020 AWS La conferenza RE:Invent ha incluso una presentazione sulle nuove funzionalità e le migliori pratiche per lavorare con SQL Postgre su Amazon. RDS Un video della presentazione è disponibile qui:

Le migliori pratiche per lavorare con Server SQL

Le migliori pratiche per una distribuzione Multi-AZ con un'istanza SQL Server DB includono quanto segue:

• Usa gli eventi di Amazon RDS DB per monitorare i failover. Ad esempio, puoi ricevere un avvio via sms o e-mail in caso di failover di un'istanza di database. Per ulteriori informazioni sugli RDS eventi Amazon, consultaUtilizzo delle notifiche di RDS eventi di Amazon.

• Se l'applicazione memorizza nella cache DNS i valori, imposta time to live (TTL) su meno di 30 secondi. Questa impostazione TTL è una buona pratica in caso di failover. In un failover, l'indirizzo IP può cambiare e il valore memorizzato nella cache non essere più in uso.

• Si consiglia di non abilitare le seguenti modalità in quanto disattivano il log delle transazioni, necessario per l'implementazione Multi-AZ:

  • Modalità di recupero semplice

  • Modalità offline

  • Modalità di sola lettura

• Esegui un test per determinare il tempo di failover dell'istanza di database. Il tempo di failover può variare in base al tipo di database, alla classe dell'istanza e al tipo di storage che utilizzi. Dovresti inoltre verificare la capacità dell'applicazione di continuare a funzionare in caso di failover.

• Per ridurre il tempo di failover, procedi come indicato di seguito:

  • Assicurati di disporre di una quantità sufficiente di Provisioned per il tuo IOPS carico di lavoro. Un numero di operazioni I/O inadeguato può incrementare il tempo di failover. Il recupero del database richiede operazioni I/O.

  • Utilizza transazioni di piccole dimensioni. Il ripristino del database si basa sulle transazioni, per cui suddividendo le transazioni di grandi dimensioni in più transazioni di dimensioni inferiori, il tempo di failover dovrebbe ridursi.

• Tieni presente che durante un failover le latenze sono elevate. Come parte del processo di failover, Amazon replica RDS automaticamente i dati su una nuova istanza di standby. Questa replica significa che viene eseguito il commit dei nuovi dati su due diverse istanze database. Pertanto, fino a quando l'istanza database in standby non raggiunge la nuova istanza database principale, potrebbe verificarsi una latenza.

• Distribuisci le applicazioni in tutte le zone di disponibilità. Se una zona di disponibilità non è raggiungibile, le applicazioni saranno ancora disponibili nelle altre zone di disponibilità.

Quando lavori con una distribuzione Multi-AZ di SQL Server, ricorda che Amazon RDS crea repliche per tutti i database SQL Server sulla tua 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 sulle best practice di Amazon RDS for SQL Server

Il 2019 AWS La conferenza re:Invent ha incluso una presentazione sulle nuove funzionalità e le migliori pratiche per lavorare con Server SQL 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 RDS best practice di Amazon creare un'istanza DB con la versione secondaria preferita del motore di database. Puoi utilizzare il plugin AWS CLI, Amazon RDSAPI, oppure AWS CloudFormation per automatizzare la creazione di istanze DB. Quando utilizzi questi metodi, puoi specificare solo la versione principale e Amazon crea RDS automaticamente l'istanza con la versione secondaria preferita. Ad esempio, se Postgre SQL 12.5 è la versione secondaria preferita e se specifichi la versione 12 concreate-db-instance, l'istanza DB 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:

• Utilizzo di AWS CLI – create-db-instance

• Utilizzo di Amazon RDS API — C reateDBInstance

• Utilizzo AWS CloudFormation – AWS::RDS::DBInstance

Video sulle RDS nuove funzionalità di Amazon

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