Linux-Magazin_-_Januar_2019

nur eine bestimmte Anzahl Sekunden
warten soll:

SQL> ALTER TABLE test WAIT 5 ADD U
COLUMN bla INT;
ERROR 1205 (HY000): Lock wait timeout U
exceeded; try restarting transaction

Dieses Verhalten wird mit dem Begriff
Fast Fail bezeichnet.
Eine ähnliche Änderung betrifft auch
den »TRUNCATE-TABLE«-Befehl. Bisher
hat er die Meta Data Locks einfach ig-
noriert, was streng genommen zu einer
Verletzung der ACID-Bedingungen führte.
Jetzt beachtet der »TRUNCATE TABLE«-
Befehl den Meta Data Lock und lässt sich
entsprechend auch mit »NOWAIT« oder
»WAIT« ausstatten.
Früher hat ein »ALTER TABLE«-Befehl
bei Maria DB immer ein komplettes
Umkopieren der Tabelle erforderlich ge-
macht. Seit Maria DB 10.0 können viele
»ALTER TABLE«-Befehle in-place ohne
Kopieren der Daten erfolgen. Mit der
»ALGORITHM«-Klausel lässt sich steu-
ern, ob das alte Verfahren (»COPY«) oder
das neue In-place-Verfahren (»INPLACE«)
zu verwenden ist.
Das In-place-Verfahren hat allerdings ei-
nen negativen Effekt: Es kann extrem
lange dauern und die Datenbankins-
tanz dramatisch ausbremsen. Aus die-
sem Grund wurden die beiden neuen
Optionen »INSTANT« und »NOCOPY«
eingeführt. »INSTANT« verweigert den
»ALTER«-Befehl, wenn Datenfiles zu mo-
difizieren wären, und »NOCOPY« verwei-
gert den Dienst, wenn der geclusterte In-
dex (Primary Key) und somit die gesamte
Tabelle umzubauen wäre:

SQL> ALTER TABLE test ADD INDEX U
(data), ALGORITHM = INSTANT;
ERROR 1846 (0A000): ALGORITHM=INSTANT U
is not supported. Reason: ADD INDEX. U
Try ALGORITHM=NOCOPY

Dies erlaubt es dem Admin, ohne genau-
ere Kenntnisse des internen Verhaltens
mehr Sicherheit bei diesen Befehlen zu
erlangen.
Zwei weitere, sehr praktische Features
sind »Instant ADD COLUMN« und »HID-
DEN COLUMN«. Das erste dieser beiden
Features erlaubt das Anlegen einer neuen
Spalte, ohne dass dabei die teure Opera-
tion des Tabellen-Umkopierens erfolgen
muss. Das Anlegen einer neuen Spalte

dauert nicht viel län-

ger als das Einfügen

einer Zeile.

Ein paar Einschrän-

kungen sind allerdings

zu beachten: »Ins-

tant ADD COLUMN«

funktioniert nicht auf

Tabellen mit einem

Volltext-Index, zudem

muss die neue Spalte

an letzter Stelle ste-

hen. Auch diese Fea-

tures wurden von der

Maria-DB-Community

beigesteuert, und zwar

von Alibaba und Ten-

cent.

Die umgekehrte Ope-

ration – ein »DROP

COLUMN« – setzt aber

ein komplettes Umko-

pieren der Tabelle in

Gang, was sehr lange

dauert. Aus einem Google-Summer-of-

Code-Projekt sind hierzu Invisible Co-

lumns (unsichtbare Spalten) entstanden.

Statt eine Spalte zu löschen, kann der

Anwender sie einfach für unsichtbar er-

klären (Listing 11) und bei einer späteren

Gelegenheit löschen, wenn er die Tabelle

sowieso umbauen muss.

Wer die Spalte explizit referenziert, kann

sie aber trotzdem noch anzeigen oder

auch füllen. Ein genaues Sichten des Ap-

plikationscodes bleibt dem Admin also

dennoch nicht erspart, wenn er Spalten

entfernen will:

SQL> SELECT * FROM test LIMIT 1;

+‑‑‑+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑+

| 3 | Some data |2018‑09‑11 17:47:04|NULL |

+‑‑‑+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑+

Lange laufende, offene Transaktionen

sind für eine Datenbank ein Problem,

weil sie gegebenenfalls Locks aufrecht-

erhalten muss, die andere Anwendungen

blockieren, und weil sie alle Datenände-

rungen bis zurück zur ältesten offenen

Transaktion vorhalten muss, um gegebe-

nenfalls diese Daten noch zur Verfügung

stellen zu können. Erfahrene Datenbank-

entwickler sind sich des Problems be-

wusst und arbeiten vorsichtig. Wer das

aber nicht berücksichtigt, der trägt zu

Blockaden oder im schlimmsten Fall zum

völligen Kollaps der Datenbank bei.

Für dieses Szenario gibt Maria DB 10.3

dem Admin neuerdings die Möglichkeit

an die Hand, bei lange laufenden, ideln-

den Transaktionen die Verbindung zu

schließen. Dies erfolgt durch die Variab-

len »idle_readonly_transaction_timeout«,

»idle_readwrite_transaction_timeout« so-

wie für beide zusammen »idle_transac-

tion_timeout« (Listing 12).

Client

Server 2

Shard 2

2, 5, 8

Server 1

Shard 1

1, 4, 7

Server 3

Shard 3

3, 6, 9

Server 0

Spider

1, 2, 3, 4, 5,

6, 7, 8, 9

Abbildung 3: Die Spider Storage Engine verteilt Daten über verschiedene

Instanzen, bietet sie gegenüber dem Client aber als Einheit an.

01 SQL> ALTER TABLE test MODIFY COLUMN bla

int INVISIBLE, ALGORITHM = INSTANT;

02 Query OK, 0 rows affected (0.001 sec)

03

04 SQL> SELECT * FROM test LIMIT 1;

05 +‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

06 | id | data | ts |

07 +‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

08 | 3 | Some data | 2018‑09‑11 17:47:04 |

09 +‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑+‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑+

Listing 11: Spalte unsichtbar

machen

01 SQL> SET SESSION

idle_readonly_transaction_timeout = 5;

02 SQL> START TRANSACTION READ ONLY;

03 SQL> do sleep(6);

04 Query OK, 0 rows affected (6.000 sec)

05

06 SQL> do sleep(6);

07 ERROR 2006 (HY000): MySQL server has gone away

Listing 12: Idle Timeouts

71

http://www.linux-magazin.de

Sysadmin

Maria DB 10.3