Configurazione della replica dei log binari per Aurora My SQL

La configurazione di My SQL replication con Aurora SQL My prevede i seguenti passaggi, che vengono discussi in dettaglio:

Indice

• 1. Abilitare l'accesso binario nella fonte di replica
• 2. Mantieni i log binari nel master di replica fino a quando non sono più necessari
• 3. Crea una copia o un dump della fonte di replica
• 4. Carica il dump nella destinazione della replica (se necessario)
• 5. Creazione di un utente di replica sull’origine di replica
• 6. Abilitare la replica nel target di replica
  • Definire una posizione per arrestare la replica su una replica di lettura
• 7. Monitora la replica
• Sincronizzazione delle password tra origine di replica e destinazione

1. Abilitare l'accesso binario nella fonte di replica

Seguono le istruzioni su come abilitare l'accesso binario nella fonte di replica per il motore del database.

Motore del database	Istruzioni
Aurora Mia SQL	Per attivare la registrazione binaria su un cluster Aurora My DB SQL Imposta il parametro del cluster di database binlog_format su ROW, STATEMENT o MIXED. MIXED è consigliato a meno che tu abbia bisogno di un formato binlog specifico. Il valore predefinito è OFF. Per modificare il parametro binlog_format, crea un gruppo di parametri del cluster di database personalizzato e associalo al tuo cluster di database. Non puoi modificare i parametri in un gruppo di parametri del cluster di database predefinito. Se stai modificando il parametro binlog_format da OFF a un altro valore, riavvia il cluster di database Aurora per rendere effettiva la modifica. Per ulteriori informazioni, consulta Parametri dell'istanza database e del cluster database di Amazon Aurora e .
RDSper My SQL	Per attivare la registrazione binaria su un'istanza Amazon RDS DB Non puoi attivare la registrazione binaria direttamente per un'istanza Amazon RDS DB, ma puoi attivarla effettuando una delle seguenti operazioni: Abilitare i backup automatici per l'istanza database. È possibile abilitare i backup automatici quando si crea un'istanza database o si possono abilitare i backup modificando un'istanza database esistente. Per ulteriori informazioni, consulta la sezione Creazione di un'istanza DB nella Amazon RDS User Guide. Crea una replica di lettura per l'istanza database. Per ulteriori informazioni, consulta Working with read replicas nella Amazon RDS User Guide.
Il mio SQL (esterno)	Per impostare la replica crittografata Per replicare i dati in modo sicuro con Aurora My SQL versione 2, puoi utilizzare la replica crittografata. Nota Se non hai bisogno di utilizzare la replica crittografata, puoi saltare queste fasi. Seguono i prerequisiti per l'utilizzo della replica crittografata: Secure Sockets Layer (SSL) deve essere abilitato sul database My source esterno. SQL È necessario preparare una chiave client e un certificato client per il cluster Aurora My SQL DB. Durante la replica crittografata, il cluster Aurora SQL My DB funge da client verso il server del database SQL My. I certificati e le chiavi per il SQL client Aurora My sono in file in formato.pem. Assicurati di essere preparato per la replica crittografata: Se non hai SSL abilitato il database My SQL source esterno e non hai preparato una chiave client e un certificato client, SSL accendi il server My SQL database e genera la chiave client e il certificato client richiesti. Se SSL è abilitato sulla fonte esterna, fornisci una chiave client e un certificato per il cluster Aurora My SQL DB. Se non li possiedi, genera una nuova chiave e un nuovo certificato per il cluster Aurora My SQL DB. Per firmare il certificato client, devi disporre della chiave di autorità di certificazione che hai usato per configurare SSL sul database esterno My SQL source. Per ulteriori informazioni, consulta Creazione di SSL certificati e chiavi utilizzando openssl nella documentazione personaleSQL. Hai bisogno del certificato autorità certificato, della chiave client e del certificato client. Connect al cluster Aurora My SQL DB come utente principale utilizzando. SSL Per informazioni sulla connessione a un cluster Aurora My SQL DB conSSL, vedere. TLSconnessioni ai cluster Aurora My DB SQL Esegui la mysql.rds_import_binlog_ssl_material stored procedure per importare le SSL informazioni nel cluster Aurora My SQL DB. Per il ssl_material_value parametro, inserisci le informazioni dai file in formato.pem per il cluster Aurora My SQL DB nel payload corretto. JSON L'esempio seguente importa SSL informazioni in un cluster Aurora My SQL DB. Nei file in formato .pem, il codice del corpo è in genere più lungo del codice del corpo riportato nell'esempio. call mysql.rds_import_binlog_ssl_material( '{"ssl_ca":"-----BEGIN CERTIFICATE----- AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE -----END CERTIFICATE-----\n","ssl_cert":"-----BEGIN CERTIFICATE----- AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE -----END CERTIFICATE-----\n","ssl_key":"-----BEGIN RSA PRIVATE KEY----- AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE -----END RSA PRIVATE KEY-----\n"}'); Per ulteriori informazioni, consulta mysql.rds_import_binlog_ssl_material e TLSconnessioni ai cluster Aurora My DB SQL. Nota Dopo aver eseguito la procedura, i segreti vengono archiviati in file. Per eliminare i file in un secondo momento, puoi eseguire la stored procedure mysql.rds_remove_binlog_ssl_material. Per attivare la registrazione binaria su un database My esterno SQL Da un shell comando, interrompi il servizio mysql. sudo service mysqld stop Modificare il file my.cnf (posto in genere sotto /etc). sudo vi /etc/my.cnf Aggiungere le opzioni log_bin e server_id alla sezione [mysqld]. L'opzione log_bin fornisce un identificatore di nome file per i file di log binari. L'opzione server_id fornisce un identificatore univoco per il server in relazioni master-replica. Se la replica crittografata non è richiesta, assicuratevi che il SQL database My esterno sia avviato con i binlogs abilitati e SSL che sia disattivato. Seguono le voci rilevanti nel file /etc/my.cnf per dati non crittografati. log-bin=mysql-bin server-id=2133421 innodb_flush_log_at_trx_commit=1 sync_binlog=1 Se è necessaria la replica crittografata, assicuratevi che il SQL database My esterno sia avviato con SSL e che i binlogs siano abilitati. Le voci del /etc/my.cnf file includono le posizioni dei file.pem per il server di database My. SQL log-bin=mysql-bin server-id=2133421 innodb_flush_log_at_trx_commit=1 sync_binlog=1 # Setup SSL. ssl-ca=/home/sslcerts/ca.pem ssl-cert=/home/sslcerts/server-cert.pem ssl-key=/home/sslcerts/server-key.pem Inoltre, l'sql_modeopzione per l'istanza My SQL DB deve essere impostata su 0 o non deve essere inclusa nel file my.cnf. Mentre sei connesso al SQL database My esterno, registra la posizione del log binario del SQL database My esterno. mysql> SHOW MASTER STATUS; L'output visualizzato dovrebbe essere simile al seguente: +------------------+----------+--------------+------------------+-------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +------------------+----------+--------------+------------------+-------------------+ | mysql-bin.000031 | 107 | | | | +------------------+----------+--------------+------------------+-------------------+ 1 row in set (0.00 sec) Per ulteriori informazioni, consulta Setting the replication source configurationla sezione La mia SQL documentazione. Avvia il servizio mysql. sudo service mysqld start

2. Mantieni i log binari nel master di replica fino a quando non sono più necessari

Quando usi My SQL binary log replication, Amazon RDS non gestisce il processo di replica. Come risultato, devi assicurarti che i file binlog nel master di replica siano mantenuti finché le modifiche vengono applicate alla replica. Questa manutenzione aiuta a ripristinare il database di origine in caso di errore.

Utilizza le istruzioni seguenti per mantenere i registri binari per il motore di database.

Motore del database	Istruzioni
Aurora Mia SQL	Per conservare i log binari su un cluster Aurora My DB SQL Non hai accesso ai file binlog per un cluster Aurora SQL My DB. Di conseguenza, è necessario scegliere un periodo di tempo per conservare i file binlog sulla fonte di replica abbastanza a lungo da garantire che le modifiche siano state applicate alla replica prima che il file binlog venga eliminato da Amazon. RDS È possibile conservare i file binlog su un cluster Aurora SQL My DB per un massimo di 90 giorni. Se stai configurando la replica con un'istanza My SQL database o My SQL DB come replica e il database RDS per cui stai creando una replica è molto grande, scegli un intervallo di tempo ampio per conservare i file binlog fino al completamento della copia iniziale del database sulla replica e al raggiungimento del ritardo di replica pari a 0. Per impostare il periodo di conservazione dei log binari, usa la procedura mysql.rds_set_configuration e specifica il parametro di configurazione 'binlog retention hours' insieme al numero di ore di conservazione dei file binlog nel cluster di database. Il valore massimo per Aurora My SQL versione 2.11.0 e successive e versione 3 è 2160 (90 giorni). L'esempio seguente imposta il periodo di conservazione dei file binlog su 6 giorni: CALL mysql.rds_set_configuration('binlog retention hours', 144); Dopo l'avvio della replica, è possibile verificare che le modifiche siano state applicate alla replica eseguendo il comando (SHOW SLAVE STATUSAurora My SQL versione 2) o (SHOW REPLICA STATUSAurora My SQL versione 3) sulla replica e controllando il campo. Seconds behind master Se il campo Seconds behind master è 0, non vi è alcun ritardo di replica. Quando non c'é ritardo di replica, riduci il periodo di tempo di conservazione dei file binlog impostando il parametro di configurazione binlog retention hours su un intervallo di tempo più breve. Se questa impostazione non è specificata, l'impostazione predefinita per Aurora My SQL è 24 (1 giorno). Se si specifica un valore 'binlog retention hours' superiore al valore massimo, Aurora My SQL utilizza il valore massimo.
RDSper My SQL	Per conservare i log binari su un'istanza Amazon RDS DB Puoi conservare i file di log binari su un'istanza Amazon RDS DB impostando le ore di conservazione dei binlog proprio come con un cluster Aurora SQL My DB, descritto nella riga precedente. Puoi anche conservare i file binlog su un'istanza Amazon RDS DB creando una replica di lettura per l'istanza DB. La replica di lettura è temporanea e ha solamente l'obiettivo di mantenere i file binlog. Dopo che la replica di lettura è stata creata, chiama la procedura mysql.rds_stop_replication nella replica di lettura. Mentre la replica viene interrotta, Amazon RDS non elimina nessuno dei file binlog sull'origine della replica. Dopo aver impostato la replica con la replica permanente, puoi eliminare la replica di lettura quando il ritardo di replica (campo Seconds behind master) tra il master di replica a la replica permanente diventa 0.
Il mio SQL (esterno)	Per conservare i log binari su un database My SQL esterno Poiché i file binlog su un SQL database My esterno non sono gestiti da AmazonRDS, vengono conservati fino a quando non vengono eliminati. Dopo l'avvio della replica, è possibile verificare che le modifiche siano state applicate alla replica eseguendo il comando (SHOW SLAVE STATUSAurora My SQL versione 2) o (SHOW REPLICA STATUSAurora My SQL versione 3) sulla replica e controllando il campo. Seconds behind master Se il campo Seconds behind master è 0, non vi è alcun ritardo di replica. Quando non c'é ritardo di replica, puoi eliminare i vecchi file binlog.

3. Crea una copia o un dump della fonte di replica

Si utilizza un'istantanea, un clone o un dump della fonte di replica per caricare una copia di base dei dati sulla replica. Quindi si inizia a replicare da quel punto.

Utilizza le seguenti istruzioni per creare una copia o un dump della fonte di replica per il tuo motore di database.

Motore del database	Istruzioni
Aurora Mia SQL	Per creare una copia di un cluster Aurora My DB SQL Seleziona uno dei seguenti metodi: Ripristina da un'istantanea del cluster DB: Crea una snapshot di un cluster di database del cluster di database Amazon Aurora. Per ulteriori informazioni, consulta Creazione di uno snapshot del cluster database. Crea un nuovo cluster di database Aurora ripristinandolo dalla snapshot cluster di database che hai appena creato. Assicurati di mantenere il gruppo di parametri database per il cluster di database ripristinato come con il cluster di database originale. Ciò assicura che la copia del cluster di database abbia l'accesso binario abilitato. Per ulteriori informazioni, consulta Ripristino da uno snapshot cluster database. Clona il tuo cluster DB. Per ulteriori informazioni, consulta Clonazione di un volume per un cluster di database Amazon Aurora. Per determinare il nome e la posizione del file binlog Seleziona uno dei seguenti metodi: Nel: AWS Management Console Scegli Databases, quindi scegli l'istanza principale (writer) per il tuo nuovo cluster Aurora DB per mostrarne i dettagli. Scorri fino a Recent Events (Eventi recenti). Viene visualizzato un messaggio di evento che include il nome e la posizione del file binlog. Il messaggio evento è nel formato seguente. Binlog position from crash recovery is binlog-file-name binlog-position Salva i valori del nome e della posizione del file binlog per quando avvierai la replica. Chiamate il AWS CLI comando describe-events, come nell'esempio seguente. aws rds describe-events { "Events": [ { "EventCategories": [], "SourceType": "db-instance", "SourceArn": "arn:aws:rds:us-west-2:123456789012:db:sample-restored-instance", "Date": "2016-10-28T19:43:46.862Z", "Message": "Binlog position from crash recovery is mysql-bin-changelog.000003 4278", "SourceIdentifier": "sample-restored-instance" } ] } Controlla il registro degli SQL errori My per l'ultima posizione del file My SQL binlog. Per creare un dump di un cluster Aurora My DB SQL Se la destinazione della replica è un SQL database My esterno o un'istanza RDS for My SQL DB, è necessario creare un file di dump dal cluster Aurora DB. Assicurati di eseguire il mysqldump comando sulla copia del cluster DB di origine che hai creato. Questo serve a evitare considerazioni bloccanti quando si esegue il dump. Se il dump fosse eseguito direttamente sul cluster DB di origine, sarebbe necessario bloccare le tabelle di origine per evitare scritture simultanee su di esse mentre il dump è in corso. Connect al cluster DB utilizzando un SQL client My. Emetti il mysqldump comando. Per esempio: PROMPT> mysqldump --databases database_name --single-transaction --order-by-primary -r backup.sql -u local_users -p Dopo aver creato il file di dump, è possibile eliminare la copia del cluster DB.
RDSper My SQL	Per creare uno snapshot di un'istanza Amazon RDS DB Crea una replica di lettura della tua istanza Amazon RDS DB. Per ulteriori informazioni, consulta Creazione di una replica di lettura nella Guida per l'utente di Amazon Relational Database Service. Esegui la connessione alla replica di lettura e interrompi la replica eseguendo la procedura mysql.rds_stop_replication. Mentre la replica di lettura è interrotta, connettiti alla replica di lettura ed SHOW SLAVE STATUS esegui il comando (Aurora My SQL versione 2) o (SHOW REPLICA STATUSAurora My versione 3). SQL Recupera il nome dei file di log binario corrente dal campo Relay_Master_Log_File e la posizione del file di log dal campo Exec_Master_Log_Pos. Salva questi valori per quando avvierai la replica. Mentre la replica di lettura rimane nello stato Stopped (Interrotto), crea una snapshot DB di una replica di lettura. Per ulteriori informazioni, consulta Creazione di uno snapshot DB nella Guida per l'utente di Amazon Relational Database Service. Elimina la replica di lettura.
My (esterno) SQL	Per creare un dump di un database My SQL esterno Prima di creare un dump, devi assicurarti che la posizione del binlog per il dump sia aggiornata con i dati nell'istanza di origine. Per fare ciò, devi prima fermare qualsiasi operazione di scrittura all'istanza con il seguente comando: mysql> FLUSH TABLES WITH READ LOCK; Crea un dump del tuo SQL database My utilizzando il mysqldump comando illustrato di seguito: PROMPT> sudo mysqldump --databases database_name --master-data=2 --single-transaction \ --order-by-primary -r backup.sql -u local_user -p Dopo aver creato il dump, sblocca le tabelle nel tuo SQL database My con il seguente comando: mysql> UNLOCK TABLES;

4. Carica il dump nella destinazione della replica (se necessario)

Se prevedi di caricare dati da un dump di un SQL database My esterno ad AmazonRDS, potresti voler creare un'EC2istanza in cui copiare i file di dump. Quindi puoi caricare i dati nel tuo cluster DB o nell'istanza DB da quell'EC2istanza. Utilizzando questo approccio, puoi comprimere i file di dump prima di copiarli sull'EC2istanza per ridurre i costi di rete associati alla copia dei dati su Amazon. RDS Puoi anche crittografare il file o i file dump per assicurare i dati mentre vengono trasferiti nella rete.

Nota

Se crei un nuovo cluster Aurora My SQL DB come destinazione della replica, non è necessario caricare un file di dump:

• È possibile eseguire il ripristino da uno snapshot del cluster DB per creare un nuovo cluster DB. Per ulteriori informazioni, consulta Ripristino da uno snapshot cluster database.

• È possibile clonare il cluster DB di origine per creare un nuovo cluster DB. Per ulteriori informazioni, consulta Clonazione di un volume per un cluster di database Amazon Aurora.

• È possibile migrare i dati da uno snapshot di un'istanza DB in un nuovo cluster DB. Per ulteriori informazioni, consulta Migrazione dei dati verso un cluster Amazon Aurora My DB SQL.

Utilizza le seguenti istruzioni per caricare il dump della fonte di replica nella destinazione di replica per il motore di database.

Motore del database	Istruzioni
Aurora Mia SQL	Per caricare un dump in un cluster Aurora My DB SQL Copia l'output del mysqldump comando dalla fonte di replica in una posizione che può anche connettersi al cluster Aurora SQL My DB. Connect al cluster Aurora My SQL DB utilizzando il mysql comando. Di seguito è riportato un esempio. PROMPT> mysql -h host_name -port=3306 -u db_master_user -p Al mysql prompt, esegui il source comando e passagli il nome del file di dump del database per caricare i dati nel cluster Aurora My SQL DB, ad esempio: mysql> source backup.sql;
RDSper My SQL	Per caricare un dump in un'istanza Amazon RDS DB Copia l'output del mysqldump comando dalla fonte di replica in una posizione che possa connettersi anche alla tua istanza My SQL DB. Connect alla propria istanza My SQL DB utilizzando il mysql comando. Di seguito è riportato un esempio. PROMPT> mysql -h host_name -port=3306 -u db_master_user -p Al mysql prompt, esegui il source comando e passagli il nome del file di dump del database per caricare i dati nell'istanza My SQL DB, ad esempio: mysql> source backup.sql;
My SQL (esterno)	Per caricare un dump in un database My SQL esterno Non è possibile caricare uno snapshot DB o uno snapshot del cluster DB in un database My esterno. SQL Devi utilizzare invece l'output dal comando mysqldump. Copia l'output del mysqldump comando dalla tua fonte di replica in una posizione che può anche connettersi al tuo database My. SQL Connect al SQL database My utilizzando il mysql comando. Di seguito è riportato un esempio. PROMPT> mysql -h host_name -port=3306 -u db_master_user -p Al mysql prompt, esegui il source comando e passagli il nome del file di dump del database per caricare i dati nel tuo database MySQL. Di seguito è riportato un esempio. mysql> source backup.sql;

5. Creazione di un utente di replica sull’origine di replica

Crea un ID utente sull’origine utilizzato solamente per la replica. L'esempio seguente è RDS per database My SQL o My SQL source esterni.

mysql> CREATE USER 'repl_user'@'domain_name' IDENTIFIED BY 'password';

Per i database Aurora My SQL source, il parametro del cluster skip_name_resolve DB è impostato su 1 (ON) e non può essere modificato, quindi è necessario utilizzare un indirizzo IP per l'host anziché un nome di dominio. Per ulteriori informazioni, consulta skip_name_resolve nella documentazione My. SQL

mysql> CREATE USER 'repl_user'@'IP_address' IDENTIFIED BY 'password';

L'utente richiede i privilegi REPLICATION CLIENT e REPLICATION SLAVE. Concedi questi privilegi all'utente.

Se è necessario utilizzare la replica crittografata, è necessario disporre di SSL connessioni per l'utente di replica. Ad esempio, è possibile utilizzare una delle seguenti istruzioni per richiedere SSL connessioni sull'account utente. repl_user

GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'IP_address';

GRANT USAGE ON *.* TO 'repl_user'@'IP_address' REQUIRE SSL;

Nota

Se REQUIRE SSL non è incluso, la connessione di replica potrebbe ridiventare una connessione non crittografata.

6. Abilitare la replica nel target di replica

Prima di attivare la replica, si consiglia di scattare un'istantanea manuale del cluster Aurora My SQL DB o della destinazione di replica dell'RDSistanza My SQL DB. Se c'è un problema e devi ristabilire la replica con il cluster di database o il target di replica dell'istanza database, puoi ripristinare il cluster di database o l'istanza database da questa snapshot invece di dover importare di nuovo i dati nel target di replica.

Utilizza le istruzioni seguenti per attivare la replica del motore di database.

Motore del database	Istruzioni
Aurora Mia SQL	Per attivare la replica da un cluster Aurora My DB SQL Individua il punto di partenza per la replica. Hai bisogno del nome e della posizione del file binlog. Se la destinazione della replica del cluster di database è stata creata da: Istantanea o clone del cluster DB: recupera il nome e la posizione del file binlog dagli eventi recenti per il nuovo cluster DB, come mostrato in. 3. Crea una copia o un dump della fonte di replica Istantanea DB: hai recuperato il nome e la posizione del file binlog dal comando (SHOW SLAVE STATUSAurora My SQL versione 2) o (SHOW REPLICA STATUSAurora My SQL versione 3) quando hai creato l'istantanea della tua origine di replica. Connettiti al cluster di database e richiama le seguenti procedure per avviare la replica con l'origine utilizzando il nome e il percorso del file di log binario del passaggio precedente: mysql.rds_set_external_source (Aurora My versione 3) SQL mysql.rds_set_external_master (Aurora La mia versione 2) SQL mysql.rds_start_replication (tutte le versioni) L'esempio seguente è per Aurora My SQL versione 3. CALL mysql.rds_set_external_source ('mydbinstance.123456789012.us-east-1.rds.amazonaws.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 0); CALL mysql.rds_start_replication; Per utilizzare SSL la crittografia, imposta il valore finale su 1 invece di0.
RDSper My SQL	Per attivare la replica da un'istanza Amazon RDS DB Se il target di replica dell'istanza database è stato creato da una snapshot DB, hai bisogno del file e della posizione binlog che sono il punto di partenza per la replica. Hai recuperato questi valori dal comando SHOW SLAVE STATUS (Aurora SQL My versione 2) o SHOW REPLICA STATUS (Aurora SQL My versione 3) quando hai creato l'istantanea della tua origine di replica. Esegui la connessione all'istanza database e chiama le procedure mysql.rds_set_external_master (Aurora La mia versione 2) SQL o mysql.rds_set_external_source (Aurora My versione 3) SQL e mysql.rds_start_replication per avviare la replica con l'origine. Utilizza il nome e il percorso del file di log binario del passaggio precedente. Di seguito è riportato un esempio. CALL mysql.rds_set_external_master ('mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 0); CALL mysql.rds_start_replication; Per utilizzare la SSL crittografia, imposta il valore finale su invece di. 1 0
Il mio SQL (esterno)	Per attivare la replica da un database My SQL esterno Recupera il file e la posizione binlog che sono il punto di inizio per la replica. Hai recuperato questi valori dal comando SHOW SLAVE STATUS (Aurora SQL My versione 2) o SHOW REPLICA STATUS (Aurora SQL My versione 3) quando hai creato l'istantanea della tua origine di replica. Se la destinazione esterna My SQL replica è stata compilata dall'output del mysqldump comando con l'--master-data=2opzione, il file binlog e la posizione binlog vengono inclusi nell'output. Di seguito è riportato un esempio. -- -- Position to start replication or point-in-time recovery from -- -- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.000031', MASTER_LOG_POS=107; Connettiti alla destinazione esterna My SQL replica ed emetti CHANGE MASTER TO and START SLAVE (Aurora SQL My versione 2) o START REPLICA (Aurora SQL My versione 3) per avviare la replica con l'origine di replica utilizzando il nome e la posizione del file di log binario del passaggio precedente, ad esempio: CHANGE MASTER TO MASTER_HOST = 'mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com', MASTER_PORT = 3306, MASTER_USER = 'repl_user', MASTER_PASSWORD = 'password', MASTER_LOG_FILE = 'mysql-bin-changelog.000031', MASTER_LOG_POS = 107; -- And one of these statements depending on your engine version: START SLAVE; -- Aurora MySQL version 2 START REPLICA; -- Aurora MySQL version 3

Se la replica ha esito negativo, può verificarsi un notevole aumento di I/O non intenzionale sulla replica, che può compromettere le prestazioni. Se la replica non riesce o non è più necessaria, è possibile eseguire la stored procedure mysql.rds_reset_external_master (Aurora La mia versione 2) SQL o mysql.rds_reset_external_source (Aurora My versione 3) SQL per rimuovere la configurazione della replica.

Definire una posizione per arrestare la replica su una replica di lettura

In Aurora My SQL versione 3.04 e successive, è possibile avviare la replica e quindi interromperla in una posizione specificata del file di registro binario utilizzando la stored procedure. mysql.rds_start_replication_until (Aurora My versione 3) SQL

Per avviare la replica su una replica di lettura e arrestare la replica in corrispondenza di una posizione specifica

1. Utilizzando un SQL client My, connettiti al cluster di replica Aurora SQL My DB come utente principale.

2. Eseguire la procedura archiviata mysql.rds_start_replication_until (Aurora My versione 3) SQL.

   L'esempio seguente avvia la replica e replica le modifiche fino a raggiungere la posizione 120 nel file di log binario mysql-bin-changelog.000777. In caso di disaster recovery, presumere che la posizione 120 si riferisca al momento immediatamente precedente l'errore.

   call mysql.rds_start_replication_until(
     'mysql-bin-changelog.000777',
     120);
   

La replica si arresta automaticamente quando viene raggiunto il punto di arresto. Viene generato il seguente RDS evento:. Replication has been stopped since the replica reached the stop point specified by the rds_start_replication_until stored procedure

Se si utilizza la replica GTID basata, utilizzare la mysql.rds_start_replication_until_gtid (Aurora La mia versione 3) SQL stored procedure anziché la mysql.rds_start_replication_until (Aurora My versione 3) SQL stored procedure. Per ulteriori informazioni sulla replica GTID basata, vedere. Utilizzo della replica GTID basata

7. Monitora la replica

Quando si configura La mia SQL replica con un cluster Aurora SQL My DB, è necessario monitorare gli eventi di failover per il cluster Aurora SQL My DB quando è la destinazione della replica. Se accade un failover, il cluster di database che è il target di replica potrebbe essere ricreato in un nuovo host con un indirizzo di rete diverso. Per informazioni su come monitorare gli eventi di failover, consulta Utilizzo delle notifiche di RDS eventi di Amazon.

È inoltre possibile monitorare la distanza tra la destinazione della replica e l'origine della replica collegandosi alla destinazione della replica ed eseguendo il comando (SHOW SLAVE STATUSAurora My SQL versione 2) o (SHOW REPLICA STATUSAurora My versione 3). SQL Nell'output del comando, il campo Seconds Behind Master indica quanto è indietro il target di replica rispetto al master di replica.

Sincronizzazione delle password tra origine di replica e destinazione

Quando si modificano gli account utente e le password sull'origine della replica utilizzando le SQL istruzioni, tali modifiche vengono replicate automaticamente sulla destinazione di replica.

Se si utilizza il AWS Management Console, il o il AWS CLI RDS API per modificare la password principale sull'origine della replica, tali modifiche non vengono replicate automaticamente nella destinazione di replica. Se si desidera sincronizzare l'utente principale e la password principale tra il sistema di origine e quello di destinazione, è necessario apportare la stessa modifica alla destinazione di replica.