Mysql InnoDb na surowym urządzeniu w topologii aktywnej/pasywnej

Question

Mamy topologię aktywną/pasywną, w której występują dwa kompleksy x86 ze współużytkowaną pamięcią masową, gdzie tylko jeden węzeł w danym momencie ma dostęp do współużytkowanej pamięć (AKA, aktywny węzeł). W przypadku przełączenia awaryjnego w aktywnym węźle pasywny węzeł inicjuje przejęcie i staje się aktywnym węzłem z dostępem do współużytkowanej pamięci masowej. Każdy węzeł ma własną pamięć urządzenia rozruchowego z systemem plików, jednak współużytkowana pamięć nie może mieć zamontowanego na niej systemu plików.

Jesteśmy zainteresowani instalacją serwera Mysql na obu węzłach, gdzie jego dane znajdują się we współużytkowanej pamięci masowej i tylko aktywny węzeł działa na serwerze.

Mysql with InnoDb is capable of running on a raw device, a tam jest również przewodnik, jak uruchomić Mysql over a cluster similar to our topology. Jednak w drugim przykładzie mają system plików zamontowany we współużytkowanej pamięci masowej. Problem związany z systemem plików budzi poważne obawy:

ib_logfile * nadal wymaga systemu plików. Więc surowa funkcja mysql nie jest dokładnie w pełni surowa. Proszę mnie poprawić, jeśli się mylę. Czy istnieje obejście do przechowywania tych plików w surowej pamięci masowej? Możemy jednak zapisać ib_logi w urządzeniu rozruchowym węzła i zawsze usuwać te pliki przed uruchomieniem serwera, jednak może to spowodować, że niezatwierdzona transakcja zostanie częściowo zatwierdzona w przypadku niepowodzenia w trakcie transakcji, co jest sprzeczne cała idea transakcji.

Czy są jeszcze jakieś pliki/funkcje, które mogą wpływać na zachowanie mysql w tej topologii?

Answer 1

Każda instalacja mysql składa się z 2 katalogów. 1. Katalog aplikacji 2. Katalog danych. Katalog danych zawiera wszystkie dane bazy danych. Zawiera pliki danych i pliki dziennika. Katalog danych może znajdować się we współużytkowanej pamięci i katalogu aplikacji na serwerach lokalnych, a kiedy chcesz przełączyć się z aktywnego na pasywne, zamkniesz (jeśli się nie zmiażdży) aktywny i uruchom serwer pasywny z uprawnieniami do udostępniania przechowywanie. Ponieważ pliki dziennika znajdują się we współużytkowanej pamięci masowej, nowy aktywny serwer odzyska utraconą transakcję. Należy pamiętać, że w tej topologii serwer pasywny jest wyłączony i dopiero po jego włączeniu zostanie uruchomiony.

Answer 2

Prawdopodobnie nie lubię tej odpowiedzi, ale tu idzie ...

Nie staraj się robić to, co opisane.

Chroni przed tylko jedną rzecz - awarię serwera (inną niż dysk). Tymczasem awaria dysku, awaria sieci, trzęsienie ziemi, powódź itp. Mogą zniszczyć system. Po co chronić tylko przed jednym scenariuszem awarii?

Powrót do planu wstępnego ... Jeśli serwer aktywny zginie, należy uniemożliwić mu zapisanie niczego więcej w plikach MySQL. Dopiero wtedy można włączyć pasywny mysqld. Będzie (zakładając, że używasz InnoDB) odzyskać to, co potrafi z dysku. Należy pamiętać, że rzeczy na aktywnym prawdopodobnie czekały na wyplenienie z pamięci RAM.

Czy twoim celem jest, aby "surowe" urządzenie było jakoś "lepsze"?

"Raw" nie jest już przydatny. Wiele lat temu było to pojęcie, które działało dobrze. Dzisiejsze napędy i kontrolery praktycznie wyeliminowały użyteczność "surowca".

Po prostu "zamontuj" system plików i przechowuj pliki mysql w miejscach, o których wie każdy serwer.

Dane i indeksy w InnoDB są w blokach 16 KB, nieco uporządkowane w 1MB "zakresach". Ale podczas modyfikowania tabel dane są rozpraszane, eliminując w ten sposób korzyści, które zapewnia "surowiec".

OK, prawdą jest, że wszystkie pliki dzienników (iblog, binlog, slowlog, relaylog, generallog itp.) W pewnym stopniu korzystają z "seryjnego" dostępu do dysku. Ale jeśli system operacyjny przydziela takie pliki nieco po kolei, to uzyskuje się wydajność "surowego" nawet w "systemie plików".

InnoDB nie wie, jak adresować urządzenie surowe.

InnoDB intensywnie korzysta z pamięci RAM, aby uniknąć operacji we/wy.

Jeśli chcesz mieć HA (wysoka dostępność), polecam Galera w MariaDB lub PXC.