Acum, să ne ia în considerare unele dintre fișierele implicate în procesul de replicare. Despre jurnal binar și releu de autentificare deja știu, dar există și alte obiecte de fișiere. Anumit locația de stocare depinde în principal de MySQL parametri de configurare. În diferite versiuni ale bazei de date implicite sunt diferite. Cel mai adesea ele pot fi găsite în directorul de date sau în directorul în care pid-server de fișiere (în sistemele bazate pe UNIX acest lucru este, de obicei directorul / var / run / mysqld /). Aici sunt.
În cazul în care intrarea în jurnalul binar este activat, serverul creează un fișier cu același nume ca și jurnalul binar, dar cu extensia
index. Acesta înregistrează toate fișierele binare jurnal de pe un disc. Acest lucru nu este un index în sensul în care vorbim despre indicii pe mese; pur și simplu este format din șiruri de text, fiecare cu numele unuia din fișierul jurnal binar. Probabil că aveți un gând că acest fișier este de prisos și pot fi eliminate (la urma urmei, MySQL este ușor de a găsi toate fișierele de pe disc). Nu o face! MySQL ignoră jurnalele binare care nu sunt listate în fișierul index.
Acest fișier este jucat același rol pentru jurnalele de releu care fișier pentru a jurnalele binare discutate mai sus.
Acest fișier conține informațiile cerute de slave pentru a se conecta la principal. Format text (o valoare pe linie) și variază în funcție de versiunea MySQL. Nu-l ștergeți, sau după repornirea slave nu știe cum să se conecteze la master. Deoarece acest fișier poate stoca parola unui utilizator în clar, este rezonabil să se limiteze drepturile de acces la acesta.
În acest fișier este stocat pe numele serverului slave la coordonatele sale curente de jurnal și replicare binare (de exemplu, în jurnalul binar de serverul principal, la care a venit slave). Nu șterge acest fișier, sau atunci când reporniți serverul slave nu va ști de ce loc pentru a continua replicare, și să încerce să reproducă comenzile deja executate.
Combinația acestor fișiere este un mod destul de simplu pentru a salva starea de replicare și reviste. Din păcate, recordul au făcut de sincronizare, așa că, dacă are loc o pană de curent atunci când fișierele nu au fost spălată pe disc, apoi, după repornire datele din ele vor fi incorecte.
În mod implicit, numele binar jurnal este format din numele gazdei la care se adaugă un sufix numeric, dar este mai bine să se stabilească numele de bază în mod explicit în fișierul my.cnf:
log_bir # Nu face acest lucru dacă nu doriți
log_bin_index = mysql-bin.index relay_log = mysql-releu-bin
De fapt, implicit index-fișierele moștenesc numele fișierelor jurnal respective, dar nu există nici un rău dacă le-ați setat în mod explicit.
Pe index-fișierele afectează, de asemenea expire_logs_days parametru, care determină cât de mult ar trebui să păstreze MySQL jurnalele binare deja închise. Dacă fișierul-mysql bin.index se face referire la fișiere care nu sunt pe disc, eliminarea automată nu va funcționa; chiar comanda PURGE MASTER BUȘTENI nu va funcționa. În general, pentru a rezolva această problemă, trebuie să încredințeze gestionarea jurnalele binare la un server MySQL, deci nu este confuz.
Este necesar să se dezvolte o strategie pentru îndepărtarea reviste vechi - folosind opțiunea expire_logs_days sau prin alte mijloace - în caz contrar, mai devreme sau mai târziu, MySQL jurnalele binare va umple întregul disc. Acesta ar trebui să ia în considerare politica de backup a organizației. Pentru mai multe informații despre jurnalul binar, consultați. În „binar Log Format“ la pag. 601.