Mysqldump è un'utilità client utilizzata per eseguire backup logici del database MySQL. Questo popolare strumento di migrazione è utile per vari casi d'uso di MySQL come:
- Backup e ripristino dei database.
- Migrazione dei dati da un server all'altro.
- Migrazione dei dati tra diversi provider di servizi MySQL gestiti.
- Migrazione dei dati tra diverse versioni di MySQL.
Mysqldump funziona leggendo gli oggetti del database di origine e generando una serie di istruzioni SQL che sono archiviate in un file dump. Riproducendo queste istruzioni sul server del database di destinazione, vengono ricostruiti i dati originali. Poiché questo modello utilizza la lettura dell'intero database e quindi essenzialmente la ricostruzione, sia il dump che il ripristino sono operazioni che richiedono tempo per un database di grandi dimensioni. Il processo potrebbe anche diventare ingombrante se si verificano errori durante il dump o il ripristino in quanto potrebbe portarti a risolvere i problemi e rieseguire le operazioni. Questo è il motivo per cui è importante pianificare bene prima di occuparti del dump e ripristinare l'attività.
In questa serie di blog in 2 parti, discutiamo alcuni degli aspetti comuni che dovresti gestire in anticipo per garantire un dump e un ripristino di successo. Nella prima parte, ci concentreremo sui prerequisiti di cui è necessario fare attenzione durante l'importazione dei dati della tabella MySQL e nella seconda parte, parleremo di come gestire l'importazione per gli oggetti e le viste del programma archiviati.
1. Requisiti di spazio
Prima di tutto, è importante assicurarsi che il volume del database di destinazione abbia spazio sufficiente per contenere i dati importati. In particolare, è necessario prestare attenzione se i log binari sono abilitati sul database MySQL di destinazione, poiché i log binari generati durante l'importazione dei dati potrebbero avere dimensioni quasi uguali a quelle dei dati stessi. I registri binari sono necessari se si desidera ripristinare i dati su un server e si desidera che vengano replicati. In questi casi, è una buona idea pianificare la dimensione della destinazione maggiore del doppio della dimensione del database di origine.
È anche importante assicurarsi che sia disponibile spazio sufficiente sul volume in cui si genera il file di output di mysqldump. Senza queste precauzioni, è possibile che il dump o il ripristino non vadano a buon fine a causa di spazio insufficiente dopo un lungo periodo di esecuzione, il che comporta una perdita di tempo e fatica produttivi.
2. Modalità_sql
Le impostazioni sql_mode per il server MySQL determinano la sintassi dell'istruzione SQL e i controlli di convalida dei dati che il server esegue per le operazioni. È importante garantire la sql_mode dei server MySQL di origine e di destinazione sono compatibili tra loro, oppure potresti riscontrare errori durante il ripristino del dump che hai eseguito. Dimostriamolo con un esempio.
Supponiamo di avere una tabella nella tua fonte che ha una colonna di data con voci come zero date:
mysql> show create table sched; --------------------------------------------------------+ | Table | Create Table | --------------------------------------------------------+ | sched | CREATE TABLE `sched` ( `id` int(11) DEFAULT NULL, `ts` date DEFAULT NULL ) ENGINE=InnoDB DEFAULT CHARSET=latin1 | +-------+--------------------------------------------------------------------------------------------------------------------- mysql> select * from sched; +------+------------+ | id | ts | +------+------------+ | 1 | 2020-01-12 | | 2 | 0000-00-00 | +------+------------+
Supponiamo la rigorosa sql_mode (e NO_ZERO_DATE ) è disabilitato sull'origine, ma abilitato sulla destinazione:il ripristino di tali righe comporterà un errore come:
ERROR 1292 (22007) at line 40: Incorrect date value: '0000-00-00' for column 'ts’' at row 2
In genere si verificano problemi di questo tipo se si esegue un dump compatto abilitando l'opzione compact come parte di mysqldump.
Se compact è disabilitato (che è per impostazione predefinita), non dovrai affrontare questo problema poiché mysqldump genera la seguente istruzione condizionale come parte del dump:
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE,SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
Ciò significa che durante il ripristino sql_mode è impostato su 'NO_AUTO_VALUE_ON_ZERO' prima di ripristinare i dati della tabella in modo che il ripristino vada a buon fine.
3. Assegni_unici e controlli_chiave_esterna
Per impostazione predefinita (se non usi l'opzione –compact), mysqldump imposta anche quanto segue:
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */; /*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
Come spiegato qui, puoi accelerare l'operazione di ripristino disattivando temporaneamente i controlli di unicità durante la sessione. Per le tabelle di grandi dimensioni, ciò consente di risparmiare un sacco di I/O del disco perché InnoDB può utilizzare il suo buffer di modifiche per scrivere record di indice secondari in un batch.
Se hai FOREIGN KEY vincoli nelle tabelle, puoi accelerare l'operazione di ripristino delle tabelle disattivando i controlli della chiave esterna per la durata della sessione di ripristino:per le tabelle di grandi dimensioni, questo può far risparmiare molto I/O del disco.
Disattivazione di FOREIGN_KEY_CHECKS aiuterà anche a evitare errori dovuti ai controlli del vincolo della chiave foregin durante l'operazione di ripristino. Ogni volta che viene creata una tabella con il vincolo della chiave foregin, MySQL si aspetta che la tabella padre a cui fa riferimento la chiave foregin esista già. Questo è un problema poiché l'utilità mysqldump esegue il dump delle tabelle in ordine alfabetico. Facciamo un esempio per dimostrarlo.
Sul database di origine, abbiamo due tabelle:
CREATE TABLE `solution_table` ( `num1` int(11) NOT NULL, `num2` int(11) DEFAULT NULL, PRIMARY KEY (`num1`)); CREATE TABLE `ref_table` ( `key` int(11) DEFAULT NULL, `ref_num` int(11) DEFAULT NULL, KEY `ref_num` (`ref_num`), CONSTRAINT `ref_num_ibfk_1` FOREIGN KEY (`ref_num`) REFERENCES `solution_table` (`num1`) )
La tabella ref_table ha un vincolo di chiave esterna che fa riferimento alla solution_table . In base all'ordine alfabetico, mysqldump prima scarica il contenuto di ref_table . Quando questo viene riprodotto al momento del ripristino, fallirà con l'errore:
ERROR 1215 (HY000) at line 50: Cannot add foreign key constraint -
Che accade durante l'esecuzione dell'istruzione create table per ‘ref_table’ .
In sintesi, sii consapevole dei problemi che potresti incontrare, se specifichi --compact opzione durante l'esecuzione di mysqldump.
4. Privilegi richiesti per eseguire mysqldump
Il privilegio minimo richiesto da mysqldump per eseguire il dump di un database è SELECT su quel database.
Tuttavia, se il tuo database ha viste, avrai bisogno anche delle autorizzazioni SHOW VIEW, poiché mysqldump scarica sempre le viste insieme alle tabelle del database. Supponi di non avere SHOW VIEW autorizzazioni, quindi mysqldump fallirà con:
mysqldump: Couldn't execute 'show create table `ivew`': SHOW VIEW command denied to user ‘dumpuser’@'172.31.18.79' for table 'iview' (1142)
Un altro punto di interesse è se il tuo dumpuser ha SELECT autorizzazioni solo su una particolare tabella del database, mysqldump scaricherà i dati solo per quella particolare tabella e ignorerà automaticamente qualsiasi altra tabella o vista.
Quindi assicurati che l'utente che esegue mysqldump disponga di tutti i privilegi appropriati in anticipo per evitare sorprese o errori in un secondo momento.
|
5. Pacchetto_max_consentito
Il pacchetto di comunicazione più grande gestito da mysql è determinato dall'impostazione max_allowed_packet . Nel contesto dell'importazione, un pacchetto di comunicazione è una singola istruzione SQL inviata al server MySQL durante il ripristino OPPURE una singola riga inviata al client durante il dump.
Il valore predefinito di max_allowed_packet per mysqldump è 24 MB. se mysqldump riceve un pacchetto più grande di questo, potresti riscontrare l'errore:
mysqldump: Error 2020: Got packet bigger than 'max_allowed_packet' bytes when dumping table `huge1` at row: 2.
Quindi assicurati che mysqldump utilizzi lo stesso valore o maggiore di max_allowed_packet che è configurato sull'istanza MySQL di origine.
L'opzione può essere specificata con il flag --max-allowed-packet=value quando si invoca il mysqldump.
Quando ripristini il dump, assicurati che max_allowed_packet la dimensione del tuo server di destinazione è abbastanza grande per ricevere i pacchetti dal file dump.
Altrimenti, durante il ripristino del dump, vedrai un messaggio di errore:
ERROR 2006 (HY000) at line 70: MySQL server has gone away
Questo errore può essere un po' fuorviante poiché potresti pensare che il server MySQL si sia spento o si sia arrestato in modo anomalo. Ma significa solo che il server ha ricevuto un pacchetto di dimensioni maggiori rispetto alla dimensione configurata di max_allowed_packet . Ancora una volta, la migliore pratica è assicurarsi che il max_allowed_packet il valore per il server di destinazione è uguale al valore nel server di origine. Questa è anche un'impostazione importante che può essere verificata e impostata in modo appropriato in anticipo, piuttosto che affrontare gli errori in un secondo momento.
In questa prima parte della serie mysqldump, abbiamo discusso i prerequisiti per un'operazione di dump e ripristino di successo per database MySQL di grandi dimensioni al fine di aiutarti a evitare tentativi multipli e tempo impiegato non produttivo.
Nella parte successiva, discuteremo le migliori pratiche per importare i programmi e le viste archiviati dal tuo database MySQL.
