Czy nierozsądne jest uruchamianie replikacji na tym samym serwerze fizycznym?

Zastanawiam się nad utworzeniem replikacji Master-Slave dla mojej bazy danych. Serwer podrzędny będzie używany do nadmiarowości i ewentualnie serwera raportów. Jednak jednym z największych problemów, na jakie napotykam, jest to, że osiągnęliśmy maksymalny poziom mocy w naszym centrum danych. Zatem dodanie innego serwera fizycznego nie jest opcją.

Nasz istniejący serwer bazy danych jest dość słabo wykorzystywany, jeśli chodzi o procesor (średnie obciążenia nigdy tak naprawdę nie przekraczają 1 na czterordzeniowym rdzeniu). Zatem głównym pomysłem jest wrzucenie niektórych nowych dysków i podwojenie pamięci (z 8 GB do 16) i uruchomienie drugiej instancji mysql na tej samej maszynie fizycznej. Każda instancja miałaby osobne dyski dla bazy danych.

Czy coś jest nie tak z tym pomysłem?

Edycja (więcej informacji): (na szczęście) nigdy nie zdarzyło mi się nic złego, aby zdjąć serwer, ale staram się planować z wyprzedzeniem. Oczywiście mamy nocne kopie zapasowe, z których moglibyśmy odzyskać. Ale pomyślałem, że nadmiarowe dane na oddzielnych dyskach zapewnią szybsze rozwiązanie, jeśli dyski głównego serwera ulegną awarii (oczywiście nie, jeśli cała maszyna zgaśnie).

Jeśli chodzi o aspekt raportowania, wszelkie tabele, z których chcielibyśmy zgłaszać, to MyIsam. Zatem robienie kosztownych odczytów przy tych samych tablicach, na których są zapisywane, może zepsuć serwer. Moje założenie było takie, że serwer podrzędny, z którego wyślę raport, nie wpłynie na serwer główny, o ile dołożyliśmy do niego wystarczającą ilość pamięci RAM (ponieważ obciążenie procesora nie było jeszcze problemem).

Aby uzyskać nadmiarowość pod względem niezawodności systemu i bezpieczeństwa danych, uruchamianie urządzenia podrzędnego na tej samej maszynie, co urządzenie nadrzędne, nie oferuje niczego (lub jest bliskie). Jeśli wydarzy się coś wystarczająco złego, aby obalić mistrza, prawdopodobnie również obali niewolnika.

W celu czystej segregacji użytkowników z powodów związanych z prawami dostępu dobry RDBMS będzie oferował bardziej efektywne sposoby tego.

Uruchomienie dwóch baz danych na tym samym komputerze będzie wymagało więcej pamięci RAM do działania z tą samą wydajnością, ponieważ obie bazy danych będą konkurować o miejsce, aby zachować różne bufory i pamięci podręczne. Wydajność może jednak wynikać z segregacji obciążenia we / wy, jeśli pliki danych dla urządzenia podrzędnego znajdują się na innych dyskach fizycznych niż urządzenie główne. W takim przypadku możesz uruchamiać złożone raporty, które wymagały wielu odczytów dysku w stosunku do urządzenia podrzędnego, bez konkurowania o dane nadrzędne o przepustowość we / wy dysku.

Edycja: jak DTest wspomina w swoim komentarzu poniżej, jeszcze jedną możliwą korzyścią dla slave DB (nawet jeśli na tych samych dyskach co master) jest to, że złożone, długo działające zapytania w slave, które mogłyby spowodować problemy z blokowaniem na dzień - codzienne zapytania w systemie głównym są bezpieczniejsze. Chociaż nadal lepiej jest mieć Slave na różnych dyskach, ponieważ takie znaczące zapytania mogą powodować problemy z rywalizacją IO.

Nie jest dla mnie jasne, jak to rozwiązuje twój problem. Nie ma redundancji, ponieważ jest na tym samym sprzęcie fizycznym, tym samym jądrze systemu operacyjnego, tych samych plikach binarnych MySQL, może na różnych dyskach, ale na tym samym kontrolerze pamięci itp. A przyczyną raportowania bazy danych jest odciążenie zapytań z bazy danych OLTP i to wszystko na tym samym zestawie, skąd pochodzi dodatkowa moc? Czy jest coś jeszcze, co próbujesz uzyskać z tej konfiguracji?

Jednym z możliwych zastosowań może być jakoś segregacja użytkowników, ale znów pomyślałem, że można to zrobić GRANT.

Rzeczywiście uważa się to za nierozsądne, czy po prostu próbujesz skorzystać z większej liczby rdzeni? Jakie są cele nowego projektu?

(opublikowany jako odpowiedź, a nie komentarz, aby skupić się na wątku konwersacyjnym)

Może to być obosieczny miecz

Możesz uruchomić wiele instancji mysql jako slave tylko do odczytu na tym samym serwerze co master, pod warunkiem, że każda instancja MySQL znajduje się na innym dysku. Jest to pożądane tylko w przypadku starszych wersji MySQL, które nie korzystają z wielu rdzeni (procesorów). Najnowsze wersje MySQL można dostroić tak, aby faktycznie korzystały z wielu procesorów, dzięki czemu nie jest konieczne uzyskiwanie dostępu do wielu rdzeni przez uruchamianie wielu instancji MySQL.

Jednocześnie jest to również bardzo zły pomysł. Wielu moich klientów zrobiło to, aby zaoszczędzić pieniądze na zakupie serwerów bez systemu operacyjnego lub serwerów VM. Wszelkie wzrosty obciążenia serwera mogą wpływać na wszystkie działające instancje MySQL z powodu złych zapytań, wolnych zapytań, zbyt wielu połączeń, nadużywania pamięci, niewystarczającej pamięci serwera, przeładowania pamięci podręcznej i tak dalej, w dowolnej instancji MySQL. Zwiększa to również złożoność aplikacji poprzez konieczność dostępu do różnych instancji MySQL poprzez ich numer portu, a Ty także możesz być na łasce TCP / IP.

Krzyżowałbym replikację na innym serwerze, tj. Podrzędny A na B i podrzędny B na A. Uruchomiliśmy wiele instancji na naszych serwerach i nie mieliśmy żadnych problemów, ponieważ nasze serwery MySQL nie były na pełnych obrotach. Przełączanie awaryjne na działający serwer jest znacznie szybsze niż przywracanie z kopii zapasowej.