Die InnoDB Storage Engine. Handy aus?

Transkript

1 Die InnoDB Storage Engine Kristian Köhntopp Handy aus?

2 InnoDB: Vorteile, Nachteile Vorteile: Transaktionen MVCC Row Locks OLTP Concurrency Crash-Recovery Nachteile: Höherer Platzbedarf Höherer Speicherbedarf Höhere I/O-Last MyISAM oft für DWH

3 InnoDB in Betrieb nehmen SHOW ENGINES; NO, DISABLED, YES, DEFAULT innodb (statt skip-innodb) innodb_file_per_table=1 innodb_log_file_size = 128M innodb_buffer_pool_size =???M /etc/sysctl.conf: vm.swappiness = 0

4 Wo liegen meine Daten? $datadir/ibdata1 Tablespace File: Shadow Data Dictionary, Undo Log, Doublewrite Buffer $datadir/<db>/<table>.ibd Tabellendaten

5 Nach InnoDB konvertieren ALTER TABLE t ENGINE=InnoDB Kein FULLTEXT Keine GIS-Typen Keine zusammengesetzten auto_increment ca. 1.6 bis 3 mal größer als MyISAM Doppelt konvertieren?

6 Transaktionen create table t ( id serial, d varchar(20) ) engine=innodb; insert into t (d) values ('eins'),('zwei'),('drei'); begin work; insert into t (d) values ( 'vier' ); select * from t; rollback; select * from t;

7 Transaktionen update t set d = "one" where id = 1; Table t Undo Log id d txn# id d txn# one > 1 eins 1 2 zwei drei MVCC = Multi Value Concurrency Control

8 MVCC (Jim Starkey) In MVCC kann ein Leser niemals durch einen Schreiber blockiert werden. Spezialfall: SELECT... FOR UPDATE Dies ist ein Lesezugriff, der wie ein Schreibzugriff lockt.

9 Rollback rollback; Table t Undo Log id d txn# id d txn# ROLLBACK eins 1 < zwei drei

10 Rollback: Kosten Commit: Schnell (Nix zu tun) Rollback: Langsam (Zeilenweises zurückkopieren der Daten Andere Lösungen: Versionierte Zeilen in der Tabelle stehen lassen (Postgres) Schnelles Rollback, Vacuum, Index-Probleme

11 Isolation Level: Read Uncommitted set transaction isolation level read uncommitted; Lese die Daten aus t, nie aus dem Undo- Log. Lese Daten, die nie dagewesen sind.

12 Isolation Level: Read committed set transaction isolation level read committed; Lese Daten, die der Schreiber committed hat. Gehe maximal eine Ebene tief ins Undo Log. Zweifaches Lesen = Daten können sich ändern = Read nicht transaktional.

13 Isolation Level: Repeatable Read set transaction isolation level repeatableread; Lies die neuste Zeile aus dem Undo-Log, die alt genug ist, um für den Reader sichtbar zu sein. Lineare Liste im Undo-Log. Begin Select Select Commit verschieden von Select-Select!

14 Kosten von Isolation Der Eintrag im Undo-Log muß sowieso gemacht werden! Rollback. Das Holen alter Rows ist etwas teurer. Das Löschen alter Rows wird verzögert. Finde die älteste aktive Transaktion im System. Lösche alle Einträge im Undo-Log, die noch älter sind. ( Begin vacation?)

15 Read-Modify-Write begin select... from t where id =? Anwendung denkt. update t set... where id =? <- X-Lock commit Anwendung denkt ungeschützt. Write-Lock erst bei Update

16 Read-Modify-Write begin select... from t where id =? for update Anwendung denkt. update t set... where id =? commit <- X-Lock select for update : Locktechnisch ein Schreibzugriff!

17 Isolation Level Serializeable set transacktion isolation level serializeable; select... from t where id =? lock in share mode Verhindert konkurrente Schreibzugriffe. Ersetzt kein RMW-FOR UPDATE.

18 Locks und Constraints Foreign Key Constraints: create table t ( tid serial, sid bigint unsigned not null references s (sid), index (sid) ) engine = innodb;

19 Locks und Constraints update t set... where tid = 2 X-Lock auf t.tid = 2 Außerdem S-Lock auf s.sid. on s.sid = t.sid where t.tid = 2 Nie in Data Warehouses! Nie in selbstreferentiellen Strukturen! Nie in hoch konkurrenten Strukturen!

20 Writes und Locks Locks werden auf den Index gelegt. Next-Key-Locking WHERE id = 20 -> Lock 20->29 EXPLAIN! Type = ALL -> sehr teures Table Lock In der Realität selten ein Problem: WHERE-Clause ist vom Update, d.h. PK-Zugriff?

21 Konfiguration

22 Transaktionsablauf Erzeuge Transaktion im Log Buffer. On Commit: write(2) in das Redo Log. fdatasync(2) das Redo Log. kein write aus dem Buffer Pool in den Table Space -> Page dirty

23 Transaktionsablauf Datenbank idle, Redo Log voll, zu viele Pages dirty On Checkpoint: wähle Pages vom Redo-Log Ende. writev(2) und fdatasync(2) in den Doublewrite Buffer. Bewege Redo Log Pointer. writev(2) noch einmal an die finale Position.

24 Transaktionsablauf Entweder: fdatasync(2) Oder: Dateien mit O_DIRECT geöffnet. innodb_flush_method Controller mit BBU kaufen!

25 Konfigurationsvariablen innodb_log_buffer_size = 8M innodb_log_file_size = 256M innodb_log_files_in_group = 2 innodb_buffer_pool_size = (80% RAM) innodb_max_dirty_pages_pct = 90

26 Konfigurationsvariablen innodb_flush_log_at_trx_commit = 1 (2) innodb_flush_method = fdatasync (O_DIRECT) innodb_file_per_table = 1 innodb_data_file_path = ibdata1:10m:autoextend innodb_autoextend_increment = 8

27 Konfigurationsvariablen innodb_open_files = 2048 open_files_limit = innodb_additional_mem_pool_size = 4M