Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

MySQL Absicherung und Datensicherung

2,955 views

Published on

Talk about MySQL Backup and Security, presented at the amoocon 2009 in Rostock, Germany

Published in: Technology
  • Be the first to comment

  • Be the first to like this

MySQL Absicherung und Datensicherung

  1. 1. 1 Sun Microsystems Methoden zur Absicherung und Datensicherung eines MySQL- Servers Lenz Grimmer MySQL Community Relations Manager
  2. 2. 2 Übersicht • Verbesserung der Server-Sicherheit > Integrierte Funktionalität > Auf Betriebssystem-Ebene • MySQL Datensicherung > physikalisch vs. logisch > Methoden und Werkzeuge
  3. 3. 3 MySQL-Absicherung • Wichtige Arbeitsschritte nach Erstinstallation • Sicherheit der Standardinstallation bereits relativ hoch • Zusätzliche Sicherungsmaßnahmen des Betriebssystems flankieren die im Server enthaltenen Funktionen http://dev.mysql.com/doc/refman/5.0/en/security.html
  4. 4. 4 Benutzerkonten • Kennwort für den root-User $ mysql -u root mysql mysql> SET PASSWORD FOR root@localhost=PASSWORD('new_password'); • Entfernen des anonymen Benutzers • Entfernen der test-Datenbank • Script: mysql_secure_installation • Konten: nur die erforderlichen • Privilegien: nur die notwendigen
  5. 5. 5 Prüfung der Zugriffsrechte • Verbindungsaufbau > Server überprüft anhand der user-Tabelle, ob ein passender Eintrag für username, host und passwort existiert • SQL-Abfrage > Server überprüft Privilegien anhand der user, db, tables_priv and column_privs Tabellen http://dev.mysql.com/doc/refman/5.0/en/privilege-system.html
  6. 6. 6 MySQL-Zugangskontrolle Query true false db true Query executed Permission denied false columns_priv false tables_priv false user true true
  7. 7. 7 Sicherheitsfunktionen • Nützliche Optionen in my.cfg: > bind-address – lauscht nur am einem TCP- Interface (z.B. 127.0.0.1) > skip-networking – Kommunikation nur lokal (via socket-Datei) • Wichtige SQL-Anweisungen: SHOW GRANTS, SET PASSWORD, GRANT/REVOKE • PROCESS/SUPER/FILE Privilegien minimieren
  8. 8. 8 Weitere Hinweise • Keine Benutzerkennwörter im Klartext in Tabellen speichern • MD5() oder SHA1(), nicht PASSWORD() • Verschlüsselung (SSL, SSH, VPN) • LOAD DATA LOCAL deaktivieren: --local-infile=0 • Nie mysqld als root-Benutzer ausführen • History-Datei ~/.mysql_history absichern oder löschen • MySQL root-User umbenennen
  9. 9. 9 Views & Stored Procedures • VIEWs können Zugriff auf bestimmte Spalten regeln > http://dev.mysql.com/doc/refman/5.0/en/views.html • Stored Procedures schirmen die realen Tabellen vor direkten Zugriffen durch Anwender und Applikationen ab > http://dev.mysql.com/doc/refman/5.0/en/stored-procedures.html • Seit MySQL 5.0 enthalten
  10. 10. 10 Absicherung auf OS-Ebene • Zugriff auf das Datenverzeichnis beschränken (chown/chmod) > Tabellen und Log-Dateien schützen • Keine Shell-Konten auf dem DB-Server • Kein direkter Zugriff auf Port 3306 aus dem Internet! • Firewall/DMZ/iptables • SELinux, AppArmor, RBAC • chroot(), Zones/Container, VMs
  11. 11. 11 Datensicherung • Notwendigkeit > Hardware-Ausfall > Anwender- oder Applikationsfehler • Zu sichernde Daten > Datenbankinhalte > Log-Dateien • Weitere Aspekte > Sicherungszeitpunkt > Ort der Sicherung und Aufbewahrung
  12. 12. 12 Wann werden Sicherungen benötigt? • Datenverlust durch Hardwarefehler > Absturz wg. Hardwareschaden > Festplattenausfall > Defekte Hardware • Anwender- und Applikationsfehler > DROP TABLE oder DELETE FROM ohne WHERE-Klausel > Development vs. Production DB > Öffnen der Tabellendateien mit der falschen Anwendung
  13. 13. 13 Was sollte gesichert werden? • Datenbankinhalte > Für komplette Sicherungen > Logisch oder phyikalisch • Log-Dateien > Für inkrementelle Sicherungen > Wiederherstellungszeitpunkte (Point in time recovery) • Konfigurationsdateien > /etc/my.cnf > Cron-Jobs
  14. 14. 14 Zeitpunkt der Datensicherung • Regelmäßig • Außerhalb der Lastspitzen • Wenig veränderliche Daten weniger häufig
  15. 15. 15 Speicherung der Sicherungskopien • Auf dem DB-Server > Besser nicht! > Zumindest auf einem separaten Dateisystem/ Volume oder Laufwerk • Kopiert auf einen anderen Server > Onsite oder offsite • Sicherung/Archivierung auf Band/Wechselplatte • An verteilten Orten
  16. 16. 16 Modulare Speicher-Engine-Architektur
  17. 17. 17 MySQL Datenverzeichnis • Alle Datenbanken und Logfiles werden standardmäßig hier gespeichert • Ort abhängig von der MySQL distribution (einkompilierter Wert): > /usr/local/mysql/data (tarball) > /var/lib/mysql (RPM) • Mit --datadir=/pfad/zum/datadir anpaßbar • SHOW VARIABLES LIKE 'datadir'; • InnoDB: innodb_data_home_dir
  18. 18. 18 Das Binärlog • Speichert alle datenverändernden SQL- Anweisungen (DML) z.B. CREATE, INSERT, DELETE, DROP, UPDATE • Zweck: > Erleichtert Datenwiederherstellung > Replikation • Enthält zusätzliche Informationen (Zeitstempel, Laufzeit) • Binär codiert, mysqlbinlog zum decodieren • Aktiviert mit --log-bin[=datei]
  19. 19. 19 Log-Management • Server rotiert die Logs • Log-Indexdatei verzeichnet alle Logs • SHOW MASTER LOGS – listet alle auf dem Server vorhandenen logs • FLUSH LOGS – rotiert logs • RESET MASTER – löscht alle binärlogs • PURGE MASTER – löscht alle binärlogs bis zu einem best. Zeitpunkt
  20. 20. 20 Sicherungsmethoden • logisch: SQL-Anweisungen • physikalisch: Tabellendateien • vollständig vs. inkrementell > Aktivieren des Binärlogs > Zeitpunktbezogene Wiederherstellung
  21. 21. 21 Gängige MySQL-Sicherungspraktiken • mysqldump > Vollständige Sicherung $ mysqldump mydb > mydb.20050925.sql > Struktur und/oder Daten als SQL- Anweisungen: CREATE TABLE, INSERT > Einzelne Tabellen oder Datenbanken möglich > portabel, aber unhandlich bei großen Datenmengen • Mit anderen Unix-Werkzeugen kombinierbar (Piping) $ mysqldump ­­opt world | mysql ­h remote.host.com world
  22. 22. 22 mysqldump - Tipps • --lock-all-tables – nützlich für konsistente MyISAM-Backups > Aber sperrt alle DML-Anweisungen • --flush-logs – synchronisiert das Binärlog (Checkpointing)
  23. 23. 23 Sicherung von InnoDB-Tabellen • mysqldump --single-transaction erstellt konsistente Sicherungskopie ohne Locking • Physikalische Sicherung > MySQL-Server herunterfahren! > Datenfiles, InnoDB log-Dateien, .frm-Dateien sichern > Server wieder starten
  24. 24. 24 XtraBackup / Maatkit • https://launchpad.net/percona-xtrabackup • Online-Backup für InnoDB • In my.cnf: > [xtrabackup] target_dir = /home/backups • Backup-Kommando: > xtrabackup –backup • http://maatkit.org/ • Multi-threaded Perl wrapper scripts > mk-parallel-dump / mk-parallel-restore
  25. 25. 25 Weitere Sicherungsmöglichkeiten • Replikation > Sicherung erfolgt auf Slave > Bonus: erhöhte Verfügbarkeit • Dateisystem-Snapshots > „semi-hot“ > Linux: LVM (mylvmbackup) > Solaris: ZFS (mysql-snapback) • MySQL 6.0: Online Backup API http://forge.mysql.com/wiki/OnlineBackup
  26. 26. 26 Backups über Dateisystem-Snapshots • Bequeme und schnelle Lösung zur unterbrechungsfreien Sicherung vollständiger Datenbanken • Geringer Platzbedarf des LVM-Snapshots (10-15% reichen üblicherweise aus) • Backup der Dateien auf dem Snapshot Volumen mit beliebigen Tools • Beeinträchtigung der I/O Performance (Linux LVM)
  27. 27. 27 Linux LVM Snapshot-Erzeugung Funktionsprinzip: mysql> FLUSH TABLES WITH READ LOCK $ lvcreate -s –-size=<size> --name=backup <LV> mysql> UNLOCK TABLES $ mount /dev/<VG>/backup /mnt $ tar czvf backup.tar.gz /mnt/* $ umount /mnt $ lvremove /dev/<VG>/backup
  28. 28. 28 Das mylvmbackup-Script • Script zur schnellen Erzeugung von MySQL- Backups mit LVM-Snapshots • Snapshots werden in ein temporäres Verzeichnis eingehängt, die Daten werden mit tar,rsync oder rsnap gesichert • Archivnames mit Zeitstempeln ermöglichen wiederholte Backup-Läufe ohne Überschreiben • Kann vor dem Backup InnoDB- Wiederherstellung auf dem Snapshot durchführen • Benötigt Perl, DBI and DBD::mysql • http://www.lenzg.net/mylvmbackup/
  29. 29. 29 Werkzeuge • Shell: cp, tar, cpio, gzip, zip, cron • rsync, unison, rsnapshot, rdiff • afbackup, Amanda/Zmanda, Bacula • Nicht auf live-Daten anwenden! (ma.gnolia.com anyone?)
  30. 30. 30 Wiederherstellung • Letzte vollständige Sicherungskopie (+ binäre Logdatei) • Einspielen des SQL-Dumps oder Kopieren der gesicherten Tabellendateien • Wiederherstellung eines bestimmten Zeitpunkts (point-in-time recovery) durch Zeitstempel im Binärlog möglich
  31. 31. 31 Beispiel Wiederherstellung • Letzte vollständige Sicherung einspielen: $ mysql < backup.sql • Einspielen der inkrementellen Änderungen seit der letzten vollständigen Sicherung: $ mysqlbinlog hostname-bin.000001 | mysql
  32. 32. 32 Vergleich der Sicherungsmethoden • Portabilität (SQL Dumps vs. Tabellendateien) • Geschwindigkeit, Speicherbedarf • Overhead und Beeinträchtigung des Betriebs
  33. 33. 33 Sicherungsstrategien • Regelmäßige Durchführung • Binärlog aktivieren • Log-Dateien synchronisieren (FLUSH LOGS) • SQL-Dumps konsistent und verständlich benennen (z.B. mit Zeitstempel im Dateinamen) • Aufbewahrung der Sicherungen auf anderen Dateisystemen
  34. 34. 34 Generelle Backup-Hinweise • Binärlogs auf einem anderen Laufwerk/Dateisystem ablegen > Verbesserte Performance > Vermeidet vollständigen Datenverlust • Backups auf Vollständigkeit/Korrektheit überprüfen • Prozeduren und Zeitpläne für Backups und Wiederherstellung festlegen • Testen, ob sie auch wirklich funktionieren!
  35. 35. 35 Vielen Dank! Fragen, Kommentare, Anregungen? Lenz Grimmer <lenz@sun.com>

×