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

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.

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:

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.

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

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.

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:

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:

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:

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

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:

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:

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: