MySQL Replikation, Scale-Out, Master- Master Replikation, Backup

Published on May 2016 | Categories: Types, Speeches | Downloads: 17 | Comments: 0 | Views: 107
of 35
Download PDF   Embed   Report

Comments

Content

MySQL Replikation, Scale-Out, MasterMaster Replikation, Backup

DOAG Regioaltreffen, München 23. März 2011 Oli Sennhauser
Senior MySQL Consultant, FromDual GmbH

[email protected]

www.fromdual.com

1

Inhalt
MySQL Replikation HA Solutions
➢ ➢ ➢ ➢ ➢ ➢ ➢ ➢

Scale-Out Read scale-out MySQL Replikation Replication set-up for HA Master-Master fail-over Active/passive Replikation Binary Cluster MySQLLog Formate Semi-Synchrone Replikation Replication Cluster Backup Methoden Storage-Engine-Replication Restore SE Replikation mit PBXT

www.fromdual.com

2

Über FromDual GmbH


Wir bieten an:
● ● ● ●

Neutrale und Hersteller unabhängige Beratung für MySQL Support für MySQL (7 x 24) Remote-DBA / MySQL Betrieb (wir betreiben Ihre MySQL DB!) Schulung und Workshops (DBA, Performance Tuning, ScaleOut, High Availability, MySQL Cluster) Consulting Partner der Open Database Alliance (ODBA.org) Oracle Silber Partner (OPN)



Wir sind:
● ●

http://www.fromdual.com
www.fromdual.com 3

Zuerst gab's da mal ein Problem:
Kosten ● MySQL Design ● Physikalische Flaschenhälse ● „Relaxation of Constraints“


Scale-Up



Web-Applikationen typischerweise: r >> w

Scale-Out
4

www.fromdual.com

Der MySQL Scale-Out Ansatz
Applikation ro rtw Master Slave Reporting Slave Backup Slave 1 Slave 2 Slave 3 ...

Load balancer

Web-Applikationen typischerweise: r >> w
www.fromdual.com 5

Master – Slave Replikation
binlog dump thread Async!
bin-log.index

Application

master.info

IO_ thread
relay-log.info

binary log writer thread

Master

Slave

SQL_ thread

...

bin-log.m

bin-log.n

...

relay-log.m

relay-log.n

www.fromdual.com

6

Erstellen eines Masters


Binary Log einschalten und Server ID setzen (erfordert Neutstart): # my.cnf [mysqld] log_bin   = binary_log server_id = 42



User mit REPLICATION SLAVE Privileg anlegen: CREATE USER replication@'%' IDENTIFIED BY 'secret'; GRANT REPLICATION SLAVE ON *.* TO replication@'%';



Konsistentes Backup vom Master erstellen:
mysqldump ­­all­databases {­­single­transaction | ­­lock­ all­tables} ­­master­data > full_dump.sql



MySQL Dokumentation: How to Set Up Replication
http://dev.mysql.com/doc/refman/5.5/en/replication-howto.html
www.fromdual.com 7

Erstellen eines Slaves


Server_id in my.cnf setzen Dem Slave zeigen, wo sein Master sitzt:




CHANGE MASTER TO master_host='masterserver',  master_port=3306, master_user='replication',  master_password='secret'



Einspielen des konsistenten Backups vom Master: mysql ­u root < full_dump.sql Überprüfen ob auf dem Slave alles i.O. ist: SHOW SLAVE STATUS\G Slave starten: START SLAVE;
www.fromdual.com 8





Für was kann man Slaves alles brauchen?
Applikation ro rtw Master Slave Reporting Slave Backup Slave 1 Slave 2 Slave 3 ...

Load balancer

Web-Applikationen typischerweise: r >> w
www.fromdual.com 9

Massives Scale-Out
M ... ... ... ... S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S 5s ... S S S ... S S ... S ...



Jetzt können sie auch erahnen wozu die BLACKHOLE SE gebraucht wird...
www.fromdual.com 10

Tool zur Verwaltung solcher Setup's


Problem: Wenn Master kaputt geht, müssen alle Slaves neu gebaut werden... Aber es gibt Tricks: Tool von Yandex.ru (Petya Kohts):
● ● ●

● ●

mmmf, multi-master mysql failover http://www.nigilist.ru/nit/mmmf/ http://cpan.uwinnipeg.ca/~kohts/mmmf

www.fromdual.com

11

Master – Master Replikation
Applikation

VIP

M1

M2

Slave 1
● ●

Slave 2

Slave 3

Slave Backup

Vorsicht beim Schreiben auf beide Master Man erhält so NICHT mehr I/O-Durchsatz!
www.fromdual.com 12

Tool zur Verwaltung solcher Setup's


Ähnliches Problem wie bei Master-Slave Replikation mit zusätzlicher Komplexität durch zirkuläre Replikation Keine Konflikt-Detektion/Auflösung! Achtung: Wir sind asynchron! Tool:
● ● ●

● ● ●

Multi-Master Replication Manager for MySQL http://mysql-mmm.org/ https://launchpad.net/mysql-mmm
www.fromdual.com 13

Binary Log Formate


Bis MySQL 5.0 nur Statement Based Replikation (SBR)
+ Weniger Traffic - Non-determistic Queries! - Mehr Locking (grössere Locks)
# at 786 #110321 20:55:40 server id 35154  end_log_pos 814       Intvar SET INSERT_ID=3/*!*/; # at 814 #110321 20:55:40 server id 35154  end_log_pos 944       Query   thread_id=3     exec_time=0     error_code=0 SET TIMESTAMP=1300737340/*!*/; INSERT INTO test VALUES (NULL, 'Statement based replikation', NULL)

www.fromdual.com

14

Binary Log Formate


Ab MySQL 5.1 auch Row Based Replication (RBR)
+ All Änderungen können nun repliziert werden. + Weniger Locking / manchmal schneller - Binary Log ist weniger transparent / mehr Traffic



Mixed (SBR default, wechselt auf RBR b. Bed.)
# at 844 #110321 20:57:36 server id 35154  end_log_pos 912       Query   thread_id=2     exec_time=0     error_code=0 SET TIMESTAMP=1300737456/*!*/; BEGIN /*!*/; # at 912 # at 959 #110321 20:57:36 server id 35154  end_log_pos 959       Table_map: `test`.`test` mapped to number 15 #110321 20:57:36 server id 35154  end_log_pos 1019      Write_rows: table id 15 flags: STMT_END_F BINLOG 'sK2HTRNSiQAALwAAAL8DAAAAAA8AAAAAAAEABHRlc3QABHRlc3QAAwMPBwJAAAI= sK2HTRdSiQAAPAAAAPsDAAAAAA8AAAAAAAEAA//4BwAAABVSb3cgYmFzZWQgcmVwbGlrYXRpb26w RydN'/*!*/; mysqlbinlog ­­base64­output=decode­rows ­­verbose bin­log.000002

www.fromdual.com

15

Semi-Synchrone Replikation
● ●

Bis 5.1 nur asynchrone Replikation! Ab 5.5 auch semi-synchrone Replikation:
binlog dump thread IO_ thread

binary log writer thread

Master

Slave

SQL_ thread

...

bin-log.m

bin-log.n

...

relay-log.m

relay-log.n

www.fromdual.com

16

Backup Methoden

www.fromdual.com

17

Backup Methoden


mysqldump Filesystem Kopie / mysqlhotcopy Snapshot mit LVM / btrfs InnoDB Hot Backup (ibbackup/xtrabackup) Backup Replikation Slave



● ● ●

www.fromdual.com

18

mysqldump


Charakteristik


Logisches Backup, hot/on-line, lokal oder remote, konsistent Einfach, lokal oder remote, Standard-Backup für MySQL, konsistent, Strukturdump möglich Kann falsch gemacht werden, blockiert MyISAM Tabellen fürs Schreiben, nicht geeignet für sehr grosse Datenmengen, Restore-Zeiten!
www.fromdual.com 19



Vorteile




Nachteile


Filesystem Kopie / mysqlhotcopy


Charakteristik


Physisches Backup, hot, local Schneller Restore, konsistent Nur bedingt für InnoDB geeignet, blockiert Tabellen für Schreibzugriffe.



Vorteile




Nachteile


www.fromdual.com

20

Snapshot mit LVM / btrfs


Charakteristik


Physisches Backup, hot, lokal Sehr schnelle Backup Methode, ziemlich schnelles Restore, konsistent Benötigt root Rechte, etwas komplizierter und Hardware intensiver, möglicherweise gefährlich mit InnoDB?
www.fromdual.com 21



Vorteile




Nachteile


Wie wird ein LVM Snapshopt Backup gemacht?


Alle DB files müssen auf dem selben Logical Volume liegen (LV = Partition) Locken der Datenbank Erstellen eines Snapshots des Logical Volumes Unlocken der Datenbank Mounten des Snapshot Logical Volumes InnoDB Recovery testen Backup (tar, compress, tape) der Datenbank Files Löschen des Snapshot Logical Volumes → Etwas kompliziert: mylvmsnapshot
www.fromdual.com 22















Wie funktionieren LVM Snapshots?

LVM device

LVM snapshot device

copy-on-write
www.fromdual.com 23

InnoDB Hot backup (ibbackup, xtrabackup)


Charakteristik


Physisches Backup, hot/on-line, lokal, konsistent, inkremental Schnelles Backup/Restore für InnoDB Löst die MyISAM Probleme nicht



Vorteile




Nachteile


www.fromdual.com

24

Backup mit OEB/XtraBackup


Volles Backup erstellen:
xtrabackup ­­backup ­­target­dir=...



Prepare (~recovery):


xtrabackup ­­prepare ­­target­dir=...



Restore?


Einfach MySQL auf den Files wieder starten...

www.fromdual.com

25

Backup Replikation Slave


Charakteristik


Logisches oder physisches backup, hot/on-line, konsitent Betrifft Master überhaupt nicht. „Beste“ Methode aus Sicht des Masters. Braucht zusätzliche Hardware (oder zumindest Ressourcen) Sicherstellen, dass Slave nicht driftet. Achtung: Wir erstellen ein Backup auf dem Slave: != Master



Vorteile




Nachteile
● ● ●

www.fromdual.com

26

Restore / Recovery

www.fromdual.com

27

Restore / Recovery


Restore / Recovery besteht aus bis zu 3 verschiedenen Schritten:


Restore der Daten oder der Tabellen oder den Files Auto-recovery der transaktionalen SE (InnoDB, PBXT, NDB) Point-in-Time-Recovery (PITR)





● ●

Schritt 1 und 2 sind klar? Was ist PITR?
www.fromdual.com 28

Point-in-Time-Recovery (PITR)
Application Application Application binary log writer thread

log_bin = on

mysqld

bin-log.1

bin-log.2

...

bin-log.n

pos/time? full backup

t
www.fromdual.com 29

Warum ein Restore getested werden sollte?


Restore können sehr sehr lange dauern.........


Überprüfen Sie Ihre MTTR!



Warum dauert der Restore eines logischen Backups so lange?
→ Restore Tabelle, Create Index → random I/O


So lange Ihr Index in den Cache/Buffer passt ist es OK, aber wehe wenn nicht...! Man kann da etwas drum herum schummeln mit Fast Index Creation im InnoDB Plug-in oder MySQL 5.5...



www.fromdual.com

30

Justify your restore
Production Prod Acc Development Test Dev

bck nightly restore

DBA

Developer

www.fromdual.com

31

Storage Engine Replikation mit PBXT
● ●

MySQL Replikation ist nicht sehr schnell Man kann die Replikation leicht falsch aufsetzen / Fehler machen. Warum so kompliziert über mind. 3 Threads und 2 Files? → Die PBXT SE v2.0 implementiert Replikation auf Storage Engine Ebene:
www.fromdual.com 32



Overhead der MySQL Replikation

www.fromdual.com

33

Architektur der PBXT Replikation

www.fromdual.com

34

Overhead der PBXT Replikation

www.fromdual.com

35

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close