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à.
# Riavvio di un cluster Amazon Aurora DB o di un'istanza Amazon Aurora DB
Potrebbe essere necessario riavviare il cluster DB o alcune istanze all'interno del cluster, di solito per motivi di manutenzione. Ad esempio, si supponga di modificare i parametri all'interno di un gruppo di parametri o di associare un gruppo di parametri diverso al cluster. In questi casi, è necessario riavviare il cluster affinché le modifiche abbiano effetto. Analogamente, è possibile riavviare una o più istanze DB di lettura all'interno del cluster. È possibile organizzare le operazioni di riavvio per singole istanze per ridurre al minimo i tempi di inattività per l'intero cluster.
Il tempo necessario per riavviare ogni istanza DB nel cluster dipende dall'attività del database al momento del riavvio. Dipende anche dal processo di ripristino dello specifico motore di DB. Se è pratico, ridurre l'attività del database su quella particolare istanza prima di avviare il processo di riavvio. In questo modo è possibile ridurre il tempo necessario per riavviare il database.
È possibile riavviare ogni istanza DB nel cluster solo quando è nello stato disponibile. Un'istanza database può non essere disponibile per vari motivi. Questi includono lo stato di arresto del cluster, una modifica applicata all'istanza e un'azione della finestra di manutenzione, ad esempio un aggiornamento della versione.
Il riavvio di un'istanza database comporta il riavvio del processo del motore di database. Il riavvio di un'istanza database comporta un'interruzione temporanea, durante la quale lo stato dell'istanza database viene impostato su *rebooting (riavvio in corso)*.
**Nota**
Se l'istanza database non usa le modifiche più recenti apportate al gruppo di parametri database associato, la Console di gestione AWS mostra il gruppo di parametri database con stato **pending-reboot (riavvio in attesa)**. Lo stato dei gruppi di parametro **pending-reboot** non prevede un riavvio automatico nel corso della prossima finestra di manutenzione. Per applicare le ultime modifiche del parametro su quella istanza database, riavviare manualmente l’istanza database. Per ulteriori informazioni sui gruppi di parametri, consultare [Gruppi di parametri per Amazon Aurora](USER_WorkingWithParamGroups.md).
**Topics**
+ [Riavvio di un'istanza database in un cluster Aurora](aurora-reboot-db-instance.md)
+ [Riavvio di un cluster Aurora con disponibilità di lettura](aurora-mysql-survivable-replicas.md)
+ [Riavvio di un cluster Aurora senza disponibilità di lettura](aurora-reboot-cluster.md)
+ [Verifica del tempo di attività per i cluster e le istanze Aurora](USER_Reboot.Uptime.md)
+ [Esempi di operazioni di riavvio Aurora](USER_Reboot.Examples.md)
# Riavvio di un'istanza database in un cluster Aurora
Questa procedura è l'operazione più importante che si esegue durante il riavvio con Aurora. Molte delle procedure di manutenzione prevedono il riavvio di una o più istanze database Aurora in un determinato ordine.
## Console
**Per riavviare un'istanza database**
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 riquadro di navigazione, scegliere **Databases (Database)** e l'istanza DB da riavviare.
1. In **Actions (Operazioni)**, scegliere **Reboot (Riavvia)**.
Viene visualizzata la pagina **Reboot DB Instance (Riavvia istanza DB)**.
1. Scegliere **Reboot (Riavvia)** per riavviare l'istanza DB.
Oppure scegliere **Cancel (Annulla)**.
## AWS CLI
Per riavviare un'istanza database tramite AWS CLI, chiamare il comando [https://docs.aws.amazon.com/cli/latest/reference/rds/reboot-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/reboot-db-instance.html).
**Example**
Per Linux, macOS o Unix:
```
aws rds reboot-db-instance \
--db-instance-identifier mydbinstance
```
Per Windows:
```
aws rds reboot-db-instance ^
--db-instance-identifier mydbinstance
```
## API RDS
Per riavviare un'istanza DB tramite l'API Amazon RDS, chiamare l'operazione [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RebootDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RebootDBInstance.html).
# Riavvio di un cluster Aurora con disponibilità di lettura
Se si utilizza la funzionalità della disponibilità di lettura, è possibile riavviare l’istanza di scrittura del cluster Aurora senza riavviare le istanze di lettura nel cluster di database primario o secondario. In questo modo si contribuisce a mantenere alta la disponibilità del cluster per le operazioni di lettura durante il riavvio dell'istanza di scrittura. È possibile riavviare le istanze di lettura in un secondo momento, secondo una pianificazione adatta a te. Ad esempio, per un cluster di produzione, è possibile riavviare le istanze di lettura una alla volta, iniziando solo dopo il completamento del riavvio dell’istanza primaria. Per ogni istanza DB che si riavvia, attenersi alla procedura in [Riavvio di un'istanza database in un cluster Aurora](aurora-reboot-db-instance.md).
La funzionalità della disponibilità di lettura per i cluster di database primari è disponibile in Aurora MySQL 2.10 e versioni successive. La disponibilità di lettura per i cluster di database secondari è disponibile in Aurora MySQL 3.06 e versioni successive.
Per Aurora PostgreSQL, questa funzione è disponibile per impostazione predefinita per le seguenti versioni:
+ 15.2 o versioni successive alla 15
+ 14.7 o versioni successive alla 14
+ 13.10 o versioni successive alla 13
+ 12.14 e versioni successive alla 12
Per ulteriori informazioni sulla funzionalità della disponibilità di lettura in Aurora PostgreSQL, consulta [Miglioramento della disponibilità di lettura delle repliche Aurora](AuroraPostgreSQL.Replication.md#AuroraPostgreSQL.Replication.Replicas.SRO).
Prima di questa funzionalità, il riavvio dell’istanza primaria causava contemporaneamente un riavvio per ogni istanza di lettura. Se il cluster Aurora sta eseguendo una versione precedente, utilizzare invece la procedura di riavvio in [Riavvio di un cluster Aurora senza disponibilità di lettura](aurora-reboot-cluster.md).
**Nota**
La modifica del comportamento di riavvio nei cluster di database Aurora con la funzionalità della disponibilità di lettura è diversa per i database Aurora MySQL precedenti alla versione 3.06 Se si riavvia l'istanza di scrittura per il cluster principale in un database globale Aurora, le istanze di lettura nel cluster primario rimangono disponibili. Tuttavia, le istanze database in qualsiasi cluster secondario si riavviano contemporaneamente.
Una versione limitata della funzionalità di disponibilità in lettura migliorata è supportata dai database globali Aurora PostgreSQL versioni 12.16, 13.12, 14.9, 15.4 e versioni successive.
Si riavvia spesso il cluster dopo aver apportato modifiche ai gruppi di parametri del cluster. È possibile apportare modifiche ai parametri seguendo le procedure in [Gruppi di parametri per Amazon Aurora](USER_WorkingWithParamGroups.md). Si supponga di riavviare l'istanza database di scrittura in un cluster Aurora per applicare le modifiche ai parametri del cluster. Alcune o tutte le istanze database di lettura potrebbero continuare a utilizzare le vecchie impostazioni dei parametri. Tuttavia, le diverse impostazioni dei parametri non influiscono sull'integrità dei dati del cluster. Tutti i parametri del cluster che influiscono sull'organizzazione dei file di dati vengono utilizzati solo dall'istanza database di scrittura.
Ad esempio, in un cluster Aurora MySQL è possibile aggiornare i parametri del cluster come `binlog_format` e `innodb_purge_threads` sull'istanza di scrittura prima delle istanze di lettura. Solo l'istanza di scrittura sta scrivendo registri binari e eliminando i record di annullamento. Per i parametri che modificano il modo in cui le query interpretano le istruzioni SQL o l'output della query, potrebbe essere necessario fare attenzione nel riavviare immediatamente le istanze di lettura. Lo si fa per evitare comportamenti imprevisti dell'applicazione durante le query. Ad esempio, supponiamo di modificare il parametro `lower_case_table_names` e di riavviare l'istanza di scrittura. In questo caso, le istanze di lettura potrebbero non essere in grado di accedere a una tabella appena creata finché non vengono tutte riavviate.
Per un elenco di tutti i parametri del cluster Aurora MySQL, consulta [Parametri a livello di cluster](AuroraMySQL.Reference.ParameterGroups.md#AuroraMySQL.Reference.Parameters.Cluster).
Per un elenco di tutti i parametri per cluster Aurora MySQL, consulta [Parametri a livello di cluster Aurora PostgreSQL](AuroraPostgreSQL.Reference.ParameterGroups.md#AuroraPostgreSQL.Reference.Parameters.Cluster).
**Suggerimento**
Aurora MySQL potrebbe comunque riavviare alcune istanze di lettura insieme all'istanza di scrittura se il cluster sta elaborando un carico di lavoro con un throughput elevato.
La riduzione del numero di riavvii si applica anche durante le operazioni di failover. Aurora MySQL riavvia solo l'istanza database di scrittura e la destinazione del failover durante un failover. Altre istanze DB di lettura nel cluster rimangono disponibili per continuare a elaborare le query tramite connessioni all'endpoint di lettura. Pertanto, è possibile migliorare la disponibilità durante un failover se è presente più di un'istanza database di lettura in un cluster.
# Riavvio di un cluster Aurora senza disponibilità di lettura
Se non si utilizza la funzionalità della disponibilità di lettura, è possibile riavviare l'intero cluster database Aurora riavviando l'istanza database di scrittura di tale cluster. A tale scopo, segui la procedura in [Riavvio di un'istanza database in un cluster Aurora](aurora-reboot-db-instance.md).
Il riavvio dell'istanza DB di scrittura avvia anche un riavvio per ogni istanza DB di lettura nel cluster. In questo modo, tutte le modifiche dei parametri a livello di cluster vengono applicate contemporaneamente a tutte le istanze DB. Tuttavia, il riavvio di tutte le istanze DB causa una breve interruzione del cluster. Le istanze DB di lettura rimangono non disponibili fino a quando l'istanza DB di scrittura termina il riavvio e diventa disponibile.
Questo comportamento di riavvio si applica a tutti i cluster database creati in Aurora MySQL versione 2.09 e precedenti.
Per Aurora PostgreSQL questo comportamento si applica alle seguenti versioni:
+ 14.6 e versioni precedenti alla 14
+ 13.9 e versioni precedenti alla 13
+ 12.13 e versioni precedenti alla 12
+ Tutte le versioni di PostgreSQL 11
Nella console RDS, l'istanza DB scrittore ha il valore **Writer (Di scrittura)** nella colonna **Role (Ruolo)** nella pagina **Database (Database)**. Nella CLI di RDS, l'output del comando `describe-db-clusters` include una sezione `DBClusterMembers`. L'elemento `DBClusterMembers` che rappresenta l'istanza DB di scrittura ha un valore di `true` per il campo `IsClusterWriter`.
**Importante**
Con la funzionalità della disponibilità di lettura, il comportamento di riavvio è diverso in Aurora MySQL e Aurora PostgreSQL: le istanze database di lettura in genere rimangono disponibili durante il riavvio dell'istanza di scrittura. Quindi è possibile riavviare le istanze di lettura al momento opportuno. È possibile riavviare le istanze di lettura con una pianificazione scaglionata se si desidera che alcune istanze di lettura siano sempre disponibili. Per ulteriori informazioni, consulta [Riavvio di un cluster Aurora con disponibilità di lettura](aurora-mysql-survivable-replicas.md).
# Verifica del tempo di attività per i cluster e le istanze Aurora
È possibile controllare e monitorare il periodo di tempo dall'ultimo riavvio per ogni istanza database nel cluster Aurora. Il CloudWatch parametro Amazon `EngineUptime` riporta il numero di secondi trascorsi dall'ultima volta in cui è stata avviata un'istanza DB. È possibile esaminare questo parametro in un point-in-time per scoprire il tempo di attività per l'istanza database. È inoltre possibile monitorare il parametro nel tempo per rilevare quando l'istanza viene riavviata.
È altresì possibile esaminare il parametro `EngineUptime` a livello del cluster. Le dimensioni `Minimum` e `Maximum` segnalano i valori di attività minori e maggiori per tutte le istanze database nel cluster. Per verificare l'ultima volta in cui una qualsiasi istanza di lettura in un cluster è stata riavviata, o riavviata per un altro motivo, monitorare il parametro a livello di cluster utilizzando la dimensione `Minimum`. Per verificare quale istanza nel cluster è durata più a lungo senza un riavvio, monitorare il parametro a livello di cluster utilizzando la dimensione `Maximum`. Ad esempio, è possibile confermare che tutte le istanze database nel cluster siano state riavviate dopo una modifica della configurazione.
**Suggerimento**
Per il monitoraggio a lungo termine, si consiglia di monitorare il parametro `EngineUptime` per singole istanze anziché a livello di cluster. Il parametro `EngineUptime` a livello di cluster viene impostato su zero quando viene aggiunta una nuova istanza database al cluster. Tali modifiche del cluster possono avvenire nell'ambito di operazioni di manutenzione e dimensionamento come quelle eseguite da Auto Scaling.
Gli esempi di CLI riportati di seguito mostrano come esaminare i parametro `EngineUptime` per le istanze di scrittura e lettura in un cluster. Gli esempi utilizzano un cluster denominato `tpch100g`. Questo cluster ha un'istanza database di scrittura `instance-1234`. Dispone inoltre di due istanze database di lettura `instance-7448` e `instance-6305`.
Innanzitutto, il comando `reboot-db-instance` riavvia una delle istanze di lettura. Il comando `wait` attende fino al termine del riavvio dell'istanza.
```
$ aws rds reboot-db-instance --db-instance-identifier instance-6305
{
"DBInstance": {
"DBInstanceIdentifier": "instance-6305",
"DBInstanceStatus": "rebooting",
...
$ aws rds wait db-instance-available --db-instance-id instance-6305
```
Il CloudWatch `get-metric-statistics` comando esamina la `EngineUptime` metrica negli ultimi cinque minuti a intervalli di un minuto. Il tempo di attività dell'istanza `instance-6305` viene ripristinato a zero e ricomincia a contare verso l'alto. Questo AWS CLI esempio per Linux utilizza la sostituzione `$()` delle variabili per inserire i timestamp appropriati nei comandi CLI. Utilizza anche il comando Linux `sort` per ordinare l'output nel momento in cui è stato raccolto il parametro. Il valore del timestamp è il terzo campo di ogni riga di output.
```
$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
--start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" \
--period 60 --namespace "AWS/RDS" --statistics Maximum \
--dimensions Name=DBInstanceIdentifier,Value=instance-6305 --output text \
| sort -k 3
EngineUptime
DATAPOINTS 231.0 2021-03-16T18:19:00+00:00 Seconds
DATAPOINTS 291.0 2021-03-16T18:20:00+00:00 Seconds
DATAPOINTS 351.0 2021-03-16T18:21:00+00:00 Seconds
DATAPOINTS 411.0 2021-03-16T18:22:00+00:00 Seconds
DATAPOINTS 471.0 2021-03-16T18:23:00+00:00 Seconds
```
Il tempo di attività minimo per il cluster viene ripristinato a zero perché una delle istanze del cluster è stata riavviata. Il tempo di attività massimo per il cluster non viene ripristinato perché almeno una delle istanze database nel cluster è rimasta disponibile.
```
$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
--start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" \
--period 60 --namespace "AWS/RDS" --statistics Minimum \
--dimensions Name=DBClusterIdentifier,Value=tpch100g --output text \
| sort -k 3
EngineUptime
DATAPOINTS 63099.0 2021-03-16T18:12:00+00:00 Seconds
DATAPOINTS 63159.0 2021-03-16T18:13:00+00:00 Seconds
DATAPOINTS 63219.0 2021-03-16T18:14:00+00:00 Seconds
DATAPOINTS 63279.0 2021-03-16T18:15:00+00:00 Seconds
DATAPOINTS 51.0 2021-03-16T18:16:00+00:00 Seconds
$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
--start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" \
--period 60 --namespace "AWS/RDS" --statistics Maximum \
--dimensions Name=DBClusterIdentifier,Value=tpch100g --output text \
| sort -k 3
EngineUptime
DATAPOINTS 63389.0 2021-03-16T18:16:00+00:00 Seconds
DATAPOINTS 63449.0 2021-03-16T18:17:00+00:00 Seconds
DATAPOINTS 63509.0 2021-03-16T18:18:00+00:00 Seconds
DATAPOINTS 63569.0 2021-03-16T18:19:00+00:00 Seconds
DATAPOINTS 63629.0 2021-03-16T18:20:00+00:00 Seconds
```
Quindi un altro comando `reboot-db-instance` riavvia l'istanza di scrittura del cluster. Un altro comando `wait` si interrompe fino al termine del riavvio dell'istanza di scrittura.
```
$ aws rds reboot-db-instance --db-instance-identifier instance-1234
{
"DBInstanceIdentifier": "instance-1234",
"DBInstanceStatus": "rebooting",
...
$ aws rds wait db-instance-available --db-instance-id instance-1234
```
Ora il parametro `EngineUptime` per l'istanza di scrittura mostra che l'istanza `instance-1234` è stata riavviata di recente. Anche l'istanza di lettura `instance-6305` è stata riavviata automaticamente insieme all'istanza di scrittura. Questo cluster esegue Aurora MySQL 2.09, il che non mantiene le istanze di lettura in esecuzione al riavvio dell'istanza di scrittura.
```
$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
--start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" \
--period 60 --namespace "AWS/RDS" --statistics Maximum \
--dimensions Name=DBInstanceIdentifier,Value=instance-1234 --output text \
| sort -k 3
EngineUptime
DATAPOINTS 63749.0 2021-03-16T18:22:00+00:00 Seconds
DATAPOINTS 63809.0 2021-03-16T18:23:00+00:00 Seconds
DATAPOINTS 63869.0 2021-03-16T18:24:00+00:00 Seconds
DATAPOINTS 41.0 2021-03-16T18:25:00+00:00 Seconds
DATAPOINTS 101.0 2021-03-16T18:26:00+00:00 Seconds
$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
--start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" \
--period 60 --namespace "AWS/RDS" --statistics Maximum \
--dimensions Name=DBInstanceIdentifier,Value=instance-6305 --output text \
| sort -k 3
EngineUptime
DATAPOINTS 411.0 2021-03-16T18:22:00+00:00 Seconds
DATAPOINTS 471.0 2021-03-16T18:23:00+00:00 Seconds
DATAPOINTS 531.0 2021-03-16T18:24:00+00:00 Seconds
DATAPOINTS 49.0 2021-03-16T18:26:00+00:00 Seconds
```
# Esempi di operazioni di riavvio Aurora
Gli esempi Aurora MySQL seguenti mostrano diverse combinazioni di operazioni di riavvio per le istanze database di lettura e scrittura in un cluster DB Aurora. Dopo ogni riavvio, le query SQL dimostrano il tempo di attività per le istanze nel cluster.
**Topics**
+ [Individuazione delle istanze di scrittore e lettore per un cluster Aurora](#USER_Reboot.Examples.IsClusterWriter)
+ [Riavvio di una singola istanza di lettura](#USER_Reboot.Examples.RebootReader)
+ [Riavvio dell'istanza di scrittura](#USER_Reboot.Examples.RebootWriter)
+ [Riavvio indipendente di scrittore e lettori](#USER_Reboot.Examples.RebootAsynch)
+ [Applicazione di una modifica dei parametri del cluster a un cluster Aurora MySQL versione 2.10](#USER_Reboot.Examples.ParamChangeNewStyle)
## Individuazione delle istanze di scrittore e lettore per un cluster Aurora
In un cluster Aurora MySQL con più istanze database, è importante sapere quale è lo scrittore e quali sono i lettori. Le istanze di scrittura e lettura possono anche cambiare ruolo quando si verifica un'operazione di failover. Pertanto, è meglio eseguire un controllo come il seguente prima di eseguire qualsiasi operazione che richieda un'istanza di scrittura o lettura. In questo caso, i valori `False` per `IsClusterWriter` identificano le istanze di lettura `instance-6305` e `instance-7448`. Il valore `True` identifica l'istanza di scrittura, `instance-1234`.
```
$ aws rds describe-db-clusters --db-cluster-id tpch100g \
--query "*[].['Cluster:',DBClusterIdentifier,DBClusterMembers[*].['Instance:',DBInstanceIdentifier,IsClusterWriter]]" \
--output text
Cluster: tpch100g
Instance: instance-6305 False
Instance: instance-7448 False
Instance: instance-1234 True
```
Prima di iniziare gli esempi di riavvio, l'istanza di scrittura ha un tempo di attività di circa una settimana. La query SQL in questo esempio mostra un modo specifico di MySQL per controllare il tempo di attività. È possibile utilizzare questa tecnica in un'applicazione di database. Per un'altra tecnica che utilizza AWS CLI e funziona per entrambi i motori Aurora, consulta [Verifica del tempo di attività per i cluster e le istanze Aurora](USER_Reboot.Uptime.md).
```
$ mysql -h instance-7448.a12345.us-east-1.rds.amazonaws.com -P 3306 -u my-user -p
...
mysql> select date_sub(now(), interval variable_value second) "Last Startup",
-> time_format(sec_to_time(variable_value),'%Hh %im') as "Uptime"
-> from performance_schema.global_status
-> where variable_name='Uptime';
+----------------------------+---------+
| Last Startup | Uptime |
+----------------------------+---------+
| 2021-03-08 17:49:06.000000 | 174h 42m|
+----------------------------+---------+
```
## Riavvio di una singola istanza di lettura
Questo esempio riavvia una delle istanze DB di lettura. Probabilmente questa istanza è stata sovraccaricata da una query sovradimensionata o da molte connessioni simultanee. Oppure è rimasta indietro rispetto all'istanza di scrittura a causa di un problema di rete. Dopo aver avviato l'operazione di riavvio, l'esempio utilizza un comando `wait` per sospendere fino a quando l'istanza non diventa disponibile. A quel punto, l'istanza ha un tempo di attività di alcuni minuti.
```
$ aws rds reboot-db-instance --db-instance-identifier instance-6305
{
"DBInstance": {
"DBInstanceIdentifier": "instance-6305",
"DBInstanceStatus": "rebooting",
...
}
}
$ aws rds wait db-instance-available --db-instance-id instance-6305
$ mysql -h instance-6305.a12345.us-east-1.rds.amazonaws.com -P 3306 -u my-user -p
...
mysql> select date_sub(now(), interval variable_value second) "Last Startup",
-> time_format(sec_to_time(variable_value),'%Hh %im') as "Uptime"
-> from performance_schema.global_status
-> where variable_name='Uptime';
+----------------------------+---------+
| Last Startup | Uptime |
+----------------------------+---------+
| 2021-03-16 00:35:02.000000 | 00h 03m |
+----------------------------+---------+
```
Il riavvio dell'istanza di lettura non ha influito sul tempo di attività dell'istanza di scrittura. Ha ancora un tempo di attività di circa una settimana.
```
$ mysql -h instance-7448.a12345.us-east-1.rds.amazonaws.com -P 3306 -u my-user -p
...
mysql> select date_sub(now(), interval variable_value second) "Last Startup",
-> time_format(sec_to_time(variable_value),'%Hh %im') as "Uptime"
-> from performance_schema.global_status where variable_name='Uptime';
+----------------------------+----------+
| Last Startup | Uptime |
+----------------------------+----------+
| 2021-03-08 17:49:06.000000 | 174h 49m |
+----------------------------+----------+
```
## Riavvio dell'istanza di scrittura
Questo esempio riavvia l'istanza di scrittura. Questo cluster esegue Aurora MySQL versione 2.09. Poiché la versione Aurora MySQL è inferiore alla 2.10, il riavvio dell'istanza di scrittura riavvia anche le istanze di lettura nel cluster.
Un comando `wait` si interrompe fino al termine del riavvio. Ora il tempo di attività per quell'istanza viene ripristinato a zero. È possibile che un'operazione di riavvio possa richiedere tempi sostanzialmente diversi per le istanze DB di scrittura e lettura. Le istanze database di scrittura e lettura eseguono diversi tipi di operazioni di pulizia a seconda dei ruoli.
```
$ aws rds reboot-db-instance --db-instance-identifier instance-1234
{
"DBInstance": {
"DBInstanceIdentifier": "instance-1234",
"DBInstanceStatus": "rebooting",
...
}
}
$ aws rds wait db-instance-available --db-instance-id instance-1234
$ mysql -h instance-1234.a12345.us-east-1.rds.amazonaws.com -P 3306 -u my-user -p
...
mysql> select date_sub(now(), interval variable_value second) "Last Startup",
-> time_format(sec_to_time(variable_value),'%Hh %im') as "Uptime"
-> from performance_schema.global_status where variable_name='Uptime';
+----------------------------+---------+
| Last Startup | Uptime |
+----------------------------+---------+
| 2021-03-16 00:40:27.000000 | 00h 00m |
+----------------------------+---------+
```
Dopo il riavvio per l'istanza database di scrittura, entrambe le istanze database di lettura hanno anche il ripristino del tempo di attività. Il riavvio dell'istanza di scrittura ha causato il riavvio delle istanze di lettura. Questo comportamento si applica ai cluster Aurora PostgreSQL e ai cluster Aurora MySQL prima della versione 2.10.
```
$ mysql -h instance-7448.a12345.us-east-1.rds.amazonaws.com -P 3306 -u my-user -p
...
mysql> select date_sub(now(), interval variable_value second) "Last Startup",
-> time_format(sec_to_time(variable_value),'%Hh %im') as "Uptime"
-> from performance_schema.global_status where variable_name='Uptime';
+----------------------------+---------+
| Last Startup | Uptime |
+----------------------------+---------+
| 2021-03-16 00:40:35.000000 | 00h 00m |
+----------------------------+---------+
$ mysql -h instance-6305.a12345.us-east-1.rds.amazonaws.com -P 3306 -u my-user -p
...
mysql> select date_sub(now(), interval variable_value second) "Last Startup",
-> time_format(sec_to_time(variable_value),'%Hh %im') as "Uptime"
-> from performance_schema.global_status where variable_name='Uptime';
+----------------------------+---------+
| Last Startup | Uptime |
+----------------------------+---------+
| 2021-03-16 00:40:33.000000 | 00h 01m |
+----------------------------+---------+
```
## Riavvio indipendente di scrittore e lettori
Gli esempi seguenti mostrano un cluster che esegue Aurora MySQL versione 2.10. In questa versione Aurora MySQL e versioni successive, è possibile riavviare l'istanza di scrittura senza causare il riavvio per tutte le istanze di lettura. In questo modo, le applicazioni a uso intensivo di query non subiscono interruzioni quando si riavvia l'istanza di scrittura. È possibile riavviare le istanze di lettura in un secondo momento. È possibile eseguire questi riavvii in un momento di scarso traffico di query. È inoltre possibile riavviare le istanze di lettura una alla volta. In questo modo, almeno un'istanza di lettura è sempre disponibile per il traffico di query dell'applicazione.
Nell'esempio seguente viene utilizzato un cluster denominato `cluster-2393`, che esegue Aurora MySQL versione `5.7.mysql_aurora.2.10.0`. Questo cluster ha un'istanza di scrittura denominata `instance-9404` e tre istanze di lettura denominate `instance-6772`, `instance-2470` e `instance-5138`.
```
$ aws rds describe-db-clusters --db-cluster-id cluster-2393 \
--query "*[].['Cluster:',DBClusterIdentifier,DBClusterMembers[*].['Instance:',DBInstanceIdentifier,IsClusterWriter]]" \
--output text
Cluster: cluster-2393
Instance: instance-5138 False
Instance: instance-2470 False
Instance: instance-6772 False
Instance: instance-9404 True
```
Il controllo del valore `uptime` di ogni istanza di database tramite il comando `mysql` mostra che ognuna ha approssimativamente lo stesso tempo di attività. Ad esempio, ecco il tempo di attività per `instance-5138`.
```
mysql> SHOW GLOBAL STATUS LIKE 'uptime';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Uptime | 3866 |
+---------------+-------+
```
Utilizzando CloudWatch, possiamo ottenere le informazioni relative al tempo di attività senza accedere effettivamente alle istanze. In questo modo, un amministratore può monitorare il database ma non può visualizzare o modificare alcun dato della tabella. In tal caso, specifichiamo un periodo di tempo che dura cinque minuti e controlliamo il valore del tempo di attività ogni minuto. I valori di attività crescenti dimostrano che le istanze non sono state riavviate durante quel periodo.
```
$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
--start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
--namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-9404 \
--output text | sort -k 3
EngineUptime
DATAPOINTS 4648.0 2021-03-17T23:42:00+00:00 Seconds
DATAPOINTS 4708.0 2021-03-17T23:43:00+00:00 Seconds
DATAPOINTS 4768.0 2021-03-17T23:44:00+00:00 Seconds
DATAPOINTS 4828.0 2021-03-17T23:45:00+00:00 Seconds
DATAPOINTS 4888.0 2021-03-17T23:46:00+00:00 Seconds
$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
--start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
--namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-6772 \
--output text | sort -k 3
EngineUptime
DATAPOINTS 4315.0 2021-03-17T23:42:00+00:00 Seconds
DATAPOINTS 4375.0 2021-03-17T23:43:00+00:00 Seconds
DATAPOINTS 4435.0 2021-03-17T23:44:00+00:00 Seconds
DATAPOINTS 4495.0 2021-03-17T23:45:00+00:00 Seconds
DATAPOINTS 4555.0 2021-03-17T23:46:00+00:00 Seconds
```
Ora riavviamo una delle istanze di lettura, `instance-5138`. Aspettiamo che l'istanza diventi nuovamente disponibile dopo il riavvio. Ora il monitoraggio del tempo di attività per un periodo di cinque minuti mostra che il tempo di attività è stato ripristinato a zero durante quel periodo. Il valore di attività più recente è stato misurato cinque secondi dopo il completamento del riavvio.
```
$ aws rds reboot-db-instance --db-instance-identifier instance-5138
{
"DBInstanceIdentifier": "instance-5138",
"DBInstanceStatus": "rebooting"
}
$ aws rds wait db-instance-available --db-instance-id instance-5138
$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
--start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
--namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-5138 \
--output text | sort -k 3
EngineUptime
DATAPOINTS 4500.0 2021-03-17T23:46:00+00:00 Seconds
DATAPOINTS 4560.0 2021-03-17T23:47:00+00:00 Seconds
DATAPOINTS 4620.0 2021-03-17T23:48:00+00:00 Seconds
DATAPOINTS 4680.0 2021-03-17T23:49:00+00:00 Seconds
DATAPOINTS 5.0 2021-03-17T23:50:00+00:00 Seconds
```
Successivamente, eseguiamo un riavvio per l'istanza di scrittur, `instance-9404`. Confrontiamo i valori di attività per l'istanza di scrittura e una delle istanze di lettura. Così facendo, possiamo vedere che il riavvio dello scrittore non ha causato un riavvio per i lettori. Nelle versioni precedenti a Aurora MySQL 2.10, i valori di attività per tutti i lettori sarebbero stati reimpostati contemporaneamente allo scrittore.
```
$ aws rds reboot-db-instance --db-instance-identifier instance-9404
{
"DBInstanceIdentifier": "instance-9404",
"DBInstanceStatus": "rebooting"
}
$ aws rds wait db-instance-available --db-instance-id instance-9404
$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
--start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
--namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-9404 \
--output text | sort -k 3
EngineUptime
DATAPOINTS 371.0 2021-03-17T23:57:00+00:00 Seconds
DATAPOINTS 431.0 2021-03-17T23:58:00+00:00 Seconds
DATAPOINTS 491.0 2021-03-17T23:59:00+00:00 Seconds
DATAPOINTS 551.0 2021-03-18T00:00:00+00:00 Seconds
DATAPOINTS 37.0 2021-03-18T00:01:00+00:00 Seconds
$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
--start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
--namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-6772 \
--output text | sort -k 3
EngineUptime
DATAPOINTS 5215.0 2021-03-17T23:57:00+00:00 Seconds
DATAPOINTS 5275.0 2021-03-17T23:58:00+00:00 Seconds
DATAPOINTS 5335.0 2021-03-17T23:59:00+00:00 Seconds
DATAPOINTS 5395.0 2021-03-18T00:00:00+00:00 Seconds
DATAPOINTS 5455.0 2021-03-18T00:01:00+00:00 Seconds
```
Per assicurarsi che tutte le istanze di lettura abbiano le stesse modifiche ai parametri di configurazione dell'istanza di scrittura, riavviare tutte le istanze di lettura dopo quelle di scrittura. Questo esempio riavvia tutti i lettori e quindi attende che tutti siano disponibili prima di procedere.
```
$ aws rds reboot-db-instance --db-instance-identifier instance-6772
{
"DBInstanceIdentifier": "instance-6772",
"DBInstanceStatus": "rebooting"
}
$ aws rds reboot-db-instance --db-instance-identifier instance-2470
{
"DBInstanceIdentifier": "instance-2470",
"DBInstanceStatus": "rebooting"
}
$ aws rds reboot-db-instance --db-instance-identifier instance-5138
{
"DBInstanceIdentifier": "instance-5138",
"DBInstanceStatus": "rebooting"
}
$ aws rds wait db-instance-available --db-instance-id instance-6772
$ aws rds wait db-instance-available --db-instance-id instance-2470
$ aws rds wait db-instance-available --db-instance-id instance-5138
```
Ora possiamo vedere che l'istanza database di scrittura ha il tempo di attività più alto. Il valore di attività di questa istanza è aumentato costantemente durante tutto il periodo di monitoraggio. Le istanze database di lettura sono state tutte riavviate dopo il lettore. Possiamo vedere il punto nel periodo di monitoraggio in cui ogni lettore è stato riavviato e il suo tempo di attività è stato ripristinato a zero.
```
$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
--start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
--namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-9404 \
--output text | sort -k 3
EngineUptime
DATAPOINTS 457.0 2021-03-18T00:08:00+00:00 Seconds
DATAPOINTS 517.0 2021-03-18T00:09:00+00:00 Seconds
DATAPOINTS 577.0 2021-03-18T00:10:00+00:00 Seconds
DATAPOINTS 637.0 2021-03-18T00:11:00+00:00 Seconds
DATAPOINTS 697.0 2021-03-18T00:12:00+00:00 Seconds
$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
--start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
--namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-2470 \
--output text | sort -k 3
EngineUptime
DATAPOINTS 5819.0 2021-03-18T00:08:00+00:00 Seconds
DATAPOINTS 35.0 2021-03-18T00:09:00+00:00 Seconds
DATAPOINTS 95.0 2021-03-18T00:10:00+00:00 Seconds
DATAPOINTS 155.0 2021-03-18T00:11:00+00:00 Seconds
DATAPOINTS 215.0 2021-03-18T00:12:00+00:00 Seconds
$ aws cloudwatch get-metric-statistics --metric-name "EngineUptime" \
--start-time "$(date -d '5 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
--namespace "AWS/RDS" --statistics Minimum --dimensions Name=DBInstanceIdentifier,Value=instance-5138 \
--output text | sort -k 3
EngineUptime
DATAPOINTS 1085.0 2021-03-18T00:08:00+00:00 Seconds
DATAPOINTS 1145.0 2021-03-18T00:09:00+00:00 Seconds
DATAPOINTS 1205.0 2021-03-18T00:10:00+00:00 Seconds
DATAPOINTS 49.0 2021-03-18T00:11:00+00:00 Seconds
DATAPOINTS 109.0 2021-03-18T00:12:00+00:00 Seconds
```
## Applicazione di una modifica dei parametri del cluster a un cluster Aurora MySQL versione 2.10
Nell'esempio seguente viene illustrato come applicare una modifica dei parametri a tutte le istanze database nel cluster Aurora MySQL 2.10. Con questa versione Aurora MySQL, si riavviano l'istanza di scrittura e tutte le istanze di lettura in modo indipendente.
L'esempio utilizza il parametro di configurazione MySQL `lower_case_table_names` per la dimostrazione. Quando questa impostazione dei parametri è diversa tra le istanze database di scrittura e lettura, una query potrebbe non essere in grado di accedere a una tabella dichiarata con un nome maiuscolo o minuscolo misto. Oppure, se due nomi di tabelle differiscono solo in termini di lettere maiuscole e minuscole, una query potrebbe accedere alla tabella errata.
Questo esempio mostra come determinare le istanze di scrittura e lettura nel cluster esaminando l'attributo `IsClusterWriter` di ciascuna istanza. Il cluster è denominato `cluster-2393`. Il cluster ha un'istanza di scrittura denominata `instance-9404`. Le istanze di lettura nel cluster sono denominate `instance-5138` e `instance-2470`.
```
$ aws rds describe-db-clusters --db-cluster-id cluster-2393 \
--query '*[].[DBClusterIdentifier,DBClusterMembers[*].[DBInstanceIdentifier,IsClusterWriter]]' \
--output text
cluster-2393
instance-5138 False
instance-2470 False
instance-9404 True
```
Per dimostrare gli effetti della modifica del parametro `lower_case_table_names`, abbiamo impostato due gruppi di parametri del cluster DB. Il gruppo di parametri `lower-case-table-names-0` ha questo parametro impostato su 0. Il gruppo di parametri `lower-case-table-names-1` ha questo gruppo di parametri impostato su 1.
```
$ aws rds create-db-cluster-parameter-group --description 'lower-case-table-names-0' \
--db-parameter-group-family aurora-mysql5.7 \
--db-cluster-parameter-group-name lower-case-table-names-0
{
"DBClusterParameterGroup": {
"DBClusterParameterGroupName": "lower-case-table-names-0",
"DBParameterGroupFamily": "aurora-mysql5.7",
"Description": "lower-case-table-names-0"
}
}
$ aws rds create-db-cluster-parameter-group --description 'lower-case-table-names-1' \
--db-parameter-group-family aurora-mysql5.7 \
--db-cluster-parameter-group-name lower-case-table-names-1
{
"DBClusterParameterGroup": {
"DBClusterParameterGroupName": "lower-case-table-names-1",
"DBParameterGroupFamily": "aurora-mysql5.7",
"Description": "lower-case-table-names-1"
}
}
$ aws rds modify-db-cluster-parameter-group \
--db-cluster-parameter-group-name lower-case-table-names-0 \
--parameters ParameterName=lower_case_table_names,ParameterValue=0,ApplyMethod=pending-reboot
{
"DBClusterParameterGroupName": "lower-case-table-names-0"
}
$ aws rds modify-db-cluster-parameter-group \
--db-cluster-parameter-group-name lower-case-table-names-1 \
--parameters ParameterName=lower_case_table_names,ParameterValue=1,ApplyMethod=pending-reboot
{
"DBClusterParameterGroupName": "lower-case-table-names-1"
}
```
Il valore predefinito di `lower_case_table_names` è 0. Con questa impostazione dei parametri, la tabella `foo` è distinta dalla tabella `FOO`. Questo esempio verifica che il parametro sia ancora all'impostazione predefinita. Quindi l'esempio crea tre tabelle che differiscono solo per lettere maiuscole e minuscole nei nomi.
```
mysql> create database lctn;
Query OK, 1 row affected (0.07 sec)
mysql> use lctn;
Database changed
mysql> select @@lower_case_table_names;
+--------------------------+
| @@lower_case_table_names |
+--------------------------+
| 0 |
+--------------------------+
mysql> create table foo (s varchar(128));
mysql> insert into foo values ('Lowercase table name foo');
mysql> create table Foo (s varchar(128));
mysql> insert into Foo values ('Mixed-case table name Foo');
mysql> create table FOO (s varchar(128));
mysql> insert into FOO values ('Uppercase table name FOO');
mysql> select * from foo;
+--------------------------+
| s |
+--------------------------+
| Lowercase table name foo |
+--------------------------+
mysql> select * from Foo;
+---------------------------+
| s |
+---------------------------+
| Mixed-case table name Foo |
+---------------------------+
mysql> select * from FOO;
+--------------------------+
| s |
+--------------------------+
| Uppercase table name FOO |
+--------------------------+
```
Successivamente, associamo il gruppo di parametri DB al cluster per impostare il parametro `lower_case_table_names` su 1. Questa modifica ha effetto solo dopo il riavvio di ogni istanza database.
```
$ aws rds modify-db-cluster --db-cluster-identifier cluster-2393 \
--db-cluster-parameter-group-name lower-case-table-names-1
{
"DBClusterIdentifier": "cluster-2393",
"DBClusterParameterGroup": "lower-case-table-names-1",
"Engine": "aurora-mysql",
"EngineVersion": "5.7.mysql_aurora.2.10.0"
}
```
Il primo riavvio che facciamo è per l'istanza database di scrittura. Quindi aspettiamo che l'istanza diventi nuovamente disponibile. A quel punto, ci connettiamo all'endpoint di scrittura e verifichiamo che l'istanza di scrittura abbia il valore del parametro modificato. Il comando `SHOW TABLES` conferma che il database contiene le tre tabelle diverse. Tuttavia, le query che fanno riferimento a tabelle denominate `foo`, `Foo` o `FOO` accedono tutte alla tabella il cui nome è interamente minuscolo, `foo`.
```
# Rebooting the writer instance
$ aws rds reboot-db-instance --db-instance-identifier instance-9404
$ aws rds wait db-instance-available --db-instance-id instance-9404
```
Ora, le query che utilizzano l'endpoint cluster mostrano gli effetti della modifica dei parametri. Indipendentemente dal fatto che il nome della tabella nella query sia maiuscolo, minuscolo o misto, l'istruzione SQL accede alla tabella il cui nome è tutto minuscolo.
```
mysql> select @@lower_case_table_names;
+--------------------------+
| @@lower_case_table_names |
+--------------------------+
| 1 |
+--------------------------+
mysql> use lctn;
mysql> show tables;
+----------------+
| Tables_in_lctn |
+----------------+
| FOO |
| Foo |
| foo |
+----------------+
mysql> select * from foo;
+--------------------------+
| s |
+--------------------------+
| Lowercase table name foo |
+--------------------------+
mysql> select * from Foo;
+--------------------------+
| s |
+--------------------------+
| Lowercase table name foo |
+--------------------------+
mysql> select * from FOO;
+--------------------------+
| s |
+--------------------------+
| Lowercase table name foo |
+--------------------------+
```
L'esempio successivo mostra le stesse query della precedente. In questo caso, le query utilizzano l'endpoint di lettura e vengono eseguite su una delle istanze database di lettura. Queste istanze non sono ancora state riavviate. Pertanto, hanno ancora l'impostazione originale per il parametro `lower_case_table_names`. Ciò significa che le query possono accedere a ciascuna delle tabelle `foo`, `Foo` e `FOO`.
```
mysql> select @@lower_case_table_names;
+--------------------------+
| @@lower_case_table_names |
+--------------------------+
| 0 |
+--------------------------+
mysql> use lctn;
mysql> select * from foo;
+--------------------------+
| s |
+--------------------------+
| Lowercase table name foo |
+--------------------------+
mysql> select * from Foo;
+---------------------------+
| s |
+---------------------------+
| Mixed-case table name Foo |
+---------------------------+
mysql> select * from FOO;
+--------------------------+
| s |
+--------------------------+
| Uppercase table name FOO |
+--------------------------+
```
Successivamente, riavviamo una delle istanze di lettura e aspettiamo che diventi nuovamente disponibile.
```
$ aws rds reboot-db-instance --db-instance-identifier instance-2470
{
"DBInstanceIdentifier": "instance-2470",
"DBInstanceStatus": "rebooting"
}
$ aws rds wait db-instance-available --db-instance-id instance-2470
```
Mentre è connesso all'endpoint dell'istanza per `instance-2470`, una query mostra che il nuovo parametro è attivo.
```
mysql> select @@lower_case_table_names;
+--------------------------+
| @@lower_case_table_names |
+--------------------------+
| 1 |
+--------------------------+
```
A questo punto, le due istanze di lettura nel cluster sono in esecuzione con impostazioni `lower_case_table_names` diverse. Pertanto, qualsiasi connessione all'endpoint di lettura del cluster utilizza un valore per questa impostazione che è imprevedibile. È importante riavviare immediatamente l'altra istanza di lettura in modo che entrambe abbiano impostazioni coerenti.
```
$ aws rds reboot-db-instance --db-instance-identifier instance-5138
{
"DBInstanceIdentifier": "instance-5138",
"DBInstanceStatus": "rebooting"
}
$ aws rds wait db-instance-available --db-instance-id instance-5138
```
L'esempio seguente conferma che tutte le istanze del lettore hanno la stessa impostazione per il parametro `lower_case_table_names`. I comandi controllano il valore di impostazione `lower_case_table_names` su ogni istanza di lettura. Quindi lo stesso comando che utilizza l'endpoint di lettura dimostra che ogni connessione all'endpoint di lettura utilizza una delle istanze di lettura, ma quale sia non è prevedibile.
```
# Check lower_case_table_names setting on each reader instance.
$ mysql -h instance-5138.a12345.us-east-1.rds.amazonaws.com \
-u my-user -p -e 'select @@aurora_server_id, @@lower_case_table_names'
+--------------------------+--------------------------+
| @@aurora_server_id | @@lower_case_table_names |
+--------------------------+--------------------------+
| instance-5138 | 1 |
+--------------------------+--------------------------+
$ mysql -h instance-2470.a12345.us-east-1.rds.amazonaws.com \
-u my-user -p -e 'select @@aurora_server_id, @@lower_case_table_names'
+--------------------------+--------------------------+
| @@aurora_server_id | @@lower_case_table_names |
+--------------------------+--------------------------+
| instance-2470 | 1 |
+--------------------------+--------------------------+
# Check lower_case_table_names setting on the reader endpoint of the cluster.
$ mysql -h cluster-2393.cluster-ro-a12345.us-east-1.rds.amazonaws.com \
-u my-user -p -e 'select @@aurora_server_id, @@lower_case_table_names'
+--------------------------+--------------------------+
| @@aurora_server_id | @@lower_case_table_names |
+--------------------------+--------------------------+
| instance-5138 | 1 |
+--------------------------+--------------------------+
# Run query on writer instance
$ mysql -h cluster-2393.cluster-a12345.us-east-1.rds.amazonaws.com \
-u my-user -p -e 'select @@aurora_server_id, @@lower_case_table_names'
+--------------------------+--------------------------+
| @@aurora_server_id | @@lower_case_table_names |
+--------------------------+--------------------------+
| instance-9404 | 1 |
+--------------------------+--------------------------+
```
Con la modifica dei parametri applicata ovunque, possiamo vedere l'effetto dell'impostazione `lower_case_table_names=1`. Se la tabella viene definita `foo`, `Foo` o `FOO` la query converte il nome in `foo` e accede alla stessa tabella in ogni caso.
```
mysql> use lctn;
mysql> select * from foo;
+--------------------------+
| s |
+--------------------------+
| Lowercase table name foo |
+--------------------------+
mysql> select * from Foo;
+--------------------------+
| s |
+--------------------------+
| Lowercase table name foo |
+--------------------------+
mysql> select * from FOO;
+--------------------------+
| s |
+--------------------------+
| Lowercase table name foo |
+--------------------------+
```