Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Utilizzo di Amazon Aurora Serverless v1
**Importante**
AWS ha [annunciato la end-of-life data delAurora Serverless v1: 31 marzo 2025](https://repost.aws/questions/QUhcMVoChXRm2HLi8F-yih1g/announcement-support-for-aurora-s/announcement-support-for-aurora-serverless-v1-ending-soon). Tutti i cluster Aurora Serverless v1 non migrati entro il 31 marzo 2025 verranno spostati su Aurora Serverless v2 durante la finestra di manutenzione. Se l’aggiornamento non riesce, Amazon Aurora converte il cluster Serverless v1 in un cluster con provisioning con la versione del motore equivalente durante la finestra di manutenzione. Se applicabile, Amazon Aurora registrerà il cluster con provisioning convertito in Supporto esteso di Amazon RDS. Per ulteriori informazioni, consulta [Supporto esteso di Amazon RDS con Amazon Aurora](extended-support.md).
Amazon Aurora Serverless v1 (Amazon Aurora Serverless versione 1) è una configurazione con scalabilità automatica on demand di Amazon Aurora. Un *cluster di databaseAurora Serverless v1* è un cluster di database che consente di scalare la capacità di calcolo verso l'alto e verso il basso in base alle esigenze dell'applicazione. Ciò è in contrasto con i *cluster database con provisioning* di Aurora, per i quali è possibile gestire manualmente la capacità. Aurora Serverless v1 offre un'opzione relativamente semplice ed economica per carichi di lavoro poco frequenti, intermittenti o imprevedibili. È economico perché avvia e dimensiona automaticamente la capacità di calcolo in base all'uso dell'applicazione e si chiude quando non viene utilizzato.
Per ulteriori informazioni sui prezzi, consultare [Prezzi di Serverless](https://aws.amazon.com/rds/aurora/pricing/) in **Edizione compatibile con MySQL** o **Edizione compatibile con PostgreSQL** nella pagina Amazon Aurora pricing.
I cluster Aurora Serverless v1 hanno lo stesso tipo di volume di archiviazione ad alta capacità, distribuito e ad alta disponibilità utilizzato dai cluster database sottoposti a provisioning.
Il volume cluster di un cluster Aurora Serverless v1 è sempre crittografato. Puoi scegliere la chiave di crittografia, ma non puoi disabilitare la crittografia. Ciò significa che è possibile eseguire le stesse operazioni su uno snapshot Aurora Serverless v1 crittografato. Per ulteriori informazioni, consulta [Aurora Serverless v1 e snapshot](aurora-serverless-v1.how-it-works.md#aurora-serverless.snapshots).
**Topics**
+ [Disponibilità di Regioni e versioni per Aurora Serverless v1](#aurora-serverless-v1-Availability)
+ [Vantaggi di Aurora Serverless v1](#aurora-serverless-v1.advantages)
+ [Casi d'uso per Aurora Serverless v1](#aurora-serverless-v1.use-cases)
+ [Limitazioni di Aurora Serverless v1](#aurora-serverless.limitations)
+ [Requisiti di configurazione per Aurora Serverless v1](#aurora-serverless-v1.requirements)
+ [Utilizzo con TLS/SSL Aurora Serverless v1](#aurora-serverless.tls)
+ [Funzionamento di Aurora Serverless v1](aurora-serverless-v1.how-it-works.md)
+ [Creazione di un cluster di database Aurora Serverless v1](aurora-serverless.create.md)
+ [Ripristino di un cluster database Aurora Serverless v1](aurora-serverless.restorefromsnapshot.md)
+ [Modifica di un cluster di database Aurora Serverless v1](aurora-serverless.modifying.md)
+ [Dimensionamento manuale della capacità del cluster database Aurora Serverless v1](aurora-serverless.setting-capacity.md)
+ [Visualizzazione dei cluster database Aurora Serverless v1](aurora-serverless.viewing.md)
+ [Eliminazione di un cluster di database Aurora Serverless v1](aurora-serverless.delete.md)
+ [Versioni del motore del database di Aurora Serverless v1 e Aurora](aurora-serverless.relnotes.md)
## Disponibilità di Regioni e versioni per Aurora Serverless v1
La disponibilità e il supporto della funzionalità varia tra le versioni specifiche di ciascun motore di database Aurora e tra Regioni AWS. Per ulteriori informazioni sulla disponibilità di versioni e regioni con Aurora e Aurora Serverless v1, consultare [Aurora Serverless v1](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV1.md).
## Vantaggi di Aurora Serverless v1
Aurora Serverless v1 offre i vantaggi riportati di seguito:
+ **Più semplice del provisioning**: Aurora Serverless v1 rimuove gran parte della complessità della gestione delle istanze e della capacità del database.
+ **Scalabile**: Aurora Serverless v1 scala perfettamente la capacità di calcolo e memoria in base alle necessità, senza alcuna interruzione alle connessioni client.
+ **Conveniente**: quando utilizzi Aurora Serverless v1, paghi soltanto le risorse del database utilizzate su base al secondo.
+ **Archiviazione ad alta disponibilità**: Aurora Serverless v1 utilizza lo stesso sistema di archiviazione tollerante ai guasti e distribuito con replica in sei direzioni utilizzato da Aurora per la protezione dalla perdita dei dati.
## Casi d'uso per Aurora Serverless v1
Aurora Serverless v1 è progettato per i seguenti casi d'uso:
+ **Applicazioni poco utilizzate** – Hai un'applicazione che viene usata soltanto per pochi minuti diverse volte al giorno o alla settimana, come il sito di un blog a volume ridotto. Con Aurora Serverless v1 paghi soltanto le risorse del database utilizzate su base al secondo.
+ **Nuove applicazioni** – Stai distribuendo una nuova applicazione e non sei sicuro delle dimensioni dell'istanza necessarie. Con Aurora Serverless v1, puoi creare un endpoint del database e far sì che il database venga dimensionato automaticamente in base ai requisiti di capacità dell'applicazione.
+ **Carichi di lavoro variabili** – Esegui un'applicazione poco utilizzata, con picchi che vanno da 30 minuti a diverse ore poche volte al giorno o diverse volte all'anno. Esempi di questo tipo sono le applicazioni per le risorse umane, la redazione del budget e la creazione di report operativi. Grazie a Aurora Serverless v1, non dovrai più effettuare il provisioning per la capacità media o di picco.
+ **Carichi di lavoro imprevedibili** – Esegui carichi di lavoro giornalieri con aumenti improvvisi e imprevedibili dell'attività. Un esempio può essere quello di un sito sul traffico in cui c'è un aumento dell'attività quando inizia a piovere. Grazie a Aurora Serverless v1, il database aumenta automaticamente la capacità per soddisfare le esigenze del picco di carico dell'applicazione e la riduce quando il picco è terminato.
+ **Database di sviluppo e test** – Gli sviluppatori utilizzano i database durante l'orario di lavoro, ma non ne hanno bisogno nelle notti o nei fine settimana. Con Aurora Serverless v1, il database si spegne automaticamente quando non viene utilizzato.
+ **Applicazioni multi-tenant**: grazie a Aurora Serverless v1, non devi gestire individualmente la capacità del database per ogni applicazione utilizzata nel parco istanze. Aurora Serverless v1 gestisce la capacità del database a livello individuale per tuo conto.
## Limitazioni di Aurora Serverless v1
Le seguenti limitazioni si applicano a Aurora Serverless v1:
+
**Importante**
AWS ha [annunciato la end-of-life data delAurora Serverless v1: 31 marzo 2025](https://repost.aws/questions/QUhcMVoChXRm2HLi8F-yih1g/announcement-support-for-aurora-s/announcement-support-for-aurora-serverless-v1-ending-soon). Tutti i cluster Aurora Serverless v1 non migrati entro il 31 marzo 2025 verranno spostati su Aurora Serverless v2 durante la finestra di manutenzione. Se l’aggiornamento non riesce, Amazon Aurora converte il cluster Serverless v1 in un cluster con provisioning con la versione del motore equivalente durante la finestra di manutenzione. Se applicabile, Amazon Aurora registrerà il cluster con provisioning convertito in Supporto esteso di Amazon RDS. Per ulteriori informazioni, consulta [Supporto esteso di Amazon RDS con Amazon Aurora](extended-support.md).
+ Aurora Serverless v1 non supporta le seguenti caratteristiche:
+ Database globali di Aurora
+ Repliche di Aurora
+ AWS Identity and Access Management autenticazione del database (IAM)
+ Backtrack in Aurora
+ Flussi di attività di database
+ Autenticazione Kerberos
+ Approfondimenti sulle prestazioni
+ Server proxy per RDS
+ Visualizzazione dei log in Console di gestione AWS
+ Le connessioni a un cluster di database Aurora Serverless v1 vengono chiuse automaticamente se mantenute aperte per più di un giorno.
+ Tutti i cluster database Aurora Serverless v1 presentano le seguenti limitazioni:
+ Non è possibile esportare snapshot Aurora Serverless v1 in bucket Simple Storage Service (Amazon S3).
+ Non è possibile utilizzare AWS Database Migration Service and Change Data Capture (CDC) con i cluster Aurora Serverless v1 DB. Solo i cluster Aurora DB con provisioning supportano CDC AWS DMS come origine.
+ Non è possibile salvare i dati in file di testo in Amazon S3 o caricare i dati di file di testo in Aurora Serverless v1 da S3.
+ Non è possibile collegare un ruolo IAM a un cluster database Aurora Serverless v1. Tuttavia, è possibile caricare i dati su Aurora Serverless v1 da Simple Storage Service (Amazon S3) utilizzando l'estensione `aws_s3` con la funzione `aws_s3.table_import_from_s3` e il parametro `credentials`. Per ulteriori informazioni, consulta [Importazione di dati da Amazon S3 in un cluster database Aurora PostgreSQL](USER_PostgreSQL.S3Import.md).
+ Quando si utilizza l'editor di query, viene creato un segreto Secrets Manager con le credenziali per accedere al database. Eliminando le credenziali dall'editor di query, anche il segreto associato viene eliminato da Secrets Manager. Una volta eliminato, però, questo segreto non può essere recuperato.
+ I cluster database basati su Aurora MySQL che eseguono Aurora Serverless v1non supportano quanto segue:
+ Richiamo di AWS Lambda funzioni dall'interno del cluster Aurora MySQL DB. Tuttavia, AWS Lambda le funzioni possono effettuare chiamate al cluster DB. Aurora Serverless v1
+ Ripristino di uno snapshot da un'istanza database che non è Aurora MySQL o RDS for MySQL.
+ Replica dei dati mediante la replica basata su registri binari (binlog). Questa limitazione vale indipendentemente dal fatto che Aurora Serverless v1 del cluster database basato su Aurora MySQL sia l'origine o la destinazione della replica. Per replicare i dati in un cluster database Aurora Serverless v1 da un'istanza database MySQL esterna a Aurora, ad esempio da una istanza che viene eseguita su Amazon EC2, si consiglia di prendere in considerazione l'utilizzo di AWS Database Migration Service. Per ulteriori informazioni, consulta la [Guida per l'utente AWS Database Migration Service](https://docs.aws.amazon.com/dms/latest/userguide/).
+ Creazione di utenti con accesso basato su host (`'username'@'IP_address'`). Questo perché Aurora Serverless v1 utilizza un parco istanze router tra il client e l'host del database per un dimensionamento senza interruzioni. L’indirizzo IP visto dal cluster database Aurora Serverless è quello dell'host del router e non del client. Per ulteriori informazioni, consulta [Architettura di Aurora Serverless v1](aurora-serverless-v1.how-it-works.md#aurora-serverless.architecture).
Utilizzare, invece, il carattere jolly (`'username'@'%'`).
+ I cluster database basati su Aurora PostgreSQL che eseguono Aurora Serverless v1 hanno le seguenti limitazioni:
+ La gestione del piano di query di Aurora PostgreSQL (`apg_plan_management`) non è supportata.
+ La funzionalità di replica logica disponibile in Amazon RDS PostgreSQL e Aurora PostgreSQL non è supportata.
+ Le comunicazioni in uscita come quelle abilitate dalle estensioni Amazon RDS for PostgreSQL non sono supportate. Ad esempio, non è possibile accedere ai dati esterni con l'estensione `postgres_fdw/dblink`. Per ulteriori informazioni sulle estensioni PostgreSQL di RDS, consulta [PostgreSQL su Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_PostgreSQL.html#PostgreSQL.Concepts.General.FeatureSupport.Extensions.101x) nella *Guida per l'utente di RDS*.
+ Al momento, alcune query SQL e comandi non sono consigliati. Questi includono blocchi di consulenza a livello di sessione, relazioni temporanee, notifiche asincrone (`LISTEN`) e cursori con hold (`DECLARE name ... CURSOR WITH HOLD FOR query`). Inoltre, i comandi `NOTIFY` impediscono il dimensionamento e non sono consigliati.
Per ulteriori informazioni, consulta [Scalabilità automatica per Aurora Serverless v1](aurora-serverless-v1.how-it-works.md#aurora-serverless.how-it-works.auto-scaling).
+ Non è possibile impostare la finestra di backup automatico preferita per un cluster di database Aurora Serverless v1.
+ Puoi impostare la finestra di manutenzione per un cluster di database Aurora Serverless v1. Per ulteriori informazioni, consulta [Impostazione della finestra di manutenzione preferita del cluster database](USER_UpgradeDBInstance.Maintenance.md#AdjustingTheMaintenanceWindow.Aurora).
## Requisiti di configurazione per Aurora Serverless v1
Quando crei un cluster database Aurora Serverless v1, presta attenzione ai seguenti requisiti:
+ Utilizza i seguenti numeri di porta specifici per ogni motore database:
+ Aurora MySQL – `3306`
+ Aurora PostgreSQL – `5432`
+ Crea il tuo cluster database Aurora Serverless v1 in un Virtual Private Cloud (VPC) basato sul servizio Amazon VPC. Quando si crea un cluster di database Aurora Serverless v1 nel VPC, si utilizzano due (2) dei cinquanta (50) endpoint di interfaccia e Gateway Load Balancer assegnati al VPC. Questi endpoint vengono creati automaticamente per l'utente. Per aumentare la tua quota, puoi contattare Supporto. Per ulteriori informazioni, consulta la pagina relativa alle [quote di Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html#vpc-limits-endpoints).
+ Non puoi assegnare al cluster database Aurora Serverless v1 un indirizzo IP pubblico. Puoi accedere a un cluster database Aurora Serverless v1 solo da un VPC.
+ Crea sottoreti in zone di disponibilità diverse per il gruppo di sottoreti database utilizzato per il cluster database Aurora Serverless v1. In altre parole, non è possibile avere più di una sottorete nella stessa zona di disponibilità.
+ Le modifiche a un gruppo di sottoreti utilizzato da un cluster database Aurora Serverless v1 non vengono applicate al cluster.
+ È possibile accedere a un cluster Aurora Serverless v1 DB da AWS Lambda. Per far ciò, dovrai configurare la funzione Lambda per l'esecuzione nello stesso VPC del cluster database Aurora Serverless v1. *Per ulteriori informazioni su come lavorare con AWS Lambda, consulta [Configurazione di una funzione Lambda per accedere alle risorse in un Amazon VPC](https://docs.aws.amazon.com/lambda/latest/dg/vpc.html) nella Developer Guide.AWS Lambda *
## Utilizzo con TLS/SSL Aurora Serverless v1
Per impostazione predefinita, Aurora Serverless v1 utilizza il protocollo Transport Layer Security/Secure Sockets Layer (TLS/SSL) per crittografare le comunicazioni tra i client e il cluster DB. Aurora Serverless v1 Supporta TLS/SSL le versioni 1.0, 1.1 e 1.2. Non è necessario configurare il cluster database Aurora Serverless v1 per utilizzare TLS/SSL.
Si applicano le seguenti limitazioni:
+ TLS/SSL il supporto per i cluster Aurora Serverless v1 DB non è attualmente disponibile in Cina (Pechino). Regione AWS
+ Quando crei utenti di database per un cluster database Aurora Serverless v1 basato su Aurora MySQL, non utilizzare la clausola `REQUIRE` per le autorizzazioni SSL. In questo modo si impedisce agli utenti di connettersi all'istanza database Aurora.
+ Sia per le utilità MySQL Client che PostgreSQL Client, le variabili di sessione che è possibile utilizzare in altri ambienti non hanno alcun effetto se utilizzate tra client e. TLS/SSL Aurora Serverless v1
+ Per MySQL Client, quando ti connetti con la modalità `VERIFY_IDENTITY` di TLS/SSL, devi utilizzare il comando `mysql` compatibile con MySQL 8.0. Per ulteriori informazioni, consulta [Connessione a un'istanza database che esegue il motore del database MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ConnectToInstance.html).
A seconda del client utilizzato per connettersi al cluster Aurora Serverless v1 DB, potrebbe non essere necessario specificare se si desidera TLS/SSL ottenere una connessione crittografata. Ad esempio, per utilizzare PostgreSQL Client per connettersi a un cluster database Aurora Serverless v1 che esegue l'edizione compatibile con PostgreSQL di Aurora, è sufficiente connettersi come si fa normalmente.
```
psql -h endpoint -U user
```
Dopo aver inserito la password, il client PostgreSQL mostra i dettagli della connessione, tra cui la versione e il codice. TLS/SSL
```
psql (12.5 (Ubuntu 12.5-0ubuntu0.20.04.1), server 10.12)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.
```
**Importante**
Aurora Serverless v1utilizza Transport Layer ( Security/Secure Sockets Layer) (la TLS/SSL) protocol to encrypt connections by default unless SSL/TLS is disabled by the client application. The TLS/SSL connessione termina nel parco router). La comunicazione tra il parco istanze del router e il cluster di database Aurora Serverless v1 avviene entro il limite della rete interna del servizio.
È possibile controllare lo stato della connessione client per verificare se la connessione a Aurora Serverless v1 è TLS/SSL crittografata. `pg_stat_ssl`PostgreSQL e le tabelle `pg_stat_activity` e la `ssl_is_used` relativa funzione non mostrano lo stato TLS/SSL della comunicazione tra l'applicazione client e. Aurora Serverless v1 Allo stesso modo, lo TLS/SSL stato non può essere derivato dall'istruzione `status` MySQL.
I parametri del cluster Aurora `force_ssl` per PostgreSQL e `require_secure_transport` per MySQL non erano precedentemente supportati per Aurora Serverless v1. Questi parametri sono ora disponibili per Aurora Serverless v1. Per un elenco completo dei parametri supportati da Aurora Serverless v1, chiama l'operazione API. [DescribeEngineDefaultClusterParameters](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeEngineDefaultClusterParameters.html) Per ulteriori informazioni sui gruppi di parametri e su Aurora Serverless v1, consulta [Gruppi di parametri per Aurora Serverless v1](aurora-serverless-v1.how-it-works.md#aurora-serverless.parameter-groups).
Per utilizzare il MySQL Client per connettersi a Aurora Serverless v1 un cluster DB che esegue Aurora MySQL Compatible Edition, lo specifichi nella richiesta. TLS/SSL L'esempio seguente include il [trust store principale di Amazon CA 1](https://www.amazontrust.com/repository/AmazonRootCA1.pem) scaricato da Amazon Trust Services, necessario per la riuscita della connessione.
```
mysql -h endpoint -P 3306 -u user -p --ssl-ca=amazon-root-CA-1.pem --ssl-mode=REQUIRED
```
Specifica la password, quando richiesto. Verrà avviato il monitor MySQL. Puoi verificare che la sessione è crittografata utilizzando il comando `status`.
```
mysql> status
--------------
mysql Ver 14.14 Distrib 5.5.62, for Linux (x86_64) using readline 5.1
Connection id: 19
Current database:
Current user: ***@*******
SSL: Cipher in use is ECDHE-RSA-AES256-SHA
...
```
Per maggiori informazioni sulla connessione al database Aurora MySQL con MySQL Client, consulta [Connessione a un'istanza database che esegue il motore del database MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ConnectToInstance.html).
Aurora Serverless v1supporta tutte le TLS/SSL modalità disponibili per MySQL Client `mysql` () e PostgreSQL Client `psql` (), incluse quelle elencate nella tabella seguente.
| Descrizione della TLS/SSL modalità | mysql | psql |
| --- | --- | --- |
| Connettiti senza utilizzare TLS/SSL. | DISABLED | disattiva |
| Prova TLS/SSL prima a utilizzare la connessione, ma se necessario ricorri a una connessione non SSL. | PREFERRED | prefer (impostazione predefinita) |
| Applica l'uso di TLS/SSL. | REQUIRED | require |
| Applica TLS/SSL e verifica la CA. | VERIFY\$1CA | verify-ca |
| Applica TLS/SSL, verifica la CA e verifica il nome host della CA. | VERIFY\$1IDENTITY | verify-full |
Aurora Serverless v1 utilizza certificati con caratteri jolly. Se specifichi l'opzione "verifica CA" o "verifica CA e nome host CA" quando utilizzi TLS/SSL, scarica innanzitutto il [trust store CA 1 radice di Amazon](https://www.amazontrust.com/repository/AmazonRootCA1.pem) da Amazon Trust Services. Dopo aver fatto ciò, puoi identificare questo file in formato PEMA nel comando client. Per farlo utilizzando PostgreSQL Client:
Per Linux, macOS o Unix:
```
psql 'host=endpoint user=user sslmode=require sslrootcert=amazon-root-CA-1.pem dbname=db-name'
```
Per ulteriori informazioni sull'utilizzo del database Aurora PostgreSQL utilizzando Postgres Client, consulta [Connessione a un'istanza database che esegue il modulo di motore del database PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ConnectToPostgreSQLInstance.html).
Per informazioni generali sulla connessione ai cluster database Aurora, consulta [Connessione a un cluster database Amazon Aurora](Aurora.Connecting.md).
### Suite di crittografia supportate per connessioni a cluster DB Aurora Serverless v1
Utilizzando suite di cifratura configurabili, è possibile avere maggiore controllo sulla sicurezza delle connessioni al database. È possibile specificare un elenco di suite di crittografia che si desidera consentire per proteggere le TLS/SSL connessioni dei client al database. Con le suite di cifratura, è possibile controllare la crittografia di connessione accettata dal server di database. In questo modo si impedisce l'uso di sistemi di crittografia non sicuri o obsoleti.
I cluster DB Aurora Serverless v1 basati su Aurora MySQL supportano le stesse suite di crittografia dei cluster DB con provisioning di Aurora MySQL. Per informazioni su queste suite di crittografia, consulta [Configurazione di suite di cifratura per connessioni ai cluster di database Aurora MySQL](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL.ConfiguringCipherSuites).
I cluster di database Aurora Serverless v1 basati su Aurora PostgreSQL non supportano le suite di crittografia.
# Funzionamento di Aurora Serverless v1
**Importante**
AWS ha [annunciato la end-of-life data delAurora Serverless v1: 31 marzo 2025](https://repost.aws/questions/QUhcMVoChXRm2HLi8F-yih1g/announcement-support-for-aurora-s/announcement-support-for-aurora-serverless-v1-ending-soon). Tutti i cluster Aurora Serverless v1 non migrati entro il 31 marzo 2025 verranno spostati su Aurora Serverless v2 durante la finestra di manutenzione. Se l’aggiornamento non riesce, Amazon Aurora converte il cluster Serverless v1 in un cluster con provisioning con la versione del motore equivalente durante la finestra di manutenzione. Se applicabile, Amazon Aurora registrerà il cluster con provisioning convertito in Supporto esteso di Amazon RDS. Per ulteriori informazioni, consulta [Supporto esteso di Amazon RDS con Amazon Aurora](extended-support.md).
Di seguito è descritto il funzionamento di Aurora Serverless v1.
**Topics**
+ [Architettura di Aurora Serverless v1](#aurora-serverless.architecture)
+ [Scalabilità automatica per Aurora Serverless v1](#aurora-serverless.how-it-works.auto-scaling)
+ [Operazione di timeout per le modifiche di capacità](#aurora-serverless.how-it-works.timeout-action)
+ [Sospendi e riprendi per Aurora Serverless v1](#aurora-serverless.how-it-works.pause-resume)
+ [Determinazione del numero massimo di connessioni di database per Aurora Serverless v1](#aurora-serverless.max-connections)
+ [Gruppi di parametri per Aurora Serverless v1](#aurora-serverless.parameter-groups)
+ [Registrazione per Aurora Serverless v1](#aurora-serverless.logging)
+ [Aurora Serverless v1 e manutenzione](#aurora-serverless.maintenance)
+ [Aurora Serverless v1 e failover](#aurora-serverless.failover)
+ [Aurora Serverless v1 e snapshot](#aurora-serverless.snapshots)
## Architettura di Aurora Serverless v1
L'immagine seguente mostra una panoramica dell'architettura di Aurora Serverless v1.
![\[Architettura di Aurora Serverless v1\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-serverless-arch.png)
Invece di effettuare il provisioning e gestire i server di database, si specificano le unità ACUs di capacità Aurora (). Ogni ACU è una combinazione di circa 2 gigabyte (GB) di memoria, CPU corrispondente e rete. Lo storage del database esegue automaticamente il dimensionamento da 10 gibibyte (GiB) a 128 tebibytes (TiB), lo stesso storage di un cluster di database Aurora standard.
Puoi specificare l'ACU minima e massima. L'*unità di capacità Aurora minima* è l'ACU più bassa a cui un cluster di database può essere ridotto. L'*unità di capacità Aurora massima* è l'ACU più alta a cui un cluster di database può essere aumentato. In base alle impostazioni, Aurora Serverless v1 crea automaticamente regole di dimensionamento basate sulle soglie per utilizzo della CPU, delle connessioni e di memoria disponibile.
Aurora Serverless v1gestisce il pool di risorse disponibili in modo da ridurre al minimo Regione AWS i tempi di scalabilità. Quando Aurora Serverless v1 aggiunge nuove risorse al cluster di database Aurora, utilizza il parco istanze del router per passare le connessioni client attive alle nuove risorse. In qualsiasi momento specifico, ti vengono addebitati solo i costi ACUs che vengono utilizzati attivamente nel tuo cluster Aurora DB.
## Scalabilità automatica per Aurora Serverless v1
La capacità allocata al cluster di database Aurora Serverless v1 si ridimensiona senza problemi in base al carico generato dall'applicazione client. Qui, il carico è l'utilizzo della CPU e il numero di connessioni. Quando la capacità è vincolata da una di queste opzioni, Aurora Serverless v1 scala verso l'alto. Anche Aurora Serverless v1 scala verso l'alto quando rileva problemi di prestazioni che possono essere risolti in questo modo.
È possibile visualizzare gli eventi di scalabilità per il Aurora Serverless v1 cluster in. Console di gestione AWS Durante il dimensionamento automatico, Aurora Serverless v1 reimposta il parametro `EngineUptime`. Il valore del parametro di reset non è indice di un problema con il dimensionamento né di un'interruzione della connessione da parte di Aurora Serverless v1. È semplicemente il punto di partenza per i tempi di attività della nuova capacità. Per maggiori informazioni sui parametri, consulta [Monitoraggio dei parametri in un cluster di database Amazon Aurora](MonitoringAurora.md).
Quando il cluster Aurora Serverless v1 DB non ha connessioni attive, può essere ridimensionato fino a una capacità pari a zero (0 ACUs). Per ulteriori informazioni, vedi [Sospendi e riprendi per Aurora Serverless v1](#aurora-serverless.how-it-works.pause-resume).
Quando è necessario eseguire un'operazione di ridimensionamento, Aurora Serverless v1 prova prima a identificare un *punto di dimensionamento*, ovvero un momento in cui non vengono elaborate query. Aurora Serverless v1 potrebbe non riuscire a trovare un punto di dimensionamento per i seguenti motivi:
+ Query di lunga durata
+ Transazioni in corso
+ Tabelle temporanee o blocchi di tabelle
Per aumentare il tasso di successo del cluster di database Aurora Serverless v1 quando si trova un punto di dimensionamento, si consiglia di evitare query e transazioni di lunga durata. Per ulteriori informazioni sulle operazioni che provocano il blocco del dimensionamento e su come evitarle, consulta [Best practice per l'utilizzo di Aurora Serverless v1](https://aws.amazon.com/blogs/database/best-practices-for-working-with-amazon-aurora-serverless/) .
Per impostazione predefinita, Aurora Serverless v1 prova a trovare un punto di dimensionamento per 5 minuti (300 secondi). Puoi specificare un periodo di timeout diverso quando crei o modifichi il cluster. Il periodo di timeout può essere compreso tra 60 secondi e 10 minuti (600 secondi). Se Aurora Serverless v1 non riesce a trovare un punto di dimensionamento entro il periodo specificato, l'operazione di scalabilità automatica raggiunge il timeout.
Per impostazione predefinita, se l'autoscaling non trova un punto di dimensionamento prima del timeout, Aurora Serverless v1 mantiene il cluster alla capacità corrente. Questo comportamento di default può essere modificato quando si crea o si modifica il cluster di database Aurora Serverless v1 selezionando l'opzione **Force the capacity change (Forza la modifica della capacità)**. Per ulteriori informazioni, consulta [Operazione di timeout per le modifiche di capacità](#aurora-serverless.how-it-works.timeout-action).
## Operazione di timeout per le modifiche di capacità
Se la scalabilità automatica raggiunge il timeout senza trovare un punto di dimensionamento, per impostazione predefinita Aurora mantiene la capacità corrente. Se desideri che Aurora forzi la modifica, abilita l'opzione **Force the capacity change** (Forza la modifica della capacità). Questa opzione è disponibile nella sezione **Autoscaling timeout and action ** (Timeout e operazione di scalabilità automatica) della pagina **Create database** (Crea database) quando crei il cluster.
L'opzione **Force the capacity change** (Forza la modifica della capacità) è disabilitata di default. Lascia questa opzione deselezionata per evitare modifiche alla capacità del tuo cluster di database Aurora Serverless v1 nel caso in cui l'operazione di dimensionamento scada senza che sia stato trovato un punto di dimensionamento.
Se selezioni questa opzione, il cluster di database Aurora Serverless v1 applicherà la modifica della capacità anche senza un punto di dimensionamento. Prima di selezionare questa opzione, devi essere consapevole delle conseguenze che essa può avere:
+ Tutte le transazioni in corso vengono interrotte e viene visualizzato il seguente messaggio di errore.
Aurora MySQL versione 2 — ERRORE 1105 (HY000): L'ultima transazione è stata interrotta a causa di Seamless Scaling. Riprova.
Puoi inviare nuovamente la transazione non appena il cluster di database Aurora Serverless v1 diventa disponibile.
+ Le connessioni a tabelle temporanee e ai blocchi vengono eliminate.
Ti consigliamo di selezionare **Force the capacity change** (Forza la modifica della capacità) solo se è possibile recuperare l'applicazione in seguito a connessioni interrotte o transazioni incomplete.
Le scelte effettuate Console di gestione AWS durante la creazione di un cluster Aurora Serverless v1 DB vengono archiviate nell'oggetto, nelle proprietà and. `ScalingConfigurationInfo` `SecondsBeforeTimeout` `TimeoutAction` Quando si crea il cluster, il valore della proprietà `TimeoutAction` viene impostato su uno dei seguenti valori:
+ `RollbackCapacityChange`: questo valore viene impostato quando selezioni l'opzione **Roll back the capacity change** (Eseguire il rollback della modifica della capacità). Questo è il comportamento che segue di default.
+ `ForceApplyCapacityChange`: questo valore viene impostato quando selezioni l'opzione **Force the capacity change** (Forza la modifica della capacità).
È possibile ottenere il valore di questa proprietà su un cluster Aurora Serverless v1 DB esistente utilizzando il [describe-db-clusters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html) AWS CLI comando, come illustrato di seguito.
Per Linux, macOS o Unix:
```
aws rds describe-db-clusters --region region \
--db-cluster-identifier your-cluster-name \
--query '*[].{ScalingConfigurationInfo:ScalingConfigurationInfo}'
```
Per Windows:
```
aws rds describe-db-clusters --region region ^
--db-cluster-identifier your-cluster-name ^
--query "*[].{ScalingConfigurationInfo:ScalingConfigurationInfo}"
```
Ad esempio, di seguito è riportata la query e la risposta per un cluster di database Aurora Serverless v1 denominato `west-coast-sles` nella Regione Stati Uniti occidentali (California settentrionale).
```
$ aws rds describe-db-clusters --region us-west-1 --db-cluster-identifier west-coast-sles
--query '*[].{ScalingConfigurationInfo:ScalingConfigurationInfo}'
[
{
"ScalingConfigurationInfo": {
"MinCapacity": 1,
"MaxCapacity": 64,
"AutoPause": false,
"SecondsBeforeTimeout": 300,
"SecondsUntilAutoPause": 300,
"TimeoutAction": "RollbackCapacityChange"
}
}
]
```
Come mostra la risposta, questo cluster di database Aurora Serverless v1 utilizza l'impostazione predefinita.
Per ulteriori informazioni, consulta [Creazione di un cluster di database Aurora Serverless v1](aurora-serverless.create.md). Dopo aver creato il Aurora Serverless v1, potrai inoltre modificare l'azione di timeout e altre impostazioni della capacità in qualsiasi momento. Per scoprire come, consulta [Modifica di un cluster di database Aurora Serverless v1](aurora-serverless.modifying.md).
## Sospendi e riprendi per Aurora Serverless v1
Puoi scegliere di mettere in pausa il cluster di database Aurora Serverless v1 dopo un determinato periodo di tempo in cui non è stata registrata alcuna attività. Specifica il periodo di tempo in cui non viene registrata alcuna attività prima che il cluster di database venga messo in pausa. Quando si seleziona questa opzione, il tempo di inattività predefinito è di cinque minuti, ma è possibile modificare questo valore. Questa è un'impostazione facoltativa.
Quando il cluster di database viene messo in pausa, non avvengono attività di elaborazione o memoria e vengono addebitati soltanto i costi per lo storage. Se vengono richieste connessioni al database quando un cluster di database Aurora Serverless v1 è messo in pausa, il cluster di database si riavvia automaticamente e adempie alle richieste di connessione.
Quando il cluster di database riprende l'attività, ha la stessa capacità che aveva quando Aurora ha messo in pausa il cluster. Il numero di ACUs dipende da quanto Aurora ha aumentato o ridotto il cluster prima di metterlo in pausa.
**Nota**
Se un cluster di database viene messo in pausa per oltre sette giorni potrebbe essere sottoposto a backup con uno snapshot. In questo caso, Aurora ripristina il cluster di database dalla snapshot quando viene avanzata una richiesta di connessione.
## Determinazione del numero massimo di connessioni di database per Aurora Serverless v1
Gli esempi seguenti sono per un cluster di database Aurora Serverless v1 compatibile con MySQL 5.7. Puoi utilizzare un client MySQL o l'editor di query, se è stato configurato l'accesso. Per ulteriori informazioni, consulta [Esecuzione di query nell'editor della query](query-editor.md#query-editor.running).
**Trovare il numero massimo di connessioni al database**
1. Trova l'intervallo di capacità per il cluster di database Aurora Serverless v1 tramite la AWS CLI.
```
aws rds describe-db-clusters \
--db-cluster-identifier my-serverless-57-cluster \
--query 'DBClusters[*].ScalingConfigurationInfo|[0]'
```
Il risultato mostra che il suo intervallo di capacità è compreso tra 1 e 4. ACUs
```
{
"MinCapacity": 1,
"AutoPause": true,
"MaxCapacity": 4,
"TimeoutAction": "RollbackCapacityChange",
"SecondsUntilAutoPause": 3600
}
```
1. Esegui la seguente query SQL per trovare il numero massimo di connessioni.
```
select @@max_connections;
```
Il risultato mostrato è per la capacità minima del cluster, 1 ACU.
```
@@max_connections
90
```
1. Ridimensiona il cluster a 8—32. ACUs
Per ulteriori informazioni sul dimensionamento, consultare [Modifica di un cluster di database Aurora Serverless v1](aurora-serverless.modifying.md).
1. Conferma l'intervallo di capacità.
```
{
"MinCapacity": 8,
"AutoPause": true,
"MaxCapacity": 32,
"TimeoutAction": "RollbackCapacityChange",
"SecondsUntilAutoPause": 3600
}
```
1. Trova il numero massimo di connessioni.
```
select @@max_connections;
```
Il risultato mostrato si riferisce alla capacità minima del cluster, 8. ACUs
```
@@max_connections
1000
```
1. Ridimensiona il cluster fino al massimo possibile, 256—256 ACUs.
1. Conferma l'intervallo di capacità.
```
{
"MinCapacity": 256,
"AutoPause": true,
"MaxCapacity": 256,
"TimeoutAction": "RollbackCapacityChange",
"SecondsUntilAutoPause": 3600
}
```
1. Trova il numero massimo di connessioni.
```
select @@max_connections;
```
Il risultato mostrato è per 256. ACUs
```
@@max_connections
6000
```
**Nota**
Il `max_connections` valore non viene scalato linearmente con il numero di ACUs.
1. Ridimensiona il cluster fino a ACUs 1—4.
```
{
"MinCapacity": 1,
"AutoPause": true,
"MaxCapacity": 4,
"TimeoutAction": "RollbackCapacityChange",
"SecondsUntilAutoPause": 3600
}
```
Questa volta, il `max_connections` valore è 4. ACUs
```
@@max_connections
270
```
1. Riduci il cluster a 2 ACUs.
```
@@max_connections
180
```
Se hai configurato il cluster in modo che si interrompa dopo un certo periodo di inattività, il cluster viene ridimensionato a 0. ACUs Tuttavia, `max_connections` non scende sotto il valore per 1 ACU.
```
@@max_connections
90
```
## Gruppi di parametri per Aurora Serverless v1
Quando crei il tuo cluster di database Aurora Serverless v1, è possibile scegliere un motore del database Aurora specifico e un gruppo di parametri del cluster di database associato. A differenza dei cluster Aurora DB con provisioning, Aurora Serverless v1 un cluster DB ha una read/write singola istanza DB configurata solo con un gruppo di parametri del cluster DB e non ha un gruppo di parametri DB separato. Durante la scalabilità automatica, Aurora Serverless v1 deve essere in grado di modificare i parametri affinché il cluster funzioni al meglio per aumentare o diminuire la capacità. Così, con un cluster di database Aurora Serverless v1, alcune delle modifiche apportate ai parametri per un particolare tipo di motore del database potrebbero non essere applicabili.
Ad esempio, un cluster di database basato su Aurora PostgreSQL – Aurora Serverless v1 non può utilizzare `apg_plan_mgmt.capture_plan_baselines` e altri parametri che potrebbero essere utilizzati in cluster di database Aurora PostgreSQL con provisioning per la gestione del piano di query.
È possibile ottenere un elenco di valori predefiniti per i gruppi di parametri predefiniti per i vari motori Aurora DB utilizzando il comando CLI [describe-engine-default-cluster-parameters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-engine-default-cluster-parameters.html) e interrogando il. Regione AWS Di seguito sono riportati i valori che è possibile utilizzare per l'opzione `--db-parameter-group-family`.
| | |
| --- |--- |
| Aurora MySQL versione 2 | `aurora-mysql5.7` |
| Aurora PostgreSQL versione 11 | `aurora-postgresql11` |
| Aurora PostgreSQL versione 13 | `aurora-postgresql13` |
Ti consigliamo di configurarlo AWS CLI con l'ID della chiave di AWS accesso e la chiave di accesso AWS segreta e di impostarlo prima di utilizzare i Regione AWS comandi. AWS CLI Fornire la regione alla configurazione CLI consente di evitare di immettere il parametro `--region` l'esecuzione dei comandi. Per ulteriori informazioni sulla configurazione AWS CLI, consulta Nozioni di [base sulla configurazione nella Guida](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) per l'*AWS Command Line Interface utente*.
Nell'esempio seguente si recupera un elenco di parametri dal gruppo di cluster di database predefinito per Aurora MySQL versione 2.
Per Linux, macOS o Unix:
```
aws rds describe-engine-default-cluster-parameters \
--db-parameter-group-family aurora-mysql5.7 --query \
'EngineDefaults.Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | [?contains(SupportedEngineModes, `serverless`) == `true`] | [*].{param:ParameterName}' \
--output text
```
Per Windows:
```
aws rds describe-engine-default-cluster-parameters ^
--db-parameter-group-family aurora-mysql5.7 --query ^
"EngineDefaults.Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | [?contains(SupportedEngineModes, 'serverless') == `true`] | [*].{param:ParameterName}" ^
--output text
```
### Modifica dei valori dei parametri per Aurora Serverless v1
Come spiegato in [Gruppi di parametri per Amazon Aurora](USER_WorkingWithParamGroups.md), non è possibile modificare direttamente i valori in un gruppo di parametri predefinito, indipendentemente dal tipo (gruppo di parametri del cluster di database, gruppo di parametri DB). Al contrario, si crea un gruppo di parametri personalizzato basato sul gruppo di parametri cluster di database predefinito per il motore database Aurora e modificare le impostazioni in base alle esigenze su quel gruppo di parametri. Ad esempio, potresti voler modificare alcune impostazioni del tuo cluster Aurora Serverless v1 DB per registrare le [query o caricare log specifici del motore DB su Amazon.](#aurora-serverless.logging) CloudWatch
**Per creare un gruppo di parametri del cluster di database personalizzato**
1. Accedi a Console di gestione AWS e quindi apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Scegliere **Gruppi di parametri**.
1. Seleziona **Crea gruppo di parametri** per aprire il riquadro dei dettagli del gruppo di parametri.
1. Seleziona il gruppo cluster di database predefinito appropriato per il motore database che desideri utilizzare per il cluster di databaseAurora Serverless v1. Assicurati di scegliere le seguenti opzioni:
1. Per **Famiglia gruppo parametri**, seleziona la famiglia appropriata per il motore del database scelto. Assicurati che la selezione abbia un nome contenente il prefisso `aurora-`.
1. Per **Type** (Tipo), scegli **DB Cluster Parameter Group** (Gruppo di parametri del cluster di database).
1. Per **Nome gruppo** e **Descrizione**, specifica nomi significativi per l'utente o per altri utenti che potrebbero dover utilizzare il cluster di database Aurora Serverless v1 e i relativi parametri.
1. Scegliere **Create (Crea)**.
Il gruppo di parametri del cluster di database personalizzato viene aggiunto all'elenco dei gruppi di parametri disponibili per l'account nella Regione AWS. Ora puoi utilizzare il gruppo di parametri del cluster DB personalizzato quando crei nuovi cluster DB Aurora Serverless v1. Puoi anche modificare un cluster di database Aurora Serverless v1 esistente per utilizzare il gruppo di parametri del cluster di database personalizzato. Dopo che il cluster Aurora Serverless v1 DB inizia a utilizzare il gruppo di parametri del cluster DB personalizzato, puoi modificare i valori dei parametri dinamici utilizzando il Console di gestione AWS o il AWS CLI.
È inoltre possibile utilizzare la console per visualizzare un side-by-side confronto tra i valori nel gruppo di parametri del cluster DB personalizzato rispetto al gruppo di parametri del cluster DB predefinito, come mostrato nella schermata seguente.
![\[Log pubblicati nei cluster CloudWatch Logs for Aurora MySQL e Aurora PostgreSQL DB Aurora Serverless v1\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-serverless-custom-db-cluster-param-cf-default.png)
Quando modifichi i valori dei parametri in un cluster di database attivo, Aurora Serverless v1 avvia il dimensionamento senza interruzioni per applicare le modifiche ai parametri. Se il tuo cluster di database Aurora Serverless v1 è in pausa, riprende l'attività e inizia il dimensionamento in modo che possa apportare la modifica. L'operazione di dimensionamento per la modifica di un gruppo di parametri [forza sempre la modifica della capacità](#aurora-serverless.how-it-works.timeout-action), quindi tieni presente che la modifica dei parametri potrebbe comportare la perdita di connessioni se non è possibile trovare un punto di dimensionamento durante il periodo di dimensionamento.
## Registrazione per Aurora Serverless v1
Per impostazione predefinita, i log degli errori di Aurora Serverless v1 sono abilitati e caricati automaticamente su Amazon CloudWatch. Puoi anche fare in modo che il cluster Aurora Serverless v1 DB carichi i log specifici del motore di database Aurora su. CloudWatch Per fare ciò, abilita i parametri di configurazione nel gruppo di parametri del cluster di database personalizzati. Il tuo cluster Aurora Serverless v1 DB carica quindi tutti i log disponibili su Amazon. CloudWatch A questo punto, puoi utilizzarli CloudWatch per analizzare i dati di registro, creare allarmi e visualizzare le metriche.
Per Aurora MySQL, i log che è possibile abilitare sono mostrati nella tabella seguente. Se abilitati, vengono caricati automaticamente dal tuo cluster Aurora Serverless v1 DB su Amazon CloudWatch.
| Log Aurora MySQL | Description |
| --- | --- |
| `general_log` | Crea il log generale. Imposta su 1 per attivare questa opzione. Il valore predefinito è disattivato (0). |
| `log_queries_not_using_indexes` | Registra tutte le query nel log delle query lente che non utilizzano un indice. Il valore predefinito è disattivato (0). Imposta su 1 per attivare questo log. |
| `long_query_time` | Impedisce che le query in esecuzione rapida vengano registrate nel log delle query lente. Può essere impostato su un valore variabile compreso tra 0 e 31.536.000. Il valore predefinito è 0 (non attivo). |
| `server_audit_events` | L'elenco degli eventi da catturare nei log. I valori supportati sono `CONNECT`, `QUERY`, `QUERY_DCL`, `QUERY_DDL`, `QUERY_DML` e `TABLE`. |
| `server_audit_logging` | Imposta su 1 per attivare la registrazione di controllo del server. Se attivi questa opzione, puoi specificare gli eventi di controllo a cui inviare CloudWatch elencandoli nel `server_audit_events` parametro. |
| `slow_query_log` | Crea un log di query lente. Imposta su 1 per attivare il log di query lente. Il valore predefinito è disattivato (0). |
Per ulteriori informazioni, consulta [Utilizzo dell'audit avanzato con un cluster di database Amazon Aurora MySQL](AuroraMySQL.Auditing.md).
Per Aurora PostgreSQL, i log che è possibile abilitare sono mostrati nella tabella seguente. Se abilitati, vengono caricati automaticamente dal tuo cluster Aurora Serverless v1 DB su Amazon CloudWatch insieme ai normali log degli errori.
| Log Aurora PostgreSQL | Description |
| --- | --- |
| `log_connections` | Attivato di default e non può essere modificato. Registra i dettagli per tutte le nuove connessioni client. |
| `log_disconnections` | Attivato di default e non può essere modificato. Registra tutte le disconnessioni client. |
| `log_hostname` | Disattivato per impostazione predefinita e non modificabile. I nomi degli host non vengono registrati. |
| `log_lock_waits` | Il valore predefinito è 0 (disattivato). Imposta su 1 per registrare le attese di blocco. |
| `log_min_duration_statement` | La durata minima (in millisecondi) per l'esecuzione di un'istruzione prima della registrazione. |
| `log_min_messages` | Imposta i livelli dei messaggi che vengono registrati. I valori supportati sono `debug5`, `debug4`, `debug3`, `debug2`, `debug1`, `info`, `notice`, `warning`, `error`, `log`, `fatal`, `panic`. Per registrare i dati delle prestazioni nel log `postgres`, imposta il valore su `debug1`. |
| `log_temp_files` | Registra l'utilizzo di file temporanei che si trovano al di sopra dei kilobyte (kB) specificati. |
| `log_statement` | Controlla le istruzioni SQL specifiche che vengono registrate. I valori supportati sono `none`, `ddl`, `mod` e `all`. Il valore predefinito è `none`. |
Dopo aver attivato i log per Aurora MySQL o Aurora Aurora Serverless v1 PostgreSQL per il cluster DB, puoi visualizzare i log in. CloudWatch
### Visualizzazione dei Aurora Serverless v1 log con Amazon CloudWatch
Aurora Serverless v1carica automaticamente («pubblica») su Amazon CloudWatch tutti i log abilitati nel gruppo di parametri del cluster DB personalizzato. Non è necessario scegliere o specificare i tipi di log. Il caricamento dei log inizia non appena si attiva il parametro di configurazione log. Se in seguito questo parametro viene disattivato, gli altri caricamenti saranno interrotti. Tuttavia, tutti i log che sono già stati pubblicati CloudWatch rimarranno finché non li elimini.
Per ulteriori informazioni sull'utilizzo CloudWatch con i log MySQL di Aurora, consulta. [Monitoraggio degli eventi di log in Amazon CloudWatch](AuroraMySQL.Integrating.CloudWatch.md#AuroraMySQL.Integrating.CloudWatch.Monitor)
Per ulteriori informazioni su CloudWatch Aurora PostgreSQL, consulta. [Pubblicazione di log Aurora PostgreSQL in Amazon CloudWatch Logs](AuroraPostgreSQL.CloudWatch.md)
**Per visualizzare i log per il cluster di database Aurora Serverless v1**
1. Apri la console all'indirizzo. CloudWatch [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)
1. Scegli il tuo Regione AWS.
1. Scegli **Log groups** (Gruppi di log).
1. Seleziona il log del cluster di database Aurora Serverless v1 dall'elenco. Per i log di errori, il modello di denominazione è il seguente.
```
/aws/rds/cluster/cluster-name/error
```
Ad esempio, nello screenshot seguente sono riportati gli elenchi dei log pubblicati per un cluster di database Aurora Serverless v1 Aurora PostgreSQL denominato `western-sles`. Sono riportati anche diversi elenchi per il cluster di database Aurora Serverless v1 Aurora PostgreSQL denominato `west-coast-sles`. Seleziona il log desiderato per iniziare ad esplorarne il contenuto.
![\[Log pubblicati nei cluster CloudWatch Logs for Aurora MySQL e Aurora PostgreSQL DB Aurora Serverless v1\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-serverless-logs-in-cloudwatch.png)
## Aurora Serverless v1 e manutenzione
La manutenzione del cluster Aurora Serverless v1 DB, ad esempio l'applicazione delle funzionalità, delle correzioni e degli aggiornamenti di sicurezza più recenti, viene eseguita automaticamente dall'utente. Aurora Serverless v1dispone di una finestra di manutenzione che è possibile visualizzare Console di gestione AWS nella sezione **Manutenzione e backup** per il cluster Aurora Serverless v1 DB. È possibile trovare la data e l’ora in cui può essere eseguita la manutenzione e verificare se è presente una manutenzione in sospeso per il cluster di database Aurora Serverless v1 come mostrato nella seguente figura.
![\[Finestra di manutenzione per un cluster di database Aurora Serverless v1 di esempio, nessuna manutenzione in sospeso\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-serverless-maintenance-window.png)
Puoi impostare la finestra di manutenzione quando crei il cluster di database Aurora Serverless v1 e modificarla in un secondo momento. Per ulteriori informazioni, consulta [Impostazione della finestra di manutenzione preferita del cluster database](USER_UpgradeDBInstance.Maintenance.md#AdjustingTheMaintenanceWindow.Aurora).
Le finestre di manutenzione vengono utilizzate per gli aggiornamenti programmati delle versioni principali. Le patch e gli aggiornamenti a versioni secondarie vengono applicati immediatamente durante il dimensionamento. Il dimensionamento avviene in base alle impostazioni per `TimeoutAction`:
+ `ForceApplyCapacityChange`: la modifica viene applicata immediatamente.
+ `RollbackCapacityChange`: Aurora aggiorna forzatamente il cluster al massimo dopo 3 giorni dal primo tentativo di patch.
Come per qualsiasi modifica forzata senza un punto di ridimensionamento appropriato, ciò potrebbe interrompere il carico di lavoro.
Quando possibile, Aurora Serverless v1 esegue la manutenzione in modalità non invasiva. Quando è necessaria la manutenzione, il cluster di database Aurora Serverless v1 dimensionerà automaticamente la propria capacità per gestire le operazioni necessarie. Prima di scalare, Aurora Serverless v1 cerca un punto di dimensionamento. Esegue l’operazione per un massimo di sette giorni, se necessario.
Alla fine di ogni giorno che Aurora Serverless v1 non riesce a trovare un punto di dimensionamento, viene creato un evento cluster. Questo evento notifica la manutenzione in sospeso e la necessità di eseguire il dimensionamento per eseguire la manutenzione. La notifica include la data in cui Aurora Serverless v1 può forzare il dimensionamento del cluster di database.
Per ulteriori informazioni, consulta [Operazione di timeout per le modifiche di capacità](#aurora-serverless.how-it-works.timeout-action).
## Aurora Serverless v1 e failover
Se l'istanza DB per un cluster di database Aurora Serverless v1 diventa non disponibile o la zona di disponibilità (AZ) restituisce un errore, Aurora crea nuovamente l'istanza DB in una AZ diversa. Tuttavia, il cluster Aurora Serverless v1 non è un cluster Multi-AZ. Questo perché è costituito da una singola istanza DB in un'unica zona di disponibiità. Perciò, questo meccanismo di failover richiede più tempo rispetto a un cluster Aurora con provisioning o alle istanze Aurora Serverless v2. Il tempo di Aurora Serverless v1 failover non è definito perché dipende dalla domanda e dalla disponibilità di capacità in altri paesi AZs all'interno del dato ambiente. Regione AWS
Poiché Aurora separa la capacità di calcolo e lo storage, il volume di archiviazione per il cluster è distribuito su più livelli. AZs I dati rimangono disponibili anche se un'interruzione riguarda l'istanza DB o la zona di disponibilità associata.
## Aurora Serverless v1 e snapshot
Il volume del cluster per un cluster Aurora Serverless v1 è sempre crittografato. Puoi scegliere la chiave di crittografia, ma non è possibile disabilitare la crittografia. Per copiare o condividere uno snapshot di un cluster Aurora Serverless v1, esegui la crittografia dello snapshot utilizzando la tua AWS KMS key. Per ulteriori informazioni, consulta [Copia di uno snapshot del cluster di database](aurora-copy-snapshot.md). Per ulteriori informazioni sulla crittografia e Amazon Aurora, consulta [Creazione di un cluster di database Amazon Aurora](Overview.Encryption.md#Overview.Encryption.Enabling)
# Creazione di un cluster di database Aurora Serverless v1
**Importante**
AWS ha [annunciato la data di fine del ciclo di vita per Aurora Serverless v1: 31 marzo 2025](https://repost.aws/questions/QUhcMVoChXRm2HLi8F-yih1g/announcement-support-for-aurora-s/announcement-support-for-aurora-serverless-v1-ending-soon). Tutti i cluster Aurora Serverless v1 di cui non è stata effettuata la migrazione entro il 31 marzo 2025 verranno spostati su Aurora Serverless v2 durante la finestra di manutenzione. Se l’aggiornamento non riesce, Amazon Aurora converte il cluster Serverless v1 in un cluster con provisioning con la versione del motore equivalente durante la finestra di manutenzione. Se applicabile, Amazon Aurora registrerà il cluster con provisioning convertito in supporto esteso per Amazon RDS. Per ulteriori informazioni, consulta [Supporto esteso di Amazon RDS con Amazon Aurora](extended-support.md).
Attraverso la seguente procedura crei un cluster Aurora Serverless v1 senza oggetti o dati dello schema. Se invece desideri creare un cluster Aurora Serverless v1 che sia il duplicato di uno con provisioning esistente, oppure un cluster Aurora Serverless v1, esegui l'operazione di ripristino o clonazione degli snapshot. Per ottenere queste informazioni, consulta [Ripristino da uno snapshot cluster database](aurora-restore-snapshot.md) e [Clonazione di un volume per un cluster di database Amazon Aurora](Aurora.Managing.Clone.md). Non è possibile convertire un cluster con provisioning esistente in uno Aurora Serverless v1. Inoltre, non è possibile riconvertire un cluster Aurora Serverless v1 esistente in uno con provisioning.
Quando crei un cluster di database Aurora Serverless v1, puoi impostare una capacità minima e massima. Un’unità di capacità equivale a una specifica configurazione di memoria e calcolo. Aurora Serverless v1 crea regole di dimensionamento basate sulle soglie di utilizzo della CPU, delle connessioni e della memoria disponibile, e scala perfettamente a una delle tante unità di capacità disponibili in base alle esigenze delle tue applicazioni. Per ulteriori informazioni, consulta [Architettura di Aurora Serverless v1](aurora-serverless-v1.how-it-works.md#aurora-serverless.architecture).
È possibile impostare i seguenti valori specifici per il cluster di database Aurora Serverless v1:
+ **Unità di capacità minima di Aurora**: Aurora Serverless v1 può ridurre la capacità fino a questa unità di capacità.
+ **Unità di capacità massima di Aurora**: Aurora Serverless v1 può aumentare la capacità fino a questa unità di capacità.
È inoltre possibile scegliere le seguenti opzioni di configurazione del dimensionamento facoltative:
+ **Forza il dimensionamento della capacità ai valori specificati quando viene raggiunto il timeout**: è possibile scegliere questa impostazione se si desidera che Aurora Serverless v1 forzi Aurora Serverless v1 per il dimensionamento anche se non riesce a trovare un punto di dimensionamento prima del timeout. Se desideri che Aurora Serverless v1 annulli le modifiche di capacità se non riesce a trovare un punto di ridimensionamento, non scegliere questa impostazione. Per ulteriori informazioni, consulta [Operazione di timeout per le modifiche di capacità](aurora-serverless-v1.how-it-works.md#aurora-serverless.how-it-works.timeout-action).
+ **Sospendi la capacità di calcolo dopo minuti consecutivi di inattività**: puoi scegliere questa impostazione se desideri che Aurora Serverless v1 dimensioni a zero quando non è presente alcuna attività nel cluster di database per un periodo di tempo specificato. Con questa impostazione abilitata, il cluster di database Aurora Serverless v1 riprende automaticamente l'elaborazione e si adatta alla capacità necessaria per gestire il carico di lavoro quando il traffico del database riprende. Per ulteriori informazioni, vedi [Sospendi e riprendi per Aurora Serverless v1](aurora-serverless-v1.how-it-works.md#aurora-serverless.how-it-works.pause-resume).
Prima di poter creare un cluster di database Aurora Serverless v1, è necessario un account AWS. È inoltre necessario aver completato le attività di configurazione per lavorare con Amazon Aurora. Per ulteriori informazioni, consulta [Configurazione dell'ambiente per Amazon Aurora](CHAP_SettingUp_Aurora.md). È inoltre necessario completare altre fasi preliminari per la creazione di un cluster di database Aurora. Per ulteriori informazioni, consulta [Creazione di un cluster database Amazon Aurora](Aurora.CreateInstance.md).
Aurora Serverless v1 è disponibile in determinate Regioni AWS solo per versioni specifiche di Aurora MySQL e Aurora PostgreSQL. Per ulteriori informazioni, consulta [Aurora Serverless v1](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV1.md).
**Nota**
Il volume del cluster per un cluster Aurora Serverless v1 è sempre crittografato. Quando crei il cluster di database Aurora Serverless v1, non puoi disattivare la crittografia, ma puoi scegliere di utilizzare la tua chiave di crittografia. Con Aurora Serverless v2, è possibile scegliere se crittografare o meno il volume cluster.
Puoi creare un cluster di database Aurora Serverless v1 utilizzando l’interfaccia AWS CLI o l’API RDS.
**Nota**
Se viene visualizzato il seguente messaggio di errore quando si tenta di creare il cluster, l'account necessita di autorizzazioni aggiuntive.
`Unable to create the resource. Verify that you have permission to create service linked role. Otherwise wait and try again later.`
Per ulteriori informazioni, consulta [Utilizzo di ruoli collegati ai servizi per Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md).
Non puoi connetterti direttamente all'istanza database nel cluster di database Aurora Serverless v1. Per connetterti al cluster di database Aurora Serverless v1, utilizza l'endpoint del database. Puoi trovare l'endpoint per il cluster di database Aurora Serverless v1 nella scheda **Connettività e sicurezza** per il cluster in Console di gestione AWS. Per ulteriori informazioni, consulta [Connessione a un cluster database Amazon Aurora](Aurora.Connecting.md).
## AWS CLI
Per creare un nuovo cluster database Aurora Serverless v1 tramite AWS CLI, esegui il comando [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) e specifica `serverless` per l'opzione `--engine-mode`.
Puoi eventualmente specificare l'opzione `--scaling-configuration` in modo che configuri la capacità minima, quella massima e la pausa automatica quando non sono presenti connessioni.
I seguenti esempi di comando creano un nuovo cluster di database Serverless impostando l'opzione `--engine-mode` su `serverless`. Gli esempi specificano inoltre i valori per l'opzione `--scaling-configuration`.
### Esempio per Aurora MySQL
Il seguente comando creano un nuovo cluster database serverless compatibile con Aurora MySQL. I valori di capacità validi per Aurora MySQL sono `1`, `2`, `4`, `8`, `16`, `32`, `64`, `128` e `256`.
Per Linux, macOS o Unix:
```
aws rds create-db-cluster --db-cluster-identifier sample-cluster \
--engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.4 \
--engine-mode serverless \
--scaling-configuration MinCapacity=4,MaxCapacity=32,SecondsUntilAutoPause=1000,AutoPause=true \
--master-username username --master-user-password password
```
Per Windows:
```
aws rds create-db-cluster --db-cluster-identifier sample-cluster ^
--engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.4 ^
--engine-mode serverless ^
--scaling-configuration MinCapacity=4,MaxCapacity=32,SecondsUntilAutoPause=1000,AutoPause=true ^
--master-username username --master-user-password password
```
### Esempio per Aurora PostgreSQL
Il comando seguente crea un nuovo cluster di database serverless compatibile con PostgreSQL 13.9. I valori di capacità validi per Aurora PostgreSQL sono `2`, `4`, `8`, `16`, `32`, `64`, `192` e `384`.
Per Linux, macOS o Unix:
```
aws rds create-db-cluster --db-cluster-identifier sample-cluster \
--engine aurora-postgresql --engine-version 13.9 \
--engine-mode serverless \
--scaling-configuration MinCapacity=8,MaxCapacity=64,SecondsUntilAutoPause=1000,AutoPause=true \
--master-username username --master-user-password password
```
Per Windows:
```
aws rds create-db-cluster --db-cluster-identifier sample-cluster ^
--engine aurora-postgresql --engine-version 13.9 ^
--engine-mode serverless ^
--scaling-configuration MinCapacity=8,MaxCapacity=64,SecondsUntilAutoPause=1000,AutoPause=true ^
--master-username username --master-user-password password
```
## API RDS
Per creare un nuovo cluster di database Aurora Serverless v1 tramite l'API RDS, esegui l'operazione [CreateDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html) e specifica `serverless` per il parametro `EngineMode`.
Puoi eventualmente specificare il parametro `ScalingConfiguration` in modo che configuri la capacità minima, quella massima e la pausa automatica quando non sono presenti connessioni. I valori di capacità validi includono quanto segue:
+ Aurora MySQL: `1`, `2`, `4`, `8`, `16`, `32`, `64`, `128` e `256`.
+ Aurora PostgreSQL: `2`, `4`, `8`, `16`, `32`, `64`, `192` e `384`.
# Ripristino di un cluster database Aurora Serverless v1
**Importante**
AWS ha [annunciato la data di fine del ciclo di vita per Aurora Serverless v1: 31 marzo 2025](https://repost.aws/questions/QUhcMVoChXRm2HLi8F-yih1g/announcement-support-for-aurora-s/announcement-support-for-aurora-serverless-v1-ending-soon). Tutti i cluster Aurora Serverless v1 di cui non è stata effettuata la migrazione entro il 31 marzo 2025 verranno spostati su Aurora Serverless v2 durante la finestra di manutenzione. Se l’aggiornamento non riesce, Amazon Aurora converte il cluster Serverless v1 in un cluster con provisioning con la versione del motore equivalente durante la finestra di manutenzione. Se applicabile, Amazon Aurora registrerà il cluster con provisioning convertito in supporto esteso per Amazon RDS. Per ulteriori informazioni, consulta [Supporto esteso di Amazon RDS con Amazon Aurora](extended-support.md).
Puoi configurare un cluster di database Aurora Serverless v1 durante il ripristino dello snapshot di un cluster di database con provisioning utilizzando l’interfaccia AWS CLI o l’API RDS.
Quando ripristini uno snapshot in un cluster database Aurora Serverless v1, puoi impostare i seguenti valori specifici:
+ **Unità di capacità minima di Aurora**: Aurora Serverless v1 può ridurre la capacità fino a questa unità di capacità.
+ **Unità di capacità massima di Aurora**: Aurora Serverless v1 può aumentare la capacità fino a questa unità di capacità.
+ **Azione di timeout**: l'azione da eseguire quando una modifica della capacità scade perché non riesce a trovare un punto di dimensionamento. Aurora Serverless v1 Il cluster database può forzare il cluster database alle nuove impostazioni di capacità impostando l'opzione **Forza la capacità di dimensionamento ai valori specificati...**. In alternativa, è possibile ripristinare la modifica della capacità per annullarla se non si sceglie l'opzione. Per ulteriori informazioni, consulta [Operazione di timeout per le modifiche di capacità](aurora-serverless-v1.how-it-works.md#aurora-serverless.how-it-works.timeout-action).
+ **Pause after inactivity** (Pausa dopo inattività): periodo di tempo senza traffico di database trascorso il quale la capacità di calcolo viene ridotta a zero. Quando il traffico di database riprende, Aurora aumenta automaticamente la capacità di calcolo e si dimensiona per gestire il traffico.
Per informazioni generali sul ripristino di un cluster database da uno snapshot, consulta [Ripristino da uno snapshot cluster database](aurora-restore-snapshot.md).
## AWS CLI
Puoi configurare un cluster database Aurora Serverless durante il ripristino della snapshot di un cluster database con provisioning tramite Console di gestione AWS, AWS CLI o l'API RDS.
Quando ripristini uno snapshot in un cluster database Aurora Serverless, puoi impostare i seguenti valori specifici:
+ **Unità di capacità minima di Aurora**: Aurora Serverless può ridurre la capacità fino a questa unità di capacità.
+ **Unità di capacità massima di Aurora**: Aurora Serverless può aumentare la capacità fino a questa unità di capacità.
+ **Azione di timeout**: l'azione da eseguire quando una modifica della capacità scade perché non riesce a trovare un punto di dimensionamento. Aurora Serverless v1 Il cluster database può forzare il cluster database alle nuove impostazioni di capacità impostando l'opzione **Forza la capacità di dimensionamento ai valori specificati...**. In alternativa, è possibile ripristinare la modifica della capacità per annullarla se non si sceglie l'opzione. Per ulteriori informazioni, consulta [Operazione di timeout per le modifiche di capacità](aurora-serverless-v1.how-it-works.md#aurora-serverless.how-it-works.timeout-action).
+ **Pause after inactivity** (Pausa dopo inattività): periodo di tempo senza traffico di database trascorso il quale la capacità di calcolo viene ridotta a zero. Quando il traffico di database riprende, Aurora aumenta automaticamente la capacità di calcolo e si dimensiona per gestire il traffico.
**Nota**
La versione dello snapshot del cluster database deve essere compatibile conAurora Serverless v1. Per l'elenco delle versioni supportate, consulta [Aurora Serverless v1](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV1.md).
Per ripristinare uno snapshot in un cluster Aurora Serverless v1 con compatibilità MySQL 5.7, includi i seguenti parametri aggiuntivi:
+ `--engine aurora-mysql`
+ `--engine-version 5.7`
I parametri `--engine` e `--engine-version` consentono di creare un cluster Aurora Serverless v1 compatibile con MySQL 5.7 da uno snapshot Aurora o Aurora Serverless v1compatibile con MySQL 5.6. Nell'esempio seguente viene ripristinata uno snapshot da un cluster compatibile con MySQL 5.6 denominato *mydbclustersnapshot* in un cluster Aurora Serverless v1 compatibile con MySQL 5.7 denominato *mynewdbcluster*.
Per Linux, macOS o Unix:
```
aws rds restore-db-cluster-from-snapshot \
--db-cluster-identifier mynewdbcluster \
--snapshot-identifier mydbclustersnapshot \
--engine-mode serverless \
--engine aurora-mysql \
--engine-version 5.7
```
Per Windows:
```
aws rds restore-db-cluster-from-snapshot ^
--db-instance-identifier mynewdbcluster ^
--db-snapshot-identifier mydbclustersnapshot ^
--engine aurora-mysql ^
--engine-version 5.7
```
Puoi eventualmente specificare l'opzione `--scaling-configuration` in modo che configuri la capacità minima, quella massima e la pausa automatica quando non sono presenti connessioni. I valori di capacità validi includono quanto segue:
+ Aurora MySQL: `1`, `2`, `4`, `8`, `16`, `32`, `64`, `128` e `256`.
+ Aurora PostgreSQL: `2`, `4`, `8`, `16`, `32`, `64`, `192` e `384`.
Nell'esempio seguente viene eseguito il ripristino da uno snapshot del cluster di database creato in precedenza denominato *mydbclustersnapshot* in un nuovo cluster di database denominato *mynewdbcluster*. È possibile impostare `--scaling-configuration` in modo che il nuovo cluster Aurora Serverless v1 DB può dimensionare da 8 ACU a 64 ACU (unità di capacità Aurora) in base alle esigenze per elaborare il carico di lavoro. Al termine dell'elaborazione e dopo 1000 secondi senza connessioni da supportare, il cluster si arresta fino a quando le richieste di connessione non richiedono il riavvio.
Per Linux, macOS o Unix:
```
aws rds restore-db-cluster-from-snapshot \
--db-cluster-identifier mynewdbcluster \
--snapshot-identifier mydbclustersnapshot \
--engine-mode serverless --scaling-configuration MinCapacity=8,MaxCapacity=64,TimeoutAction='ForceApplyCapacityChange',SecondsUntilAutoPause=1000,AutoPause=true
```
Per Windows:
```
aws rds restore-db-cluster-from-snapshot ^
--db-instance-identifier mynewdbcluster ^
--db-snapshot-identifier mydbclustersnapshot ^
--engine-mode serverless --scaling-configuration MinCapacity=8,MaxCapacity=64,TimeoutAction='ForceApplyCapacityChange',SecondsUntilAutoPause=1000,AutoPause=true
```
## API RDS
Per configurare un cluster database Aurora Serverless v1 durante un ripristino da un cluster database tramite l'API RDS, esegui l'operazione [RestoreDBClusterFromSnapshot](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterFromSnapshot.html) e specifica `serverless` per il parametro `EngineMode`.
Puoi eventualmente specificare il parametro `ScalingConfiguration` in modo che configuri la capacità minima, quella massima e la pausa automatica quando non sono presenti connessioni. I valori di capacità validi includono quanto segue:
+ Aurora MySQL: `1`, `2`, `4`, `8`, `16`, `32`, `64`, `128` e `256`.
+ Aurora PostgreSQL: `2`, `4`, `8`, `16`, `32`, `64`, `192` e `384`.
# Modifica di un cluster di database Aurora Serverless v1
**Importante**
AWS ha [annunciato la end-of-life data delAurora Serverless v1: 31 marzo 2025](https://repost.aws/questions/QUhcMVoChXRm2HLi8F-yih1g/announcement-support-for-aurora-s/announcement-support-for-aurora-serverless-v1-ending-soon). Tutti i cluster Aurora Serverless v1 non migrati entro il 31 marzo 2025 verranno spostati su Aurora Serverless v2 durante la finestra di manutenzione. Se l’aggiornamento non riesce, Amazon Aurora converte il cluster Serverless v1 in un cluster con provisioning con la versione del motore equivalente durante la finestra di manutenzione. Se applicabile, Amazon Aurora registrerà il cluster con provisioning convertito in Supporto esteso di Amazon RDS. Per ulteriori informazioni, consulta [Supporto esteso di Amazon RDS con Amazon Aurora](extended-support.md).
Dopo aver configurato un cluster Aurora Serverless v1 DB, è possibile modificare determinate proprietà con Console di gestione AWS, the o l' AWS CLI API RDS. La maggior parte delle proprietà che puoi modificare sono le stesse di altri tipi di cluster Aurora.
Di seguito sono riportate le modifiche più importanti di Aurora Serverless v1:
+ [Modifica della configurazione di dimensionamento](#aurora-serverless.modifying.scaling)
+ [Aggiornamento della versione principale](#aurora-serverless.modifying.upgrade)
+ [Conversione da istanza Aurora Serverless v1 in istanza con provisioning](#aurora-serverless.modifying.convert)
## Modifica della configurazione di dimensionamento di un cluster di database Aurora Serverless v1
Puoi impostare le capacità minima e massima per il cluster di database. Ogni unità di capacità equivale a una specifica configurazione di memoria e calcolo. Aurora Serverless crea automaticamente regole di dimensionamento in base alle soglie per utilizzo della CPU, connessioni e memoria disponibile. Puoi anche specificare se Aurora Serverless sospende il database in assenza di attività e lo ripristina quando l'attività ricomincia.
Puoi impostare i seguenti valori specifici per la configurazione di dimensionamento:
+ **Unità di capacità minima di Aurora**: Aurora Serverless può ridurre la capacità fino a questa unità di capacità.
+ **Unità di capacità massima di Aurora**: Aurora Serverless può aumentare la capacità fino a questa unità di capacità.
+ **Il timeout e l'operazione di scalabilità automatica**: questa sezione specifica per quanto tempo Aurora Serverlessattende di trovare un punto di dimensionamento prima del timeout. Specifica anche l'operazione da eseguire quando una modifica della capacità raggiunge il timeout perché non riesce a trovare un punto di dimensionamento. Aurora può forzare la modifica della capacità per impostare la capacità sul valore specificato non appena possibile. Oppure, può eseguire il rollback della modifica della capacità per annullarla. Per ulteriori informazioni, consulta [Operazione di timeout per le modifiche di capacità](aurora-serverless-v1.how-it-works.md#aurora-serverless.how-it-works.timeout-action).
+ **Pausa dopo l'inattività**: utilizza l'impostazione opzionale **Ridimensiona la capacità a 0 ACUs quando il cluster è inattivo** per ridimensionare il database fino a una capacità di elaborazione pari a zero mentre è inattivo. Quando il traffico di database riprende, Aurora aumenta automaticamente la capacità di calcolo e si dimensiona per gestire il traffico.
**Nota**
Quando si modifica l'intervallo di capacità per un cluster database Aurora Serverless, la modifica viene implementata subito, indipendentemente dal fatto che si scelga di applicarla immediatamente o durante la successiva finestra di manutenzione pianificata.
### Console
Puoi modificare la configurazione di dimensionamento di un cluster di database Aurora dalla Console di gestione AWS.
**Per modificare un cluster di database Aurora Serverless v1**
1. Aprire la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Nel pannello di navigazione, scegliere **Databases (Database)**.
1. Seleziona il cluster di database Aurora Serverless v1 che desideri modificare.
1. Per **Actions (Operazioni)**, scegliere **Modify cluster (Modifica cluster)**.
1. Nella sezione **Capacity settings (Impostazioni di capacità)**, modificare la configurazione di dimensionamento.
1. Scegli **Continua**.
1. Nella pagina **Modifica il cluster DB** rivedi le modifiche apportate, quindi scegli quando applicarle.
1. Scegliere **Modify cluster (Modifica cluster)**.
### AWS CLI
Per modificare la configurazione di scalabilità di un cluster Aurora Serverless v1 DB utilizzando il, esegui il AWS CLI comando. [modify-db-cluster](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/rds/modify-db-cluster.html) AWS CLI Specifica l'opzione `--scaling-configuration` in modo che configuri la capacità minima, quella massima e la pausa automatica quando non sono presenti connessioni. I valori di capacità validi includono quanto segue:
+ Aurora MySQL: `1`, `2`, `4`, `8`, `16`, `32`, `64`, `128` e `256`.
+ Aurora PostgreSQL: `2`, `4`, `8`, `16`, `32`, `64`, `192` e `384`.
In questo esempio, si modifica la configurazione di scalabilità di un cluster Aurora Serverless v1 DB denominato. *sample-cluster*
Per Linux, macOS o Unix:
```
aws rds modify-db-cluster \
--db-cluster-identifier sample-cluster \
--scaling-configuration MinCapacity=8,MaxCapacity=64,SecondsUntilAutoPause=500,TimeoutAction='ForceApplyCapacityChange',AutoPause=true
```
Per Windows:
```
aws rds modify-db-cluster ^
--db-cluster-identifier sample-cluster ^
--scaling-configuration MinCapacity=8,MaxCapacity=64,SecondsUntilAutoPause=500,TimeoutAction='ForceApplyCapacityChange',AutoPause=true
```
### API RDS
È possibile modificare la configurazione di scalabilità di un cluster Aurora DB con [l'](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html)operazione DBCluster Modify API. Specifica il parametro `ScalingConfiguration` in modo che configuri la capacità minima, quella massima e la pausa automatica quando non sono presenti connessioni. I valori di capacità validi includono quanto segue:
+ Aurora MySQL: `1`, `2`, `4`, `8`, `16`, `32`, `64`, `128` e `256`.
+ Aurora PostgreSQL: `2`, `4`, `8`, `16`, `32`, `64`, `192` e `384`.
## Aggiornamento della versione principale di un cluster di database Aurora Serverless v1
**Importante**
AWS ha [annunciato la end-of-life data delAurora Serverless v1: 31 marzo 2025](https://repost.aws/questions/QUhcMVoChXRm2HLi8F-yih1g/announcement-support-for-aurora-s/announcement-support-for-aurora-serverless-v1-ending-soon). Tutti i cluster Aurora Serverless v1 non migrati entro il 31 marzo 2025 verranno spostati su Aurora Serverless v2 durante la finestra di manutenzione. Se l’aggiornamento non riesce, Amazon Aurora converte il cluster Serverless v1 in un cluster con provisioning con la versione del motore equivalente durante la finestra di manutenzione. Se applicabile, Amazon Aurora registrerà il cluster con provisioning convertito in Supporto esteso di Amazon RDS. Per ulteriori informazioni, consulta [Supporto esteso di Amazon RDS con Amazon Aurora](extended-support.md).
Puoi aggiornare la versione principale per un cluster database Aurora Serverless v1 compatibile con PostgreSQL 11 a una versione corrispondente compatibile con PostgreSQL 13.
### Console
Puoi eseguire un aggiornamento locale di un cluster di database Aurora Serverless v1 usando la Console di gestione AWS.
**Per aggiornare un cluster di database Aurora Serverless v1**
1. Aprire la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Nel pannello di navigazione, seleziona **Database**.
1. Seleziona il cluster di database Aurora Serverless v1 che desideri aggiornare.
1. Per **Actions (Operazioni)**, scegliere **Modify cluster (Modifica cluster)**.
1. In **Versione**, scegli 13 come numero di versione di Aurora PostgreSQL.
Il seguente esempio mostra un aggiornamento locale da Aurora PostgreSQL 11.16 a 13.9.
![\[Aggiornamento di un cluster di database Aurora Serverless v1 mediante la console\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/sv1-upgrade-apg11-to-13.png)
Se esegui un aggiornamento della versione principale, non modificare tutte le altre proprietà. Per modificare una qualsiasi delle altre proprietà, esegui un'operazione **Modifica** al termine dell'aggiornamento.
1. Scegli **Continua**.
1. Nella pagina **Modifica il cluster DB** rivedi le modifiche apportate, quindi scegli quando applicarle.
1. Scegliere **Modify cluster (Modifica cluster)**.
### AWS CLI
Per eseguire un aggiornamento locale da un cluster di database Aurora Serverless v1 compatibile con PostgreSQL 11 a uno compatibile con PostgreSQL 13, specifica il parametro `--engine-version` con un numero di versione Aurora PostgreSQL versione 13 compatibile con Aurora Serverless v1. Includi anche il parametro `--allow-major-version-upgrade`.
In questo esempio, viene modificata la versione principale di un cluster database Aurora Serverless v1 compatibile con PostgreSQL 11 denominata `sample-cluster`. Questo consente di eseguire un aggiornamento locale a un cluster di database Aurora Serverless v1 compatibile con PostgreSQL 13.
```
aws rds modify-db-cluster \
--db-cluster-identifier sample-cluster \
--engine-version 13.serverless_12 \
--allow-major-version-upgrade
```
Per Windows:
```
aws rds modify-db-cluster ^
--db-cluster-identifier sample-cluster ^
--engine-version 13.serverless_12 ^
--allow-major-version-upgrade
```
### API RDS
Per eseguire un aggiornamento locale da un cluster di database Aurora Serverless v1 compatibile con PostgreSQL 11 a uno compatibile con PostgreSQL 13, specifica il parametro `EngineVersion` con un numero di versione Aurora PostgreSQL versione 13 compatibile con Aurora Serverless v1. Includi anche il parametro `AllowMajorVersionUpgrade`.
## Conversione di cluster di database Aurora Serverless v1 in allocato
Puoi convertire un cluster di database Aurora Serverless v1 in un cluster di database allocato. **Per eseguire la conversione, utilizza la AWS CLI o l'API Amazon RDS per modificare la classe dell'istanza DB in Provisioned.** Utilizza i passaggi seguenti per modificare la classe dell’istanza database.
L'esempio seguente dimostra come utilizzare la AWS CLI per convertire Aurora Serverless v1 un cluster DB in un cluster con provisioning.
### AWS CLI
Per convertire un cluster Aurora Serverless v1 DB in un cluster con provisioning, esegui il comando. [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) AWS CLI
I parametri seguenti sono obbligatori:
+ `--db-cluster-identifier`: il cluster di database Aurora Serverless v1 che stai convertendo in allocato.
+ `--engine-mode`: usa il valore `provisioned`.
+ `--allow-engine-mode-change`
+ `--db-cluster-instance-class`: scegli la classe di istanza database per il cluster di database allocato in base alla capacità del cluster di database Aurora Serverless v1.
In questo esempio, si converte un cluster di database Aurora Serverless v1 denominato `sample-cluster` e si utilizza la classe di istanza database `db.r5.xlarge`.
Per Linux, macOS o Unix:
```
aws rds modify-db-cluster \
--db-cluster-identifier sample-cluster \
--engine-mode provisioned \
--allow-engine-mode-change \
--db-cluster-instance-class db.r5.xlarge
```
Per Windows:
```
aws rds modify-db-cluster ^
--db-cluster-identifier sample-cluster ^
--engine-mode provisioned ^
--allow-engine-mode-change ^
--db-cluster-instance-class db.r5.xlarge
```
L’esempio seguente dimostra come utilizzare l’API Amazon RDS per convertire un cluster di database Aurora Serverless v1 in un cluster con provisioning.
### API RDS
Per convertire un cluster Aurora Serverless v1 DB in un cluster con provisioning, utilizzate l'operazione [Modify DBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) API.
I parametri seguenti sono obbligatori:
+ `DBClusterIdentifier`: il cluster di database Aurora Serverless v1 che stai convertendo in allocato.
+ `EngineMode`: usa il valore `provisioned`.
+ `AllowEngineModeChange`
+ `DBClusterInstanceClass`: scegli la classe di istanza database per il cluster di database allocato in base alla capacità del cluster di database Aurora Serverless v1.
## Considerazioni sulla conversione da un cluster di database Aurora Serverless v1 a un cluster con provisioning
Le seguenti considerazioni si applicano alla conversione da un cluster di database Aurora Serverless v1 a un cluster con provisioning.
+ Puoi utilizzare questa conversione come parte dell'aggiornamento del tuo cluster di database da Aurora Serverless v1 a Aurora Serverless v2. Per ulteriori informazioni, consulta [Aggiornamento da un cluster Aurora Serverless v1 ad Aurora Serverless v2](aurora-serverless-v2.upgrade.md#aurora-serverless-v2.upgrade-from-serverless-v1-procedure).
+ Il processo di conversione crea un'istanza database di lettura nel cluster di database, promuove l'istanza di lettura in un'istanza di scrittura ed elimina l'istanza Aurora Serverless v1 originale. Quando si converte il cluster di database, non è possibile eseguire altre modifiche contemporaneamente, ad esempio la modifica della versione del motore di database o del gruppo di parametri del cluster di database. L'operazione di conversione viene applicata immediatamente e non può essere annullata.
+ Durante la conversione, viene acquisito uno snapshot del cluster di database di backup in caso di errore. L'identificatore per lo snapshot del cluster di database ha il formato `pre-modify-engine-mode-DB_cluster_identifier-timestamp`.
+ Aurora utilizza la versione secondaria predefinita corrente del motore di database per il cluster di database allocato.
+ Se non fornisci una classe di istanza database per il cluster di database convertito, Aurora ne consiglia una in base alla capacità massima del cluster di database Aurora Serverless v1 originale. La capacità consigliata per le mappature delle classi di istanza è illustrata nella tabella seguente.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/aurora-serverless.modifying.html)
**Nota**
A seconda della classe di istanza database scelta e dell'utilizzo del database, è possibile che vengano calcolati costi diversi per un cluster di database allocato rispetto a Aurora Serverless v1.
Se converti il tuo cluster di database Aurora Serverless v1 in una classe di istanza database (db.t\$1) espandibile, potresti incorrere in costi aggiuntivi per l'utilizzo del cluster di database. Per ulteriori informazioni, consulta [Tipi di classi di istanza database](Concepts.DBInstanceClass.Types.md).
# Dimensionamento manuale della capacità del cluster database Aurora Serverless v1
**Importante**
AWS ha [annunciato la data di fine del ciclo di vita per Aurora Serverless v1: 31 marzo 2025](https://repost.aws/questions/QUhcMVoChXRm2HLi8F-yih1g/announcement-support-for-aurora-s/announcement-support-for-aurora-serverless-v1-ending-soon). Tutti i cluster Aurora Serverless v1 di cui non è stata effettuata la migrazione entro il 31 marzo 2025 verranno spostati su Aurora Serverless v2 durante la finestra di manutenzione. Se l’aggiornamento non riesce, Amazon Aurora converte il cluster Serverless v1 in un cluster con provisioning con la versione del motore equivalente durante la finestra di manutenzione. Se applicabile, Amazon Aurora registrerà il cluster con provisioning convertito in supporto esteso per Amazon RDS. Per ulteriori informazioni, consulta [Supporto esteso di Amazon RDS con Amazon Aurora](extended-support.md).
In genere, i cluster database Aurora Serverless v1 vengono dimensionati senza problemi in base al carico di lavoro. Tuttavia, la capacità potrebbe non essere sempre dimensionata in maniera rapida da soddisfare estremi improvvisi, come ad esempio un aumento esponenziale delle transazioni. In questi casi è possibile avviare manualmente l'operazione di dimensionamento impostando un nuovo valore di capacità. Dopo aver impostato la capacità esplicitamente, Aurora Serverless v1 può dimensionare automaticamente il cluster database. Esegue questa operazione in base al periodo di attesa per la riduzione.
Puoi impostare la capacità di un cluster database Aurora Serverless v1 su un valore specifico con Console di gestione AWS, AWS CLI o l'API RDS.
## Console
Puoi impostare le capacità di un cluster database Aurora dalla Console di gestione AWS.
**Per modificare un cluster database Aurora Serverless v1**
1. Apri la console Amazon RDS all'indirizzo [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Nel riquadro di navigazione, scegliere **Databases** (Database).
1. Seleziona il cluster database Aurora Serverless v1 che desideri modificare.
1. Per **Actions (Operazioni)**, selezionare **Set capacity (Imposta capacità)**.
1. Nella finestra **Dimensionamento della capacità del database** seleziona quanto segue:
1. Per il selettore a discesa **Scale DB cluster to** (Dimensionamento del cluster database a), seleziona la nuova capacità desiderata per il cluster database.
1. Nella casella di controllo **If a seamless scaling point cannot be found** (Se non è possibile trovare un punto di ridimensionamento senza soluzione di continuità...), scegli il comportamento desiderato per il tuo cluster database Aurora Serverless v1 in base all’impostazione di `TimeoutAction`, come riportato di seguito:
+ Deseleziona questa opzione se desideri che la capacità rimanga invariata se Aurora Serverless v1 non riesce a trovare un punto di ridimensionamento prima del timeout.
+ Seleziona questa opzione se desideri forzare la modifica della capacità del cluster database Aurora Serverless v1 anche se non riesce a trovare un punto di ridimensionamento prima del timeout. Questa opzione può comportare l'eliminazione delle connessioni Aurora Serverless v1 che impediscono di trovare un punto di ridimensionamento.
1. Nel campo **seconds** (secondi) specifica per quanto tempo il cluster database Aurora Serverless v1 può cercare un punto di dimensionamento prima del timeout. Puoi specificare un qualsiasi valore compreso tra 10 e 600 secondi (10 minuti). L'impostazione predefinita è 5 minuti (300 secondi). In questo esempio si impone al cluster database Aurora Serverless v1 di eseguire il dimensionamento verso il basso fino a 2 ACU anche se non riesce a trovare un punto di ridimensionamento entro cinque minuti.
![\[Impostazione della capacità per un cluster database Aurora Serverless v1 con la console\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-serverless-set-capacity.png)
1. Scegliere **Apply (Applica)**.
Per ulteriori informazioni sui punti di ridimensionamento, `TimeoutAction`, e sui periodi di tempo di recupero, consulta [Scalabilità automatica per Aurora Serverless v1](aurora-serverless-v1.how-it-works.md#aurora-serverless.how-it-works.auto-scaling).
## AWS CLI
Per impostare la capacità di un cluster database Aurora Serverless v1 tramite AWS CLI, emetti il comando AWS CLI [modify-current-db-cluster-capacity](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-current-db-cluster-capacity.html) e specifica l'opzione `--capacity`. I valori di capacità validi includono quanto segue:
+ Aurora MySQL: `1`, `2`, `4`, `8`, `16`, `32`, `64`, `128` e `256`.
+ Aurora PostgreSQL: `2`, `4`, `8`, `16`, `32`, `64`, `192` e `384`.
In questo esempio, viene impostata la capacità di un cluster database Aurora Serverless v1 denominato *sample-cluster* su *64*.
```
aws rds modify-current-db-cluster-capacity --db-cluster-identifier sample-cluster --capacity 64
```
## API RDS
Puoi impostare le capacità di un cluster database Aurora con l'operazione API [ModifyCurrentDBClusterCapacity](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyCurrentDBClusterCapacity.html). Specifica il parametro `Capacity`. I valori di capacità validi includono quanto segue:
+ Aurora MySQL: `1`, `2`, `4`, `8`, `16`, `32`, `64`, `128` e `256`.
+ Aurora PostgreSQL: `2`, `4`, `8`, `16`, `32`, `64`, `192` e `384`.
# Visualizzazione dei cluster database Aurora Serverless v1
**Importante**
AWS ha [annunciato la data di fine del ciclo di vita per Aurora Serverless v1: 31 marzo 2025](https://repost.aws/questions/QUhcMVoChXRm2HLi8F-yih1g/announcement-support-for-aurora-s/announcement-support-for-aurora-serverless-v1-ending-soon). Tutti i cluster Aurora Serverless v1 di cui non è stata effettuata la migrazione entro il 31 marzo 2025 verranno spostati su Aurora Serverless v2 durante la finestra di manutenzione. Se l’aggiornamento non riesce, Amazon Aurora converte il cluster Serverless v1 in un cluster con provisioning con la versione del motore equivalente durante la finestra di manutenzione. Se applicabile, Amazon Aurora registrerà il cluster con provisioning convertito in supporto esteso per Amazon RDS. Per ulteriori informazioni, consulta [Supporto esteso di Amazon RDS con Amazon Aurora](extended-support.md).
Dopo aver creato uno o più cluster database Aurora Serverless v1, puoi visualizzare quali cluster database sono di tipo **Serverless** e quali di tipo **Istanza**. Puoi anche visualizzare il numero corrente di unità di capacità di Aurora (ACU) utilizzate da ogni cluster database Aurora Serverless v1. Ogni ACU è la combinazione di capacità di calcolo (CPU) e memoria (RAM).
**Per visualizzare i cluster database Aurora Serverless v1**
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. Nell'angolo in alto a destra della Console di gestione AWS, seleziona la Regione AWS in cui hai creato i cluster database Aurora Serverless v1.
1. Nel riquadro di navigazione, scegli **Databases** (Database).
Per ogni cluster database, il tipo viene indicato su **Role (Ruolo)**. I cluster database Aurora Serverless v1 mostrano **Serverless** per il tipo. Puoi visualizzare la capacità corrente di un cluster database Aurora Serverless v1 in **Dimensione**.
![\[Visualizzazione dei cluster database Aurora Serverless v1\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-serverless-viewing.png)
1. Seleziona il nome di un cluster database Aurora Serverless v1 per visualizzarne i dettagli.
Nella scheda **Connettività e sicurezza**, prendi nota dell'endpoint del database. Utilizza questo endpoint per connetterti al cluster database Aurora Serverless v1.
![\[Visualizzazione dell'endpoint del database del cluster database Aurora Serverless v1\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-serverless-endpoint.png)
Seleziona la scheda **Configurazione** per visualizzare le impostazioni di capacità.
![\[Visualizzazione delle impostazioni della capacità del cluster database Aurora Serverless v1\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-serverless-capacity-settings.png)
Viene generato un *evento di dimensionamento *quando il cluster database aumenta o riduce il dimensionamento, viene messo in pausa o ripristinato. Selezionare la scheda **Logs & events (Log ed eventi)** per visualizzare gli eventi recenti. La seguente immagine mostra esempi di tali eventi.
![\[Visualizzazione delle impostazioni della capacità del cluster database Aurora Serverless v1\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-serverless-scaling.png)
## Monitoraggio della capacità e dimensionamento degli eventi per il cluster database Aurora Serverless v1
Puoi visualizzare il cluster database Aurora Serverless v1 in CloudWatch per monitorare la capacità allocata al cluster database con il parametro `ServerlessDatabaseCapacity`. Inoltre, puoi monitorare tutti i parametri standard Aurora CloudWatch come `CPUUtilization`, `DatabaseConnections`, `Queries` e così via.
Puoi fare in modo che Aurora pubblichi alcuni o tutti i log di database su CloudWatch. Puoi selezionare i log da pubblicare abilitando [parametri di configurazione come `general_log` e `slow_query_log` nel gruppo di parametri del cluster di database](aurora-serverless-v1.how-it-works.md#aurora-serverless.parameter-groups) associato al cluster Aurora Serverless v1. A differenza dei cluster con provisioning, i cluster Aurora Serverless v1 non richiedono la specifica nelle impostazioni del cluster database dei tipi di log da caricare in CloudWatch. I cluster Aurora Serverless v1 caricano automaticamente tutti i log disponibili. Quando disabiliti un parametro di configurazione del log, la pubblicazione del log su CloudWatch si arresta. Puoi anche eliminare i log in CloudWatch se non sono più necessari.
Per iniziare a utilizzare Amazon CloudWatch per il tuo cluster database Aurora Serverless v1, consulta [Visualizzazione dei Aurora Serverless v1 log con Amazon CloudWatch](aurora-serverless-v1.how-it-works.md#aurora-serverless.logging.monitoring). Per ulteriori informazioni su come monitorare i cluster database Aurora attraverso CloudWatch, consulta [Monitoraggio degli eventi di log in Amazon CloudWatch](AuroraMySQL.Integrating.CloudWatch.md#AuroraMySQL.Integrating.CloudWatch.Monitor).
Per la connessione a un cluster database Aurora Serverless v1, utilizza l'endpoint di database. Per ulteriori informazioni, consulta [Connessione a un cluster database Amazon Aurora](Aurora.Connecting.md).
**Nota**
Non puoi connetterti direttamente a istanze database specifiche nei cluster database Aurora Serverless v1.
# Eliminazione di un cluster di database Aurora Serverless v1
**Importante**
AWS ha [annunciato la data di fine del ciclo di vita per Aurora Serverless v1: 31 marzo 2025](https://repost.aws/questions/QUhcMVoChXRm2HLi8F-yih1g/announcement-support-for-aurora-s/announcement-support-for-aurora-serverless-v1-ending-soon). Tutti i cluster Aurora Serverless v1 di cui non è stata effettuata la migrazione entro il 31 marzo 2025 verranno spostati su Aurora Serverless v2 durante la finestra di manutenzione. Se l’aggiornamento non riesce, Amazon Aurora converte il cluster Serverless v1 in un cluster con provisioning con la versione del motore equivalente durante la finestra di manutenzione. Se applicabile, Amazon Aurora registrerà il cluster con provisioning convertito in supporto esteso per Amazon RDS. Per ulteriori informazioni, consulta [Supporto esteso di Amazon RDS con Amazon Aurora](extended-support.md).
A seconda di come viene creato un cluster di database Aurora Serverless v1, la protezione dall’eliminazione potrebbe essere attivata per impostazione predefinita. Non è possibile eliminare immediatamente un cluster di database Aurora Serverless v1 in cui è abilitata la **protezione dall’eliminazione**. Per eliminare cluster database Aurora Serverless v1 con protezione dall'eliminazione utilizzando Console di gestione AWS, modifica innanzitutto il cluster per rimuovere questa protezione. Per informazioni sull'utilizzo di AWS CLI per questa attività, consulta [AWS CLI](#aurora-serverless.delete.cli).
**Per disabilitare la protezione dall'eliminazione tramite Console di gestione AWS**
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. Nel pannello di navigazione, seleziona **DB clusters** (Cluster database).
1. Seleziona il cluster database Aurora Serverless v1 dall'elenco.
1. Seleziona **Modifica** per aprire la configurazione del cluster database. La pagina Modifica cluster database consente di visualizzare le impostazioni, le impostazioni della capacità e altri dettagli di configurazione per il cluster database Aurora Serverless v1. La protezione dall'eliminazione è disponibile nella sezione **Additional configuration** (Configurazione aggiuntiva).
1. Deseleziona l'opzione **Enable deletion protection** (Abilita protezione eliminazione) nella scheda delle proprietà **Additional configuration** (Configurazione aggiuntive).
1. Scegli **Continue** (Continua). Viene visualizzato il **Riepilogo delle modifiche** .
1. Seleziona **Modifica cluster** per accettare il riepilogo delle modifiche. Puoi inoltre scegliere **Indietro** per modificare le modifiche o **Annulla** per ignorarle.
Una volta disattivata la protezione dall'eliminazione, potrai eliminare il cluster database Aurora Serverless v1 utilizzando Console di gestione AWS.
## Console
**Per eliminare un cluster database Aurora Serverless v1**
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. Nella sezione **Risorse** seleziona **Cluster database**.
1. Seleziona il cluster database Aurora Serverless v1 che desideri eliminare.
1. In **Actions (Azioni)**, selezionare **Delete (Elimina)**. Verrà richiesto di confermare che si desidera eliminare il cluster database Aurora Serverless v1.
1. Si consiglia di mantenere le opzioni preselezionate:
+ **Sì** per **Crea snapshot finale**
+ Il nome del cluster database Aurora Serverless v1 più `-final-snapshot` per **Nome snapshot finale**. Tuttavia, puoi modificare il nome della snapshot finale in questo campo.
![\[Schermata di eliminazione del cluster database Aurora Serverless v1\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/aurora-sles-delete-db-1.png)
Se scegli **No** per **Crea snapshot finale** non potrai ripristinare il cluster database utilizzando le snapshot o il ripristino point-in-time.
1. Seleziona **Elimina cluster database**.
Aurora Serverless v1 elimina il cluster di database. Se decidi di avere uno snapshot finale, lo stato del cluster database Aurora Serverless v1 diventa "Backup in corso" prima che venga eliminato e non viene più visualizzato nell'elenco.
## AWS CLI
Prima di iniziare, configura AWS CLI con l'ID chiave di accesso di AWS, la chiave di accesso segreta di AWS e la Regione AWS in cui si trova il cluster database Aurora Serverless v1. Per ulteriori informazioni, consulta [i passaggi di base della configurazione](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) nella Guida per l'utente di AWS Command Line Interface.
Non puoi eliminare un cluster database Aurora Serverless v1 fino a quando disattivi la protezione dall'eliminazione per i cluster configurati con questa opzione. Se provi a eliminare un cluster con questa opzione di protezione attivata, viene visualizzato il seguente messaggio di errore.
```
1. An error occurred (InvalidParameterCombination) when calling the DeleteDBCluster
2. operation: Cannot delete protected Cluster, please disable deletion protection and try again.
```
Puoi modificare l'impostazione di protezione da eliminazione del cluster database Aurora Serverless v1 utilizzando il comando AWS CLI comando [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) come riportato di seguito:
```
aws rds modify-db-cluster --db-cluster-identifier your-cluster-name --no-deletion-protection
```
Con questo comando vengono restituite le proprietà revisionate per il cluster database specificato. Adesso puoi eliminare il cluster database Aurora Serverless v1.
Consigliamo di creare sempre uno snapshot finale ogni volta che si elimina un cluster database Aurora Serverless v1. Il seguente esempio di utilizzo del comando AWS CLI [delete-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/delete-db-cluster.html) mostra come completare questa operazione. Specifica il nome del cluster database e un nome per la snapshot.
Per Linux, macOS o Unix:
```
aws rds delete-db-cluster --db-cluster-identifier \
your-cluster-name --no-skip-final-snapshot \
--final-db-snapshot-identifier name-your-snapshot
```
Per Windows:
```
aws rds delete-db-cluster --db-cluster-identifier ^
your-cluster-name --no-skip-final-snapshot ^
--final-db-snapshot-identifier name-your-snapshot
```
# Versioni del motore del database di Aurora Serverless v1 e Aurora
**Importante**
AWS ha [annunciato la end-of-life data delAurora Serverless v1: 31 marzo 2025](https://repost.aws/questions/QUhcMVoChXRm2HLi8F-yih1g/announcement-support-for-aurora-s/announcement-support-for-aurora-serverless-v1-ending-soon). Tutti i cluster Aurora Serverless v1 non migrati entro il 31 marzo 2025 verranno spostati su Aurora Serverless v2 durante la finestra di manutenzione. Se l’aggiornamento non riesce, Amazon Aurora converte il cluster Serverless v1 in un cluster con provisioning con la versione del motore equivalente durante la finestra di manutenzione. Se applicabile, Amazon Aurora registrerà il cluster con provisioning convertito in Supporto esteso di Amazon RDS. Per ulteriori informazioni, consulta [Supporto esteso di Amazon RDS con Amazon Aurora](extended-support.md).
Aurora Serverless v1è disponibile solo in alcune versioni di Aurora MySQL Regioni AWS e Aurora PostgreSQL e Aurora PostgreSQL. Per l'elenco aggiornato di Regioni AWS tale supporto Aurora Serverless v1 e le versioni specifiche di Aurora MySQL e Aurora PostgreSQL disponibili in ciascuna regione, vedere. [Aurora Serverless v1](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV1.md)
Aurora Serverless v1 utilizza il motore del database Aurora associato per identificare le release supportate specifiche per ogni motore del database supportato, come segue:
+ Aurora MySQL Serverless
+ Aurora PostgreSQL Serverless
Quando una release secondaria dei motori di database diventa disponibile per Aurora Serverless v1, viene applicata automaticamente nelle varie Regioni AWS in cui è disponibile Aurora Serverless v1. In altre parole, non è necessario aggiornare il cluster database Aurora Serverless v1 per ottenere una nuova release secondaria per il motore del database del cluster se è disponibile per Aurora Serverless v1.
## Aurora MySQL Serverless
Aurora Serverless v1è disponibile solo in alcune versioni di Aurora MySQL Regioni AWS e solo per specifiche. Per l'elenco aggiornato di Regioni AWS tale supporto Aurora Serverless v1 e le versioni specifiche di Aurora MySQL disponibili in ciascuna regione, vedere. [Aurora Serverless v1 con Aurora MySQL](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV1.md#Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV1.amy)
Per informazioni sui miglioramenti e sulle correzioni di bug per la versione 2 di Aurora MySQL, consulta [Aggiornamenti del motore del database per Amazon Aurora MySQL versione 2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.Updates.20Updates.html) nelle *Note di rilascio di Aurora MySQL*.
Per utilizzare una versione più recente di Aurora MySQL, puoi utilizzare Aurora Serverless v2. Per le versioni di MySQL Regioni AWS e Aurora utilizzabili, consulta. Aurora Serverless v2 [Aurora Serverless v2 con Aurora MySQL](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV2.md#Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV2.amy) Per informazioni sull’utilizzo di Aurora Serverless v2, consulta [Uso di Aurora Serverless v2](aurora-serverless-v2.md).
## Aurora PostgreSQL Serverless
Aurora Serverless v1è disponibile solo in alcune versioni di Aurora PostgreSQL Regioni AWS e solo per specifiche. Per l'elenco aggiornato di Regioni AWS tale supporto Aurora Serverless v1 e le versioni specifiche di Aurora PostgreSQL disponibili in ciascuna regione, consulta. [Aurora Serverless v1 con Aurora PostgreSQL](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV1.md#Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV1.apg)
Se desideri utilizzare Aurora PostgreSQL per il cluster di database Aurora Serverless v1, puoi scegliere tra le versioni compatibili con Aurora PostgreSQL 13. Le release secondarie per Aurora edizione compatibile con PostgreSQL includono solo le modifiche compatibili con le versioni precedenti. Il cluster database Aurora Serverless v1 viene aggiornato in modo trasparente quando una release secondaria di Aurora PostgreSQL diventa disponibile per Aurora Serverless v1 nella tua Regione AWS.
Per utilizzare una versione più recente di Aurora PostgreSQL, puoi utilizzare Aurora Serverless v2. Per le versioni PostgreSQL Regioni AWS e Aurora utilizzabili, consulta. Aurora Serverless v2 [Aurora Serverless v2 con Aurora PostgreSQL](Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV2.md#Concepts.Aurora_Fea_Regions_DB-eng.Feature.ServerlessV2.apg) Per informazioni sull’utilizzo di Aurora Serverless v2, consulta [Uso di Aurora Serverless v2](aurora-serverless-v2.md).
## Aggiornamenti automatici a versioni secondarie per Aurora Serverless v1
Quando sono disponibili versioni minori dei motori di databaseAurora Serverless v1, queste vengono applicate automaticamente nei vari Regioni AWS luoghi in cui sono disponibili. Aurora Serverless v1 In altre parole, non è necessario aggiornare il cluster database Aurora Serverless v1 per ottenere una nuova release secondaria per il motore del database del cluster se è disponibile per Aurora Serverless v1.