Jak szybka jest replikacja MySQL?

Zastanawiam się nad skonfigurowaniem replikacji naszej bazy danych mysql, aby móc mieć lokalne urządzenia podrzędne w każdym z naszych oddziałów, a jednocześnie mieć wzorzec w głównym biurze, aby poprawić (znacznie) wydajność aplikacji w naszych oddziałach.

Sam db nie jest tak duży (<1 gb), ale zastanawiam się; biorąc pod uwagę 200-300 aktualizacji rekordów / min szczytów: jak szybka jest replikacja? (zakładając, po pierwsze, ogólne połączenie DSL 5 MB, w razie potrzeby szybsze - starając się utrzymać koszty na możliwie najniższym poziomie, ale pieniądze są na więcej)

Czy całe tabele są replikowane partiami? Czy replikacja jest wykonywana na żądanie, gdy każdy rekord w tabeli jest aktualizowany (z dokumentów, myślę, że widzę, że można go konfigurować)?

Uwagi:

• Myślę, że 1 master, 2 slave (na razie 2 oddziały), tak jak w dokumentach tutaj, z tym wyjątkiem, że to aplikacja, a nie klient WWW
• Każda aktualizacja dokonana na urządzeniu głównym musi zostać zreplikowana na inne urządzenia podrzędne w ciągu <10 minut.
• Wszystko to zakłada, że ​​mogę sprawić, by nasz ORM (DevExpress XPO) był zadowolony z koncepcji czytania od niewolnika i pisania do mistrza.

Replikacja MySQL odbywa się tak blisko czasu rzeczywistego, jak to możliwe, ograniczonego przez dyskowe i sieciowe operacje we / wy. Niewolnicy otwierają gniazdo dla mistrza, które jest otwarte. Kiedy transakcja występuje na urządzeniu głównym, zostaje zapisana w binlog i jest po prostu odtwarzana na urządzeniach podrzędnych. Jeśli gniazdo między urządzeniem nadrzędnym a urządzeniem podrzędnym zostanie przerwane, binlog zostanie odtworzony dla urządzenia podrzędnego przy następnym udanym połączeniu.

Replikacja z wieloma wzorcami robi to samo, ale w obu kierunkach.

Niektóre podstawowe obliczenia pomogą w lepszym określeniu potrzeb w zakresie przepustowości.

Average transaction size * number of slaves * updates/minute = bandwidth needed

Mam nadzieję że to pomoże.

Replikacją po stronie niewolników zajmują się dwa niezależne wątki.

• Proces czytnika dziennika, który łączy się z urządzeniem głównym, otrzymuje każdą instrukcję modyfikacji danych i zapisuje ją w dzienniku przekazywania.
• Proces zapisu SQL, który pobiera nowe elementy z dziennika przekazywania, zatwierdza instrukcje w bazie danych slave, a następnie przesuwa wskaźnik slave poza tę instrukcję, aby wskazać odbiór zapytania.

Opóźnienie replikacji jest ograniczone przez IO, po pierwsze IO w bazie danych slave, aby zastosować transakcje z dziennika przekazywania (co może obejmować złożone zapytania SQL), a po drugie przez IO w master, aby odczytać jego binlog i przesłać go do każdego slave.

Replikacja MySQL zwiększa pojemność zapytań odczytu, ale nie zwiększa wydajności zapisu zapytań, która jest ustalana z prędkością, w której operacje we / wy mogą być opróżniane do binlogu zarówno na urządzeniu głównym, jak i podrzędnym

Replikacja w MySQL jest dość szybka, aby uzyskać dane do urządzenia podrzędnego (szybciej niż będziesz w stanie uruchomić UPDATEna urządzeniu nadrzędnym i przejść do innego okna, aby uruchomić SELECTna urządzeniu podrzędnym, jeśli(i tylko wtedy) połączenia sieciowe są uruchomione i wszystko działa poprawnie. Każde połączenie klasy DSL powinno być odpowiednie dla ogólnego przypadku twoich zwykłych małych zapytań, ale duże zapytania wstawiania / aktualizacji mogą zająć trochę czasu, aby skopiować i ponownie zsynchronizować w przypadku luki w replikacji (a MySQL jest wyjątkowo podatny na te niestety zajmą trochę czasu (ponowne skopiowanie całej bazy danych z mastera). Istnieją sztuczki ograniczania wpływu resynchronizacji na twój master, takie jak umieszczenie MySQL na LVM, abyś mógł wykonać bardzo szybką blokadę / migawkę i zsynchronizować zawartość migawki z slave'em, ale ostatecznie resynchronizacja będzie do niczego.