Yn ôfwachting fan it begjin fan in nije ynskriuwing foar de kursus Wy bliuwe in searje artikels publisearje oer fersifering yn MySQL.
Yn it foarige artikel yn dizze searje hawwe wy besprutsen, . Hjoed, basearre op de kennis krigen earder, litte wy sjen nei de rotaasje fan master kaaien.
Master-kaai-rotaasje omfettet it generearjen fan in nije master-kaai en it opnij fersiferjen fan de tablespace-kaaien (dy't wurde opslein yn 'e tablespace-koppen) mei dizze nije kaai.
Lit ús ûnthâlde hoe't de koptekst fan in fersifere tafelromte derút sjocht:
Ut it foarige artikel witte wy dat as de tsjinner begjint, it lêst de kopteksten fan alle fersifere tabelromten en ûnthâldt de grutste KEY ID. Bygelyks, as wy hawwe trije tabellen mei KEYID = 3 en ien tabel mei KEYID = 4, dan sil de maksimale kaai-ID 4 wêze. Litte wy dit KEY ID neame - MAX KEY ID.
Hoe master kaai rotation wurket
1. De brûker útfiert ALTER INNODB MASTER KEY.
2. De tsjinner freget de kaairing om in nije masterkaai te generearjen fan 'e tsjinner UUID en KEYID gelyk oan MAX ferhege mei ienKAAIID. Sa krije wy masterkaai-id lyk oan INNODBKEY-UUID- (MAXKAAIID + 1). By suksesfolle generaasje fan 'e masterkaai wurdt MAX KEY ID ferhege mei ien (d.w.s. MAXKAAIID=MAXKAAIID + 1).
3. De tsjinner scans alle tablespaces fersifere mei de master kaai, en foar eltse tablespace:
-
fersiferet de tablespace kaai mei in nije master kaai;
-
fernijt de kaai ID nei de nije MAXKAAIID;
-
as de UUID is oars as de tsjinner UUID, dan updates de tsjinner UUID.
Lykas wy witte, bestiet de Master Key ID dy't brûkt wurdt om in tabel te ûntsiferjen út in UUID en in KEY ID lêzen fan 'e tabelromtekop. Wat wy no dogge, is dizze ynformaasje bywurkje yn 'e koptekst fan' e tabelromte-kodearring sadat de tsjinner de juste haadkaai ûntfangt.
As wy tabelromten hawwe dy't fan ferskate plakken komme, lykas ferskate backups, dan kinne se ferskate masterkaaien brûke. Al dizze masterkaaien sille moatte wurde ophelle út it repository as de tsjinner begjint. Dit kin it opstarten fan de tsjinner fertrage, benammen as jo in server-basearre keystore brûke. Mei masterkaairotaasje fersiferje wy tablespace-kaaien opnij mei ien masterkaai dy't itselde is foar alle tablespaces. No, by it starten, soe de tsjinner mar ien masterkaai moatte ûntfange.
Dit is fansels gewoan in noflike side-effekt. It haaddoel fan draaiende masterkaaien is om ús server feiliger te meitsjen. As de masterkaai op ien of oare manier stellen is út 'e ferwulft (bygelyks fan' e Vault Server), dan kin in nije masterkaai oanmakke wurde en kinne de tabelromte-kaaien opnij fersifere wurde, wêrtroch't de stellen kaai ûnjildich is. Wy binne feilich... hast.
Yn in foarige artikel haw ik besprutsen hoe't ienris in tafelromte-kaai is stellen, in tredde partij it kin brûke om gegevens te ûntsiferjen. Op betingst dat der tagong is ta ús skiif. As de masterkaai stellen is en jo tagong hawwe ta de fersifere gegevens, kinne jo de stellen masterkaai brûke om de tafelromte-kaai te ûntsiferjen en de ûntsifere gegevens te krijen. Sa't jo sjen kinne, draait de master-kaai yn dit gefal net. Wy fersiferje de tabelromte-kaai opnij mei in nije masterkaai, mar de eigentlike kaai dy't brûkt wurdt om de gegevens te fersiferjen / ûntsiferje bliuwt itselde. Dêrom kin de "hacker" it trochgean brûke om gegevens te ûntsiferjen. Dat ha ik earder trochjûn kin útfiere wiere tablespace re-fersifering, net allinnich ienfâldige tablespace kaai re-fersifering. Dizze funksje wurdt fersiferingsthreads neamd. Dizze funksjonaliteit is lykwols noch eksperiminteel op it stuit.
Master-kaairotaasje is nuttich as de masterkaai stellen is, mar de oanfaller hat gjin manier om it te brûken en de tafelromte-kaaien te ûntsiferjen.
Lês mear:
Boarne: www.habr.com