1 / 31

CAPITOLE AVANSATE DE BAZE DE DATE

CAPITOLE AVANSATE DE BAZE DE DATE. SQL-Server. Availability. Availability. Hot standby solution No data loss (de obicei – include plus automatic failure detection, automatic failover) Warm standby solution Possible data loss (no automatic failure detection, no automatic failover).

hera
Télécharger la présentation

CAPITOLE AVANSATE DE BAZE DE DATE

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CAPITOLE AVANSATE DE BAZE DE DATE SQL-Server. Availability

  2. Availability • Hot standby solution • No data loss • (de obicei – include plus automatic failure detection, automatic failover) • Warm standby solution • Possible data loss • (no automatic failure detection, no automatic failover)

  3. Database Snapshots • Copii read-only, point-in-time ale unei baze de date sursa; no transaction log CREATE DATABASE DB_SN_name ON (files…)[, ...] AS SNAPSHOT OF DB_SOURCE_name • Se creeaza la un anumit moment, si contine datele care au existat in acel moment in bd sursa, si au fost afectate ulterior (modificate sau sterse; doar la prima modificare, versiunea originala se scrie in snapshot db) fisiere si filegroup-uri pe aceeasi structura ca a db sursa

  4. Database Snapshots • Copy-on-write

  5. Database Snapshots • Copy-on-write

  6. Database Snapshots • Pot sa existe mai multe snapshot-uri ale aceleiasi baze de date la un moment dat • Initial – snapshot-ul e gol • Creste pe masura ce se modifica date in baza de date sursa • Catalog al paginilor modificate (bitmap of db pages) – initial 0, si la modificarea unei pagini – bitul sau devine 1 => pentru rezolvarea interogarilor • Limitari • Nu permite back-up, restore, detach pe snapshot • Nu permite drop, detach, restore, schimbari structurale (fisiere) pe BD sursa atata timp cat are cel putin un snapshot • BD sursa si snapshot sunt pe aceeasi instanta de server • Si altele

  7. Database Snapshots • Restore din snapshot RESTORE DATABASE DB_name FROM DATABASE_SNAPSHOT = DB_SNAPSHOT_name

  8. Log Shipping • Primary DB + (1..n) Secondary DB + (opt) Monitor Server • Permite proces automatizat care include operatiile • Backup log (de pe primary database) • Copiere de log backup • Restore de log backup (pe unul sau mai multe secondary databases) • => bd principala si bd secundara sunt sincronizate periodic • => este posibil ca bd secundara sa nu contina (inca) date / modificari din bd principala • Obs: Se pot folosi db secundare pentru interogari distribuite – performanta • Obs: BD primara si secundare pot sa fie pe doua server-e diferite sau doua instante diferite pe acelasi server

  9. Log Shipping • => Warm standby solution / warm standby copy • In caz de defect al bd principale (devine indisponibila), nu exista mecanism de failover automatic => bd secundara trebuie restaurata si adusa online manual • Server-e implicate • Primary server & primary database – bd disponibila pentru aplicatii (production server) • Secondary server & secondary database – bd care primeste log-urile de la bd principala, nu e online • (Opt) Monitor server – monitorizeaza log shipping (cand a avut loc ultimul backup, copy, restore) si poate sa trimita alerte cand procesul de sincronizare nu are loc conform planificarii • Obs: Pentru un sistem mai rezistent la defecte, ar trebui ca server-ele primar, secundar si de monitorizare sa fie diferite

  10. Log Shipping • Log shipping jobs (SQL Server Agent jobs) • Backup job – pe serverul principal, pentru bd principala; creeaza log backup, sterge backup-urile mai vechi • Copy job – pe serverul secundar; copiaza log backup se pe serverul principal pe serverul secundar (cale configurabila) • Restore job – restore de log backup pe bd secundara; sterge vechile fisiere de backup • (Opt) Alert job – pe serverul de monitorizare; emite alerte in caz de log shipping failure

  11. Log Shipping • Config (1) • Primary DB – in full sau bulk-logged recovery model • Este activata Primary DB pentru log shipping • Se seteaza directorul (shared) in care se vor salva log backups, durata de pastrare a backup-urilor, timpul pentru alerte in cazul in care nu are loc backup cf. planificarii, “orarul” de executie al backup job • Se configureaza Secondary DB(‘s) (identificare, credentiale, ...) (gata initializata sau restaurata dintr-un full backup al primary DB)

  12. Log Shipping • Config (2) • Se seteaza directorul (shared) unde vor fi copiate log backups pentru restore, durata de pastrare a backup-urilor, “orarul” de executie al job-ului de copiere, “orarul” de executie al restore job, alert times, ... • Secondary DB: • Nu se poate seta sa fie in “recovery mode” (sub aceasta stare, la un restore de log, executa REDO + UNDO) • => Se poate seta sa fie in: • No recovery mode (no REDO, no UNDO, no access) (availability) • Standby mode (read-only, UNDO + Transaction Undo File (for RE-DO on committed transactions)) (availability + scalability) • Monitor Server – optional – history & status (informatia de monitorizare se inregistreaza atat pe server-ele unde ruleaza job-urile, cat si pe monitor server)

  13. Log Shipping • Manual failover • Daca Primary DB e accesibila => creeaza log backup • Restore toate transaction log backups (care nu au fost folosite inca) pe Secondary DB • Dezactiveaza job-urile • Configureaza Secondary DB ca Primary DB

  14. Database Mirroring • Permite existenta unui standby server hot sau warm, cu automatic failover si no data latency • => copie duplicat a unei baze de date, pe alta instanta de SQL-Server • Principal DB + Mirror DB + (Opt) Witness Server • Inregistrari de transaction log de pe Principal DB sunt trimise pe Mirror DB

  15. Database Mirroring • Principal DB • Sursa tranzactiilor in sesiunea de mirroring • Full recovery model • Production DB • Mirror DB • Primeste inregistrarile de transaction log de la Principal DB • Replay”” operatiile pe Mirror DB (le scrie mai intai in transaction log propriu, apoi scrie modificarile in fisierul de date) • Recovering state (nu este disponibila pentru conexiuni, operatii de citire / scriere) • Full recovery model • Permite snapshot DB

  16. Database Mirroring • Witness Server (opt) • Automatic failure detection & automatic failover • Rol de arbitru • 1 Principal DB -> 1 Mirror DB • 1 Mirror DB -> 1 Principal DB • 1 Witness Server -> (1..n) Mirroring Session

  17. Database Mirroring • Config (1) • Full recovery model (Principal DB & Mirror DB) • Backup Principal DB • Restore Mirror DB (WITH NORECOVERY) (full backup + (opt) n log backups => sincronizare) • (Opt) Copiere de obiecte sistem (logins, linked servers, ...) • Stabilire Endpoints (TCP cu payload DATABASE_MIRRORING, ROLE = PARTNER | WITNESS | ALL)

  18. Database Mirroring • Config (2) • Stabilire Endpoints • Un mod de control al conectarii securizate pe o instanta SQL Server • TCP (payload = TSQL | SERVICE_BROKER | DATABASE_MIRRORING) • HTTP endpoints (serveste cereri SOAP) • => TCP pentru comunicatiile intre instantele implicate in mirroring, la nivel de instanta (nu de DB) • => payload = DATABASE_MIRRORING (max 1 TCP DB_MIRROR endpoint per instance)

  19. Database Mirroring • Config (2) • Stabilire Endpoints • Ofera mai multe nivele de securitate: • Type & payload definition (vor refuza cereri de un alt tip) • Se specifica port pentru TCP endpoint + (opt) Listener IP (lista de IP-uri de la care sa primeasca cereri; by default – any) • Metoda de autentificare (Win sau certificate) (vezi domeniile) • Metoda de criptare (RC4, AES) • GRANT CONNECT – pentru login-urile partenerilor • State = STARTED (STOPPED / DISABLED) • Role = PARTNER (P or M) / WITNESS (W) / ALL

  20. Database Mirroring • Moduri de operare • High Availability • Principal DB + Mirror DB + Witness Server • Hot standby configuration • Transfer sincron / Automatic failure detection / Automatic failover • (*) Se scriu inregistrarile in transaction log al Principal DB • (modificarile sunt scrise in Principal DB) • Se transfera inregistrarile de transaction log catre Mirror DB (operatie declansata de (*)) • (operatile sunt replayed pe Mirror DB) • Cand se primeste operatia Commit pe Primary DB, tranzactia este mai intai comisa pe Mirror DB, se trimite confirmarea pe Principal DB, se comite si pe Principal DB, apoi se trimite confirmarea comiterii catre aplicatie • => toate operatiile sunt scrise in ambele transaction log si toate tranzactiile sunt comise pe Principal si Mirror DB • Performanta scazuta – costuri de sincronizare

  21. Database Mirroring • High Availability • Witness Server • Testeaza Principal DB si Mirror DB (ping) • (se asemenea, Mirror DB trimite ping catre Principal DB) • Cand Mirror DB nu mai poate lua legatura cu Principal DB, ia legatura cu Witness Server; daca si Witness Server detecteaza failure pe Principal DB, efectueaza (automat) switch de roluri (Mirror DB <-> Principal DB) • Inversarea de roluri are nevoie de qvorum: Mirror DB solicita sa fie promovat Principal DB, Witness Server poate comunica cu Mirror, dar nu poate comunica cu Principal, Witness e de acord (operatie arbitrata de Witness) => switch de roluri • (daca Witness si Mirror nu pot comunica, nu se efectueaza switch-ul) • Cand fostul Principal DB revine online, detecteaza ca fostul Mirror este Principal, devine Mirror, si flow-ul de transaction log records se reia dinspre noul Principal catre noul Mirror • W online => hot standby; W not online => warm standby

  22. Database Mirroring • Moduri de operare • High Performance • Principal DB + Mirror DB (no Witness Server) • Warm standby configuration • Transfer asincron / No automatic failure detection / No automatic failover • Se scriu inregistrari in transaction log al Principal DB, se comit tranzactiile pe Principal DB, se trimite confirmarea comiterii aplicatiei • Un proces separat trimite blocuri de inregistrari de transaction log (tranzactii) catre Mirror DB • => nu se poate asigura failover automat deoarece e posibil ca Mirror DB sa nu fi primit ultimele operatii efectuate pe Principal DB • => failover manual (cu eventuale pierderi de ultime operatii) • => performanta in executia operatiilor pe Principal DB

  23. Database Mirroring • Moduri de operare • High Protection • Similar High Availability • No Witness Server • Transfer sincron / Automatic failure detection / Manual failover • => nu se poate forma qvorum in caz de failure => manual se promoveaza Mirror DB in rol de Principal DB

  24. Database Mirroring • Observatie: Failover manual • High Availability & High Protection (@Principal DB) (ex: inainte ca Principal DB sa intre intr-o etapa de mentenanta) ALTER DATABASE SET PARTNER FAILOVER • High Performance (Mirror DB – in recovering state) (pana cand Principal DB revine online, sesiunea de mirroring este suspendata) ALTER DATABASE DB_name SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS • Observatie: Failover pentru aplicatii • VS 2005 (MDAC tool) -> • Un feature pentru obiectele connection: Transparent Client Redirect: • obiectul connection realizeaza conexiunea catre Principal DB • in caz de failure, obiectul connection trimite eroare catre client, se incearca re-conectarea, moment in care se reface conexiunea catre Mirror DB

  25. Other availability techniques • Backup • (vezi curs anterior)

  26. Other availability techniques (BDD) • Replicare: availability – in general, din considerente geografice; BDD • Article – obiecte care sunt replicate • Publication – grup de articole care sunt replicate • Publisher – originalul proprietar al obiectelor care sunt publicate • Distributor – gestioneaza replicarea; local (D = P) sau remote (D <> P) • Subscriber – primeste obiectele publicate (replici ale acestora); read-only sau updatable • Subscrieri: • Push – Distributor copiaza date in BD Subscriber • Pull – Subscriber ia date de la Distributor

  27. Replication

  28. Replication • Tipuri de replicare • Snapshot • Se copiaza un intreg set de date (articolele publicate) de la Publisher la Subscriber(-i), cu suprascriere, dupa un anumit orar prestabilit (sau manual) • Transactional • Pas 1: Se copiaza articolele publicate la fiecare Subscriber • Pas 2: Se sincronizeaza doar datele modificate (de la ultima sincronizare) – se trimit catre Subscriber ultimele modificari (pe baza de transaction log) • Merge • Pas 1: Se copiaza articolele publicate la fiecare Subscriber • Pas 2: La fiecare site (Publisher sau Subscriber) se pot efectua modificari asupra datelor replicate • Pas 3: Sincronizare: se iau modificarile efectuate de la fiecare site, se trimit modificarile catre toate celelalte site-uri, cu eventuale rezolvari de conflicte (de exemplu: primul / ultimul care a modificat o inregistrare, valoarea minima / maxima de pe coloana modificata, s.a.)

  29. Replication • Snapshot

  30. Replication • Transactional

  31. Replication • Merge

More Related