Wow, masz strasznie mocny sprzęt do rozwiązania tego problemu. Nie ma o wiele więcej do zaoferowania pod względem sprzętowym, z wyjątkiem aktualizacji do być może procesorów Sandy / Ivy Bridge w celu uzyskania o 20-50% lepszej wydajności z wyszukiwań Btree itp.
Pamiętaj, że moją mocną stroną jest Innodb, więc idę
- Zignoruj to, co robisz, i zachowuj się, jakby to nie miało znaczenia.
- Załóżmy, że ten problem jest wystarczającym impulsem, aby zmusić Cię do aktualizacji. Tak, to aktualizacja.
Innodb może pomóc w pełni wykorzystać całą tę pamięć, przechowując te często używane wiersze w puli buforów. Możesz dostroić go tak, aby był tak duży, jak chcesz (powiedzmy 80% pamięci), a świeże odczyty / zapisy pozostaną w pamięci, dopóki nie będzie trzeba zepchnąć ich na dysk, aby zrobić więcej miejsca na najnowsze dane. W pamięci jest o rząd wielkości szybszy niż twoje FusionIO.
Istnieje wiele innych funkcji Innodb, takich jak hasze adaptacyjne, mechanizmy automatycznego blokowania itp., Które mogą być dobrodziejstwem dla twojego środowiska. Ty jednak znasz swoje dane lepiej niż ja.
W świecie innodb dobrym rozwiązaniem krótkoterminowym jest optymalizacja twojego slave'a - czy naprawdę potrzebujesz każdego indeksu swojego slave'a, który masz na swoim masterie? Indeksy są kulą i łańcuchem przy wstawianiu / aktualizowaniu / usuwaniu, NAWET z kartami Fusion IO. IOPS to nie wszystko. Procesory mostkowe Sandy / Ivy mają znacznie lepszą przepustowość pamięci i wydajność obliczeniową - mogą znacznie zmienić Westmeres, które masz teraz. (Wykres 20-50% ogółem). Usuń wszystkie indeksy, których nie potrzebujesz na slave!
Po drugie, i prawie na pewno dotyczy tylko innodb, jest to, że mk-prefetch może wiedzieć, które aktualizacje i zanim slave je zapisze. Pozwala to mk-prefetch na uruchomienie najpierw zapytania do odczytu, tym samym zmuszając dane do zapisania w pamięci do czasu, gdy pojedyncza replika uruchomi zapytanie do zapisu. Oznacza to, że dane są w pamięci, a nie w fusionIO, co oznacza szybki wzrost wydajności o rząd wielkości. To ogromna różnica, więcej niż można się spodziewać. Wiele firm używa tego jako stałego rozwiązania. Dowiedz się więcej, sprawdzając Percona Toolkit .
Po trzecie, a co najważniejsze, po przejściu na Innodb, zdecydowanie sprawdź Tokutek. Ci faceci mają niesamowicie niesamowite rzeczy, które przewyższają wydajność Innodb w zakresie zapisu / aktualizacji / usuwania. Mówią o poprawie szybkości replikacji jako jednej z kluczowych korzyści, a na podstawie ich benchmarków można zobaczyć, dlaczego szalone IOPS Fusions nadal nie pomogą ci w przypadku Btrees . (Uwaga: nie są przeze mnie niezależnie weryfikowane). Używają drop-in zamiennego indeksu btree, który, choć o wiele bardziej złożony, poprawia wiele algorytmicznych ograniczeń prędkości indeksów btree.
Właśnie zastanawiam się nad przyjęciem Tokutka. Jeśli zwolnią tyle prędkości zapisu, to mogę dodać więcej indeksów. Ponieważ kompresują dane i indeksy w tak wspaniałych proporcjach (podają 25x), nie płacisz nawet (wydajności, konserwacji) ceny za zwiększone dane. Płacisz jednak ($) za ich silnik, 2500 $ rocznie za wstępnie skompresowane GB, IIRC. Mają zniżki, jeśli masz replikowane dane, ale możesz nawet zainstalować Tokutek na swoim niewolniku i utrzymać swojego mistrza w niezmienionej postaci. Sprawdź szczegóły techniczne w wykładzie MIT Algoritms Open Courseware . Alternatywnie, mają mnóstwo technicznych artykułów na swoim blogu i regularne oficjalne dokumenty dla tych, którzy nie mają 1:20, aby obejrzeć wideo. Wierzę, że ten film podaje również formułę Big-O określającą szybkość odczytywania. Ja mamzakładać, że odczyty są wolniejsze (zawsze istnieje kompromis!), ale formuła jest zbyt skomplikowana, abym mógł ocenić, ile. Twierdzą, że jest mniej więcej taki sam, ale wolałbym zrozumieć matematykę (mało prawdopodobne!). Być może znajdziesz się w lepszej sytuacji, aby to odkryć niż ja.
Ps Nie jestem związany z Tokutkiem, nigdy nie prowadziłem ich produktu i nawet nie wiedzą, że na nie patrzę.
Aktualizacja :
Widzę, że masz kilka innych pytań na tej stronie i pomyślałem, że włączyłem:
Po pierwsze, pobieranie wstępne slave prawie na pewno nie będzie działać dla myisam, chyba że masz wyjątkowe środowisko. Wynika to głównie z tego, że pobieranie wstępne blokuje te tabele, do których zamierzasz pisać, lub w wątku podrzędnym blokuje się tabelę, której potrzebuje demon pobierania wstępnego. Jeśli Twoje tabele są wyjątkowo dobrze zrównoważone pod kątem replikacji, a różne tabele są zapisywane w trybie rundy, może to działać - ale pamiętaj, że jest to bardzo teoretyczne. Książka „High Performance Mysql” zawiera więcej informacji w sekcji „Problemy z replikacją”.
Po drugie, prawdopodobnie twój niewolnik ma obciążenie 1,0-1,5, może być wyższy, jeśli masz uruchomione inne procy lub zapytania, ale poziom podstawowy wynosi 1,0. Oznacza to, że prawdopodobnie jesteś związany z procesorem, co jest prawdopodobne w przypadku FusionIO na pokładzie. Jak wspomniałem wcześniej, Sandy / Ivy Bridge da nieco więcej mocy, ale prawdopodobnie nie wystarczy, aby przejść przez trudniejsze czasy przy minimalnym opóźnieniu. Jeśli obciążenie tego urządzenia podrzędnego jest w większości tylko do zapisu (tj. Niewiele odczytów), twój procesor prawie na pewno spędza czas na obliczaniu pozycji dla wstawiania / usuwania btree. To powinno wzmocnić mój punkt powyżej dotyczący usuwania niekrytycznych indeksów - zawsze możesz je ponownie dodać później. Wyłączenie hyperthreadingu nie będzie działać, więcej procesora nie jest twoim wrogiem. Gdy przekroczysz 32 GB pamięci RAM, powiedzmy 64 GB, musisz się martwić dystrybucją pamięci RAM, ale nawet wtedy objawy są różne.
Na koniec, i co najważniejsze (nie pomijaj tej części;)), zakładam, że korzystasz teraz z RBR (replikacja oparta na wierszach), ponieważ wspomniałeś o trywialnym wzroście wydajności podczas przełączania go również. Jednak może istnieć sposób na uzyskanie jeszcze większej wydajności. Błąd MySQL 53375 może się pojawić, jeśli tabele są replikowane bez klucza podstawowego. Urządzenie podrzędne nie jest w zasadzie wystarczająco inteligentne, aby używać niczego poza kluczem podstawowym, więc brak jednego zmusza wątek replikacji do wykonania pełnego skanowania tabeli dla każdej aktualizacji. Naprawą jest po prostu dodanie łagodnego, zastępczego automatycznego klucza inkrementującego. Zrobiłbym to tylko, gdyby stół był duży (powiedzmy kilka dziesiątek tysięcy lub więcej wierszy). Oczywiście wiąże się to z kosztem posiadania innego indeksu na stole, co podnosi cenę płaconą za procesor. Zauważ, że jest bardzo mało teoretycznych argumentów przeciwko temu, ponieważ InnoDB dodaje jeden za kulisami, jeśli nie. Fantom nie jest jednak użyteczną obroną przeciwko 53375. Wolfram również może rozwiązać ten problem, ale musisz mieć pewność, że używając Wolfram masz proste kodowanie. Ostatnim razem, gdy grałem z nim, zginąłby okropnie, gdy każdy ciąg inny niż UTF8 wymagał replikacji. To czas, kiedy się poddałem.
