Esempi di operazioni di riavvio Aurora

I seguenti SQL esempi Aurora My mostrano diverse combinazioni di operazioni di riavvio per istanze DB reader e writer in un cluster Aurora DB. Dopo ogni riavvio, SQL le query dimostrano l'uptime delle istanze nel cluster.

Individuazione delle istanze di scrittore e lettore per un cluster Aurora

In un SQL cluster Aurora My con più istanze DB, è importante sapere chi è l'autore 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 SQL query in questo esempio mostra un modo SQL specifico di My per controllare l'uptime. È possibile utilizzare questa tecnica in un'applicazione di database. Per un'altra tecnica che utilizza AWS CLI e funziona per entrambi i motori Aurora, vedi. Verifica del tempo di attività per i cluster e le istanze Aurora

$ 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 My SQL versione 2.09. Poiché la SQL versione di Aurora My è precedente alla 2.10, il riavvio dell'istanza writer riavvia anche tutte 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 Postgre e SQL ai cluster SQL Aurora My precedenti alla 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

Questi esempi successivi mostrano un cluster che esegue Aurora My SQL versione 2.10. In questa SQL versione di Aurora My e successive, puoi riavviare l'istanza di Writer senza causare il riavvio di tutte le istanze del lettore. 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.

L'esempio seguente utilizza un cluster denominatocluster-2393, che esegue Aurora My SQL version. 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 sull'uptime corrispondenti 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 ad Aurora My SQL 2.10, i valori di uptime per tutti i lettori venivano reimpostati contemporaneamente all'autore.

$ 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 My SQL versione 2.10

L'esempio seguente dimostra come applicare una modifica dei parametri a tutte le istanze DB nel cluster Aurora My 2.10. SQL Con questa SQL versione di Aurora My, riavvii l'istanza di writer e tutte le istanze di Reader in modo indipendente.

L'esempio utilizza il parametro lower_case_table_names di SQL configurazione My per l'illustrazione. 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'SQListruzione accede alla tabella il cui nome è tutto in 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 |
+--------------------------+