{"id":89872,"date":"2020-07-27T01:42:19","date_gmt":"2020-07-26T23:42:19","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/raspredelyonnye-subd-dlya-enterprajza"},"modified":"2020-07-27T01:42:19","modified_gmt":"2020-07-26T23:42:19","slug":"raspredelyonnye-subd-dlya-enterprajza","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/raspredelyonnye-subd-dlya-enterprajza","title":{"rendered":"Rozproszone bazy danych dla przedsi\u0119biorstw","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Teoria CAP jest kamieniem w\u0119gielnym teorii system\u00f3w rozproszonych. Oczywi\u015bcie, kontrowersje wok\u00f3\u0142 niej nie milkn\u0105: definicje nie s\u0105 kanoniczne, a \u015bcis\u0142ego dowodu brak\u2026 Niemniej jednak, stoj\u0105c mocno na pozycjach zdrowego rozs\u0105dku™, intuicyjnie rozumiemy, \u017ce teorema jest prawdziwa.<\/p>\n

\"Rozproszone
\n
\nJedyn\u0105 rzecz\u0105, kt\u00f3ra nie jest oczywista, jest znaczenie litery \u201eP\u201d. Kiedy klaster si\u0119 rozdziela, decyduje \u2013 czy nie odpowiada\u0107, a\u017c zostanie osi\u0105gni\u0119ta wi\u0119kszo\u015b\u0107, czy te\u017c przekaza\u0107 dost\u0119pne dane. W zale\u017cno\u015bci od wynik\u00f3w tego wyboru, system klasyfikowany jest jako CP lub AP. Cassandra, na przyk\u0142ad, mo\u017ce dzia\u0142a\u0107 w obu trybach, w zale\u017cno\u015bci nie tylko od ustawie\u0144 klastra, ale tak\u017ce od parametr\u00f3w ka\u017cdego konkretnego zapytania. Ale je\u015bli system nie jest \u201eP\u201d, a si\u0119 rozdzieli, to co si\u0119 dzieje?<\/p>\n

Odpowied\u017a na to pytanie jest nieco zaskakuj\u0105ca: klaster CA nie mo\u017ce si\u0119 rozdzieli\u0107.
\nCzym jest taki klaster, kt\u00f3ry nie mo\u017ce si\u0119 rozdzieli\u0107?
\n<\/a><\/noindex>
\nNiezb\u0119dnym atrybutem takiego klastra jest wsp\u00f3lny system przechowywania danych. W przewa\u017caj\u0105cej wi\u0119kszo\u015bci przypadk\u00f3w oznacza to pod\u0142\u0105czenie przez SAN, co ogranicza zastosowanie rozwi\u0105za\u0144 CA do du\u017cych przedsi\u0119biorstw, kt\u00f3re mog\u0105 utrzyma\u0107 infrastruktur\u0119 SAN. Aby kilka serwer\u00f3w<\/a> mog\u0142o pracowa\u0107 z tymi samymi danymi, potrzebny jest klastrowy system plik\u00f3w. Takie systemy plik\u00f3w s\u0105 dost\u0119pne w portfolio HPE (CFS), Veritas (VxCFS) i IBM (GPFS). <\/p>\n

Oracle RAC<\/h4>\n

\nOpcja Real Application Cluster pojawi\u0142a si\u0119 po raz pierwszy w 2001 roku w wersji Oracle 9i. W takim klastrze kilka instancji serwera<\/a> pracuje z t\u0105 sam\u0105 baz\u0105 danych.
\nOracle mo\u017ce dzia\u0142a\u0107 zar\u00f3wno z klastrowym systemem plik\u00f3w, jak i z w\u0142asnym rozwi\u0105zaniem \u2013 ASM, Automatic Storage Management.<\/p>\n

Ka\u017cda instancja prowadzi sw\u00f3j dziennik. Transakcja jest wykonywana i rejestrowana przez jedn\u0105 instancj\u0119. W przypadku awarii instancji, jeden z ocala\u0142ych w\u0119z\u0142\u00f3w klastra (instancji) odczytuje jej dziennik i przywraca utracone dane \u2013 dzi\u0119ki temu zapewniana jest dost\u0119pno\u015b\u0107.<\/p>\n

Wszystkie instancje maj\u0105 w\u0142asn\u0105 pami\u0119\u0107 podr\u0119czn\u0105, a te same strony (blokad) mog\u0105 znajdowa\u0107 si\u0119 jednocze\u015bnie w pami\u0119ciach podr\u0119cznych wielu instancji. Co wi\u0119cej, je\u015bli jaka\u015b strona jest potrzebna jednej instancji i znajduje si\u0119 w pami\u0119ci podr\u0119cznej innej instancji, mo\u017ce ona uzyska\u0107 j\u0105 od \"s\u0105siada\" dzi\u0119ki mechanizmowi cache fusion, zamiast odczytywa\u0107 dane z dysku.<\/p>\n

\"Rozproszone
\n
\nCo si\u0119 stanie, je\u015bli jeden z egzemplarzy b\u0119dzie musia\u0142 zmieni\u0107 dane?<\/p>\n

Cech\u0105 Oracle jest to, \u017ce nie ma dedykowanej us\u0142ugi blokad: je\u015bli serwer chce zablokowa\u0107 wiersz, to informacja o blokadzie jest umieszczana bezpo\u015brednio na tej stronie pami\u0119ci, na kt\u00f3rej znajduje si\u0119 blokowany wiersz. Dzi\u0119ki temu podej\u015bciu Oracle jest mistrzem wydajno\u015bci w\u015br\u00f3d monolitycznych baz: serwis blokad nigdy nie staje si\u0119 w\u0105skim gard\u0142em. Jednak w konfiguracji klastrowej taka architektura mo\u017ce prowadzi\u0107 do intensywnej wymiany danych w sieci i wzajemnych blokad.<\/p>\n

Gdy tylko wiersz zostanie zablokowany, egzemplarz powiadamia wszystkie pozosta\u0142e egzemplarze, \u017ce strona, na kt\u00f3rej znajduje si\u0119 ten wiersz, zosta\u0142a zaj\u0119ta w trybie monopolowym. Je\u015bli inny egzemplarz b\u0119dzie chcia\u0142 zmieni\u0107 wiersz na tej samej stronie, musi czeka\u0107, a\u017c zmiany na stronie zostan\u0105 zatwierdzone, tzn. informacja o zmianie zostanie zapisana w dzienniku na dysku (przy czym transakcja mo\u017ce trwa\u0107). Mo\u017ce si\u0119 zdarzy\u0107, \u017ce strona zostanie zmieniona kolejno przez kilka egzemplarzy, a wtedy przy zapisie strony na dysku trzeba b\u0119dzie ustali\u0107, u kt\u00f3rego egzemplarza znajduje si\u0119 aktualna wersja tej strony.<\/p>\n

Przypadkowa aktualizacja tych samych stron przez r\u00f3\u017cne w\u0119z\u0142y RAC prowadzi do znacznego spadku wydajno\u015bci bazy danych \u2013 a\u017c do tego, \u017ce wydajno\u015b\u0107 klastra mo\u017ce by\u0107 ni\u017csza ni\u017c wydajno\u015b\u0107 pojedynczego egzemplarza.<\/p>\n

Prawid\u0142owe wykorzystanie Oracle RAC polega na fizycznym podziale danych (na przyk\u0142ad za pomoc\u0105 mechanizmu tabel partycjonowanych) i odwo\u0142ywaniu si\u0119 do ka\u017cdego zestawu partycji przez dedykowany w\u0119ze\u0142. G\u0142\u00f3wnym celem RAC sta\u0142o si\u0119 nie poziome skalowanie, ale zapewnienie odporno\u015bci na awarie.<\/p>\n

Je\u015bli w\u0119ze\u0142 przestaje odpowiada\u0107 na sygna\u0142y heartbeat, to ten w\u0119ze\u0142, kt\u00f3ry jako pierwszy to zauwa\u017cy\u0142, uruchamia procedur\u0119 g\u0142osowania na dysku. Je\u015bli i tu zaginiony w\u0119ze\u0142 si\u0119 nie zaznaczy, to jeden z w\u0119z\u0142\u00f3w przejmuje obowi\u0105zki dotycz\u0105ce przywracania danych:<\/p>\n