Mysqldump is een client-hulpprogramma dat wordt gebruikt om logische back-ups van de MySQL-database uit te voeren. Deze populaire migratietool is handig voor verschillende gebruiksscenario's van MySQL, zoals:
- Back-up en herstel van databases.
- Gegevens migreren van de ene server naar de andere.
- Gegevens migreren tussen verschillende beheerde MySQL-serviceproviders.
- Gegevens migreren tussen verschillende versies van MySQL.
Mysqldump werkt door de brondatabaseobjecten te lezen en een set SQL-instructies te genereren die in een dumpbestand zijn opgeslagen. Door deze instructies op de doeldatabaseserver af te spelen, worden de oorspronkelijke gegevens gereconstrueerd. Aangezien dit model het lezen van de hele database gebruikt en vervolgens in wezen opnieuw opbouwt, zijn zowel dumpen als herstellen tijdrovende bewerkingen voor een grote database. Het proces kan zelfs omslachtig worden als u fouten tegenkomt tijdens het dumpen of herstellen, omdat dit ertoe kan leiden dat u de problemen oplost en de bewerkingen opnieuw uitvoert. Daarom is het belangrijk om goed te plannen voordat je begint met dumpen en herstellen.
In deze tweedelige blogserie bespreken we enkele van de algemene aspecten die u vooraf moet aanpakken om een succesvolle dump- en herstelactiviteit te garanderen. In het eerste deel concentreren we ons op de vereisten waar u op moet letten bij het importeren van de MySQL-tabelgegevens en in het tweede deel zullen we het hebben over hoe u de import van opgeslagen programma-objecten en -weergaven moet afhandelen.
1. Ruimtevereisten
Ten eerste is het belangrijk om ervoor te zorgen dat uw doeldatabasevolume voldoende ruimte heeft om de geïmporteerde gegevens te bewaren. In het bijzonder moet u voorzichtig zijn als binaire logboeken zijn ingeschakeld op uw MySQL-doeldatabase, omdat binaire logboeken die worden gegenereerd tijdens het importeren van de gegevens bijna even groot kunnen zijn als de gegevens zelf. Binaire logboeken zijn nodig als u uw gegevens op één server wilt herstellen en wilt dat deze wordt gerepliceerd. In dergelijke gevallen is het een goed idee om de doelgrootte groter te plannen dan tweemaal de grootte van de brondatabase.
Het is ook belangrijk om ervoor te zorgen dat er voldoende ruimte beschikbaar is op het volume waarop u het mysqldump-uitvoerbestand genereert. Zonder deze voorzorgsmaatregelen kan het zijn dat uw dump of herstel mislukt vanwege onvoldoende ruimte na een lange tijd draaien, wat een verlies van uw productieve tijd en moeite betekent.
2. Sql_mode
sql_mode-instellingen voor de MySQL-server bepalen de syntaxis van de SQL-instructie en gegevensvalidatiecontroles die de server uitvoert voor de bewerkingen. Het is belangrijk om ervoor te zorgen dat de sql_mode van bron- en doel-MySQL-servers zijn compatibel met elkaar, of u kunt fouten tegenkomen tijdens het herstellen van de dump die u hebt genomen. Laten we dit aan de hand van een voorbeeld demonstreren.
Stel dat u een tabel in uw bron heeft die een datumkolom heeft met vermeldingen als nuldatums:
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 | +------+------------+
Stel dat de strikte sql_mode (en NO_ZERO_DATE ) is uitgeschakeld op de bron, maar ingeschakeld op de bestemming - het herstellen van dergelijke rijen zal leiden tot fouten zoals:
ERROR 1292 (22007) at line 40: Incorrect date value: '0000-00-00' for column 'ts’' at row 2
Je zult dergelijke problemen meestal zien als je een compacte dump maakt door de compacte optie in te schakelen als onderdeel van je mysqldump.
Als compact is uitgeschakeld (wat standaard is), zult u dit probleem niet tegenkomen, aangezien mysqldump de volgende voorwaardelijke instructie genereert als onderdeel van de dump:
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE,SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
Dit betekent dat tijdens het herstellen sql_mode is ingesteld op 'NO_AUTO_VALUE_ON_ZERO' voordat de tabelgegevens worden hersteld, dus het herstel verloopt prima.
3. Unique_checks en Foreign_key_checks
Standaard (als u de optie –compact niet gebruikt), stelt mysqldump ook het volgende in:
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */; /*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
Zoals hier uitgelegd, kunt u de herstelbewerking versnellen door de uniciteitscontroles tijdens de sessie tijdelijk uit te schakelen. Voor grote tabellen bespaart dit veel schijf-I/O omdat InnoDB zijn wijzigingsbuffer kan gebruiken om secundaire indexrecords in een batch te schrijven.
Als je FOREIGN KEY . hebt beperkingen in uw tabellen, kunt u het herstel van tabellen versnellen door de externe sleutelcontroles uit te schakelen voor de duur van de herstelsessie:voor grote tabellen kan dit veel schijf-I/O besparen.
FOREIGN_KEY_CHECKS uitschakelen helpt ook om fouten te voorkomen als gevolg van toetsbeperkingscontroles tijdens de herstelbewerking. Telkens wanneer een tabel met een foregin-sleutelbeperking wordt gemaakt, verwacht MySQL dat de bovenliggende tabel waarnaar wordt verwezen door de foregin-sleutel al bestaat. Dit is een probleem omdat het hulpprogramma mysqldump de tabellen in alfabetische volgorde dumpt. Laten we een voorbeeld nemen om dit aan te tonen.
In de brondatabase hebben we twee tabellen:
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`) )
De tabel ref_table heeft een externe sleutelbeperking die verwijst naar de solution_table . Op alfabetische volgorde dumpt mysqldump eerst de inhoud van ref_table . Wanneer dit opnieuw wordt afgespeeld op het moment van herstel, zal het mislukken met de fout:
ERROR 1215 (HY000) at line 50: Cannot add foreign key constraint -
Dit gebeurt tijdens het uitvoeren van de create table-instructie voor ‘ref_table’ .
Kortom, houd rekening met de problemen die u kunt tegenkomen, als u --compact opgeeft optie tijdens het uitvoeren van mysqldump.
4. Benodigdheden vereist voor het uitvoeren van mysqldump
Het minimale privilege dat mysqldump vereist voor het dumpen van een database is SELECT op die database.
Als uw database echter views heeft, heeft u ook SHOW VIEW permissies nodig, aangezien mysqldump views altijd samen met de tabellen van de database dumpt. Stel dat u geen SHOW VIEW . heeft machtigingen, dan zal de mysqldump mislukken met:
mysqldump: Couldn't execute 'show create table `ivew`': SHOW VIEW command denied to user ‘dumpuser’@'172.31.18.79' for table 'iview' (1142)
Een ander aandachtspunt is of uw dumpuser SELECT heeft alleen toestemming geeft voor een bepaalde tabel van de database, zal mysqldump alleen gegevens voor die bepaalde tabel dumpen en automatisch alle andere tabellen of weergaven negeren.
Zorg er dus voor dat de gebruiker die mysqldump uitvoert vooraf alle juiste rechten heeft om verrassingen of fouten op een later tijdstip te voorkomen.
|
5. Max_allowed_packet
Het grootste communicatiepakket dat door mysql wordt afgehandeld, wordt bepaald door de instelling max_allowed_packet . In de context van importeren is een communicatiepakket een enkele SQL-instructie die tijdens het herstel naar de MySQL-server wordt verzonden OF een enkele rij die tijdens de dump naar de client wordt verzonden.
De standaardwaarde van max_allowed_packet voor mysqldump is 24 MB. als mysqldump een groter pakket ontvangt, kunt u de volgende fout tegenkomen:
mysqldump: Error 2020: Got packet bigger than 'max_allowed_packet' bytes when dumping table `huge1` at row: 2.
Zorg er dus voor dat mysqldump dezelfde of een grotere waarde gebruikt van max_allowed_packet die is geconfigureerd op de bron MySQL-instantie.
De optie kan worden gespecificeerd met de vlag --max-allowed-packet=value bij het aanroepen van de mysqldump.
Zorg er bij het herstellen van de dump voor dat max_allowed_packet grootte van uw bestemmingsserver groot genoeg is om de pakketten van het dumpbestand te ontvangen.
Anders krijg je tijdens het herstellen van de dump een foutmelding:
ERROR 2006 (HY000) at line 70: MySQL server has gone away
Deze fout kan een beetje misleidend zijn, omdat je misschien denkt dat de MySQL-server is afgesloten of gecrasht. Maar het betekent alleen dat de server een groter pakket heeft ontvangen dan de geconfigureerde grootte van max_allowed_packet . Nogmaals, de beste werkwijze is ervoor te zorgen dat het max_allowed_packet waarde voor uw doelserver is hetzelfde als de waarde in de bronserver. Dit is ook een belangrijke instelling die vooraf kan worden gecontroleerd en op de juiste manier kan worden ingesteld, in plaats van de fouten op een later tijdstip onder ogen te zien.
In dit eerste deel van de mysqldump-serie hebben we de vereisten besproken voor een succesvolle dump- en herstelbewerking voor grote MySQL-databases om u te helpen meerdere pogingen en onproductieve tijdsbesteding te voorkomen.
In het volgende deel bespreken we best practices om de opgeslagen programma's en weergaven uit uw MySQL-database te importeren.