sql >> Database >  >> RDS >> Mysql

Grote MySQL InnoDB-tabellen wijzigen

Bewerk 2016: we hebben onlangs (augustus 2016) gh-ost . uitgebracht , mijn antwoord aanpassen om het weer te geven.

Tegenwoordig zijn er verschillende tools waarmee u online tabellen voor MySQL kunt wijzigen. Dit zijn:

Laten we eens kijken naar de "normale" `ALTER TABLE`:

Het duurt lang voordat een grote tafel ALTER . is . innodb_buffer_pool_size is belangrijk, en dat geldt ook voor andere variabelen, maar op een zeer grote tabel zijn ze allemaal verwaarloosbaar. Het kost gewoon tijd.

Wat MySQL doet met ALTER een tabel is om een ​​nieuwe tabel met een nieuw formaat te maken, alle rijen te kopiëren en vervolgens over te schakelen. Gedurende deze tijd is de tafel volledig vergrendeld.

Overweeg je eigen suggestie:

Het zal hoogstwaarschijnlijk het slechtst presteren van alle opties. Waarom is dat? Omdat u een InnoDB-tabel gebruikt, moet de INSERT INTO tablename_tmp SELECT * FROM tablename zorgt voor een transactie. een enorme transactie. Het zal zelfs meer belasting creëren dan de normale ALTER TABLE .

Bovendien moet u uw applicatie op dat moment afsluiten zodat deze niet schrijft (INSERT , DELETE , UPDATE ) aan je tafel. Als dat zo is, is je hele transactie zinloos.

Wat de online tools bieden

De tools werken niet allemaal hetzelfde. De basis wordt echter gedeeld:

  • Ze maken een "schaduw"-tabel met gewijzigd schema
  • Ze maken en gebruiken triggers om wijzigingen van de oorspronkelijke tabel naar de spooktabel door te voeren
  • Ze langzaam kopieer alle rijen van uw tabel naar schaduwtabel. Dat doen ze in brokken:zeg maar 1.000 rijen per keer.
  • Ze doen al het bovenstaande terwijl je nog steeds in staat bent om de originele tabel te openen en te manipuleren.
  • Als ze tevreden zijn, verwisselen ze de twee met een RENAME .

De openark-kit tool is nu 3,5 jaar in gebruik. De Percona-tool is een paar maanden oud, maar mogelijk meer getest dan de vorige. De tool van Facebook zou goed werken voor Facebook, maar biedt geen algemene oplossing voor de gemiddelde gebruiker. Ik heb het zelf niet gebruikt.

Bewerk 2016: gh-ost is een triggerloze oplossing die de schrijfbelasting van de master op de master aanzienlijk vermindert, waardoor de schrijfbelasting van de migratie wordt losgekoppeld van de normale belasting. Het is controleerbaar, controleerbaar, testbaar. We hebben het intern op GitHub ontwikkeld en als open source uitgebracht; we doen al onze productiemigraties via gh-ost vandaag. Zie hier .

Elke tool heeft zijn eigen beperkingen, kijk goed naar de documentatie.

De conservatieve manier

De conservatieve manier is om een ​​Active-Passive Master-Master-replicatie te gebruiken, doe de ALTER op de standby (passieve) server, wissel dan van rol en doe de ALTER weer op wat vroeger de actieve server was, nu passief geworden. Dit is ook een goede optie, maar vereist een extra server en diepere kennis van replicatie.



  1. Afstemmen van SQL-statements in SQL Developer

  2. Selecteer verschillende records voor een join

  3. Een koude stand-by maken voor PostgreSQL met Amazon AWS

  4. Barman gebruiken om een ​​back-up te maken van PostgreSQL - een overzicht