Construirea unui sistem cu toleranță la erori cu Oracle Physical Standby
Prin implementarea unui sistem informatic bazat pe baza de date Oracle și prin organizarea unei strategii fiabile de recuperare a backup-ului, este posibilă începerea operării de producție a sistemului. În cazul unui accident, va fi posibilă restaurarea datelor la timpul necesar. Dar ce se întâmplă dacă timpul de repaus permis nu trebuie să depășească câteva minute? Apoi, nu puteți face fără moduri diferite de duplicare a datelor în timp real.
Structura Oracle Data Guard
În funcție de cerințele specifice privind timpul de recuperare și pierderea admisibilă a datelor în caz de accident (obiectiv de recuperare, obiectiv de recuperare [2]). Sunt posibile diferite scenarii de implementare:
- Așteptare fizică DB - baza de date de rezervă este o copie fizică exactă a primarului, este în starea montat și, în același timp, este transferat fluxul informațiilor de redo.
- Logică de așteptare DB - baza de date de rezervă nu este o copie exactă a bazei de date principale, este deschisă în modul citire-scriere și fluxul de comenzi SQL este transferat.
Dacă este necesar, o astfel de bază poate fi activată într-un timp scurt ca fiind una industrială.
Deoarece baza de date logică de așteptare nu este o copie exactă a bazei de date primare, și nu acceptă anumite tipuri de date, SQL-comandă, există o cerință de a asigura unicitatea de rânduri în tabele [4], considerăm că punerea în aplicare a exact fizice Standby DB. Mi se pare că folosirea DB Logic Standby este mai bine nu ca o copie de rezervă, ci ca o bază de date pentru rapoarte. Am ales pentru primar și de rezervă a bazelor de date următoarele setări: unități de producție care funcționează în modul maxim de disponibilitate, a trecut modificările sunt aplicate în modul de așteptare a bazei de date în timp real Apply Redo. Pentru acest mod de operare, procesul LGWR inițiază transferul de informații despre modificări. Diferența dintre regimurile de protecție este faptul că în modul de protecție maximă, tranzacția este înregistrată numai în cazul în care înregistrarea este făcută în revistele locale, și de la distanță, în caz de imposibilitate a bazei de date de înregistrări șterse se oprește și în modul de performanță maximă pentru a continua munca trebuie doar o înregistrare locală , iar baza de date principală continuă să funcționeze, chiar dacă nu există nicio conexiune la baza de date de rezervă.
Modul de disponibilitate maximă reprezintă o opțiune de compromis, schimbând automat cele două moduri. Dacă link-ul funcționează fără erori, transmisia are loc în mod sincron, în cazul în care apare o defecțiune, se efectuează automat trecerea la un mod mai puțin stricte. După eliminarea erorilor, se restabilește modul maxim de protecție [5].
Ce aveți nevoie pentru a crea un mediu de testare:
- Două servere cu aceeași arhitectură, ele pot diferi în ceea ce privește numărul de procesoare, memorie, discuri, lansarea sistemului de operare etc. Permiteți serverului primar DB să fie numit Poltava, iar serverul de așteptare este Fastiv.
- Modul bază de date trebuie să fie ARCHIVELOG.
- Trebuie să utilizați Oracle Server Enterprise Edition Edition. În teste, vom folosi versiunea Oracle10.2 a EE pentru Solaris.
Pregătirea configurației de lucru
Așadar, avem o bază de date Oracle primară de lucru localizată pe serverul Poltava și trebuie să creăm o bază de date standby în standby pe serverul Fastiv. Trebuie să pregătiți fișierele de configurare și să efectuați setări suplimentare.
Permiteți numelui bazei de date să fie "TST", atribuiți valoarea ORACLE_SID = ORCL pentru baza de producție primară, pentru standby - DB ORACLE_SID = ORCL1. Fișierele DB primare sunt în directorul / tstb / ORCL, fișierele de așteptare DB sunt în directorul / tstb / ORCL1.
Este necesar să efectuați următoarele acțiuni:
Activați logarea forței pe sistemul de producție pentru a forța informațiile din jurnalele bazei de date, chiar și pentru așa-numitele operațiuni de Nologging:
SQL> ALTER DATABASE FORCE LOGGING;
Creați fișierul de așteptare pentru reluarea fișierelor. Acestea sunt necesare doar pentru funcționarea bazei de date în așteptare, dar le vom crea atât pe bază primară, cât și pe standby, în cazul schimbării rolurilor între baze de date, nu va fi nevoie să le creați.
Redo-ul de așteptare a fișierelor trebuie să fie creat nu mai mic decât redo-ul online, iar numărul n + 1 din numărul grupului de redo (a se vedea Lista 1).
Listarea 1. Adăugarea fișierelor în modul Repaus în așteptare
sqlplus "/ ca sysdba" < ALTER DATABASE ADAȚI STANDBY LOGFILE GROUP 4 '/tstb/ORCL/redo01.stb' SIZE 100M REUSE; ALTER DATABASE ADAȚI STANDBY LOGFILE GROUP 5 '/tstb/ORCL/redo02.stb' SIZE 100M REUSE; ALTER DATABASE ADAȚI STANDBY LOGFILE GROUP 6 '/tstb/ORCL/redo03.stb' SIZE 100M REUSE; ALTER DATABASE ADAȚI STANDBY LOGFILE GROUP 7 '/tstb/ORCL/redo04.stb' SIZE 100M REUSE; Setați parametrii în fișierele parametrilor init.ora / spfile.ora pentru primar și în așteptare (consultați Listă 2). Listarea 2. Lista parametrilor pentru init.ora / spfile.ora * .control_files = '/ tstb / ORCL / control01.ctl', '/tstb/ORCL/control02.ctl', '/tstb/ORCL/control03.ctl' * .LOG_ARCHIVE_DEST_1 = 'LOCATION = / tstb / log1 / VALID_FOR = (ALL_LOGFILES, ALL_ROLES) DB_UNIQUE_NAME = Kiev' * .LOG_ARCHIVE_DEST_2 = 'SERVICE = Fastiv LGWR SYNC AFFIRM VALID_FOR = (ONLINE_LOGFILES, PRIMARY_ROLE) DB_UNIQUE_NAME = Fastiv' Crearea unei baze de date standby în așteptare Creați copii de siguranță ale bazei de date și fișierului de parolă și transferați fișierele copiate pe serverul Fastiv de rezervă. Deoarece valorile ORACLE_SID pentru bazele de date primare și de rezervă sunt diferite, fișierele de parolă vor avea de asemenea nume diferite, de exemplu, orapwORCL și orapwORCL1. Creați un fișier de control în așteptare și copiați-l pe serverul de așteptare în locația specificată în fișierul bază de date în așteptare: SQL> ALTER DATABASE CREAȚI STANDBY CONTROLFILE AS '/tmp/standby.ctl'; Schimbați baza de date principală la modul de capacitate maximă cu următoarea comandă: SQL> ALTER DATABASE SET BANDA DE DATE DE STANDBY PENTRU A MAXIMIZA DISPONIBILITATEA; Bazele de date sunt pregătite să funcționeze. Acum puteți să porniți ambele baze de date. Operații DB în timpul funcționării În timpul operării este necesară efectuarea anumitor acțiuni - pornire, oprire, deschidere pentru citire, logare a jurnalelor pierdute, activarea unei baze de date de rezervă (failover), schimbarea stării (trecerea la comutare). Luați în considerare aceste operațiuni: Scenariul stbstart este responsabil pentru pornirea bazei de date standby în modul de aplicare în timp real. Oprirea opțiunii de așteptare DB este furnizată de scriptul stbshut (a se vedea Lista 4). Listarea 4. Pornirea și oprirea bazei de date fizice în așteptare sqlplus "/ ca sysdba" < modificați baza de date de bază de așteptare pentru baza de date; ALTER DATABASE RECOVEREAZĂ BAZA DE BAZĂ DE STANDBY MANAGATĂ UTILIZAREA LOGOFILULUI CURENT DECONECTAȚI DE LA SESIUNE; sqlplus "/ ca sysdba" < ALTER DATABASE RECOVEREAZĂ CALITATEA DE BAZĂ DE BAZĂ DE BAZĂ DE MANAGEMENT STANDBY; Să verificăm mecanismul de trecere a modificărilor prin comutarea jurnalelor. Pe principalele: SQL> ALTER SISTEM SWITCH LOGFILE; SQL> SELECT GROUP #, THREAD #, SEQUENCE #, ARHIVAT, STATUS DE LA V $ STANDBY_LOG; Scriptul este responsabil pentru pornirea bazei de date standby în modul read-only (vezi lista 5). Livrarea de Redo în acest caz continuă, dar modificările vor fi amânate până la ieșirea din acest mod. Listing 5. Rularea bazei de date standby în modul read-only sqlplus "/ ca sysdba" < ALTER DATABASE RECOVEREAZĂ CALITATEA DE BAZĂ DE BAZĂ DE BAZĂ DE MANAGEMENT STANDBY; modificați baza de date numai pentru citire; Switchover - un script pentru schimbarea rolurilor între baze de date. Este necesar ca baza de date primară să fie deschisă, iar modul de așteptare trebuie să fie în modul de montare sau recuperare (a se vedea Lista 6). După cum puteți vedea în scenariu, pentru a schimba rolurile, trebuie să aveți acces la fiecare dintre bazele de date implicate în operație. Listing 6. Schimbul de roluri între bazele de date Poltava și Fastiv sqlplus "/ ca sysdba" < REM se conectează primar conectați sys / manager @ poltava ca sysdba coloana SWITCHOVER_STATUS format A20 rubrica "Stare comutare" primar " SELECTAȚI SWITCHOVER_STATUS DIN V \ $ DATABASE; coloana DATABASE_ROLE format A20 rubrica "Rolul înainte de trecerea la comutare" selectați DATABASE_ROLE din V \ $ DATABASE; ALTER DATABASE ANGAJAM PENTRU TRANSMITEREA LA STANDBY FIZICĂ; coloana DATABASE_ROLE format A20 rubrica "Rol după oprire" selectați DATABASE_ROLE din V \ $ DATABASE; REM conectați regimul de așteptare db la modul de aplicare redo conectați sys / manager @ fastiv ca sysdba coloana SWITCHOVER_STATUS format A20 rubrica "Stare comutare" standby " SELECTAȚI SWITCHOVER_STATUS DIN V \ $ DATABASE; coloana DATABASE_ROLE format A20 rubrica "Rolul înainte de trecerea la comutare" selectați DATABASE_ROLE din V \ $ DATABASE; ALTER DATABASE ANGAJAM PENTRU TRANSMITERE LA PRIMAR; ALTER DATABASE OPEN; REM dacă este doar în citire, nu deschideți - reporniți REM SHUTDOWN IMMEDIATE; coloana DATABASE_ROLE format A20 rubrica "Rol după oprire" selectați DATABASE_ROLE din V \ $ DATABASE; Failover este un script care activează baza de date de rezervă în cazul unui accident de bază. Deoarece nu mai există o bază de date de rezervă, înainte de activarea bazei de date de rezervă, aceasta trebuie transferată în modul de performanță maximă (a se vedea Lista 7). SQL> ALTER DATABASE SET STANDBY DATABASE PENTRU MAXIMIZAREA PERFORMANȚEI; Înregistrarea jurnalelor pierdute este prezentată în mod clar în Lista 8. Listing 7. Activarea unei baze de date de rezervă în caz de accident sqlplus "/ ca sysdba" < coloana DATABASE_ROLE format A15 rubrica "Rolul înainte de trecerea la comutare" selectați DATABASE_ROLE din V \ $ DATABASE; ALTER DATABASE RECOVEREAZĂ FORȚA DE FINALIZARE A GESTIUNII DE BAZĂ DE BAZĂ STANDBY; ALTER DATABASE ANGAJAM PENTRU TRANSMITERE LA PRIMAR; ALTER DATABASE SETTAȚI DATABASE STANDBY PENTRU MAXIMIZAREA PERFORMANȚEI; ALTER DATABASE OPEN; coloana DATABASE_ROLE format A15 rubrica "Rolul după trecerea la comutare" selectați DATABASE_ROLE din V \ $ DATABASE; Listare 8. Definirea și permiterea manuală a transmiterii buștenilor SQL> SELECTAȚI LISTA #, LOW_SEQUENCE #, HIGH_SEQUENCE # FROM V $ ARCHIVE_GAP; THREAD # LOW_SEQUENCE # HIGH_SEQUENCE # SQL> ALTER DATABASE REGISTRARE FISICĂ LOGFILE 'filespec1'; Automatizați monitorizarea muncii Deoarece baza de date primară se află în modul maxim de disponibilitate, baza de date principală va continua să funcționeze dacă serverul în așteptare este oprit. Între starea primară și cea de așteptare se formează un decalaj. Pentru a detecta și rezolva o defecțiune, este nevoie de timp ca baza de date care se află subiacent să nu fie susținută. În acest moment, în cazul unui accident repetat deja în baza de date principală, este posibilă pierderea datelor. Pentru a detecta și a elimina astfel de situații în timp util, este necesar să se automatizeze procesul de monitorizare a funcționării ambelor baze de date. Listing 9. Un script care caută erori în fișierul alert.log dacă [-f / tmp / memsg_no] FILESLIST = "ls -R / ora / admin / * / bdump / * .log dir1 = `dirname $ | sed 's / \ / ora \ / admin \ /// g MSG = '/ usr / local / bin / fetchlog -F 1: 100: 1000: s $ / var / adm / $. MSG1 = "echo" $ "| egrep -i "ora-" ` Acest lucru se poate face, de exemplu, folosind pachetul fetchlog [6]. Pe baza acestui software, a fost creat scriptul fetchalert (vezi Listing 9), care poate fi lansat folosind daemonul crond: testcase $ 0,15,30,45 * * * * / usr / local / bin / fetchalert> / dev / null 2> 1 Schema propusă este simplă și nu necesită hardware special pentru implementarea acesteia, dar are și dezavantaje: Dar este posibil ca acești factori să nu aibă un impact grav asupra sistemului, deoarece tehnologiile moderne de rețea permit transmiterea unor volume mari de date pe distanțe semnificative, iar un server mai mic poate fi folosit ca rezervă.
Trimiteți-le prietenilor: