Wpis z mikrobloga

Miruny sprawa:
Mam sobie bazę danych w MySQLu. Może spora nie jest ~500 MB, ale gdy jednocześnie trwa do niej zapis i odczyt pewnych rekordów, a w nim jeszcze joiny i inne wynalazki to niestety, ale to się bardzo muli ( ͡° ʖ̯ ͡°) a dyski nie są SSD tylko starsze SASy ( ͡° ʖ̯ ͡°) i nie mam możliwości zmiany.
Istnieje coś, żeby można było mieć na jednym serwerze dwie replikujące się bazy?
Pomysł mam, żeby tą jedną trzymać na dysku tak jak jest, a druga, która będzie się replikować jako slave, trzymać na silniku MEMORY, żeby siedziała sobie w pamięci RAM i żeby to z tej bazy szedł zawsze odczyt ( ͡° ͜ʖ ͡°)

Da się, nie da się?
Albo może macie lepsze rozwiązanie?

#kiciochpyta #pytaniedoeksperta #bazydanych #mysql i zawołam ryzykownie #programowanie, bo może tam też siedzi jakiś krypto-mirek z baz danych ( ͡º ͜ʖ͡º)
  • 17
@super_tux: wydaje się, że na jakimś słabym sprzęcie to chodzi. Tak, może głupio, może nie głupio spytam - używasz indeksów i zapytania po nich "biegają"? Bo tak na moje, to 500MB powinno ci się zmieścić do pamięci tak czy tak, a możesz mieć dużą "rotację" danych wtedy w pamięci nie będziesz miał aktualnych danych więc i tak będą musiały być pobrane z dysku.
...ale ja się nie znam na MySQLu ¯\_(ツ)_/¯
@mr_hammerer: Indeksy zbyt wiele nie pomagają - w bazie jest olbrzymia rotacja. Dane są zbierane, analizowane, sortowane, eksportowane i wywalane z bazy. Ogólnie to kilkanaście milionów zapytań na godzinę ( ͡° ʖ̯ ͡°)
Nie chcę też całkowicie wrzucić bazy do RAMu z wiadomych względów - cokolwiek się stanie, choćby kernel panic i jestem w ciemnej dupie ( ͡° ͜ʖ ͡°)
@super_tux: wydaje mi się, że baza do odczytu ci nie pomoże - dane musisz zreplikować więc tam też będziesz miał ten sam zapis, jednak trzymałbym się jakiejś optymalizacji zapytań. Rzuć okiem których zapytań masz najwięcej (są "najcięższe") i spróbuj je zoptymalizować (indeksy zweryfikuj lub dodoaj). ....ale to tylko moje spostrzeżenia. Trzeba byłoby wpaść na tą bazę i zobaczyć co się tam dzieje, ake ja się na mysqlu nie znam ( ͡
via Wykop Mobilny (Android)
  • 1
@super_tux: analizowales czy wąskim gardłem nie jest sam zapis? Z tego co piszesz pewnie gro zapisu to coś a'la random write, co efektywnie zjada iopsy dysków. Jeśli potrzeba ich więcej niż dyski są w stanie dać to replika in-memory nie rozwiąże problemu.

Hmm nie możecie zmienić dysków na SSD. Masz tam BBU?
@b0rn2frag: UPS jest, ale tu bardziej chodzi mi też o zabezpieczenie jak ktoś zrobi reboot serwera albo wywali jakiś kernel panic albo co ( ͡° ͜ʖ ͡°) bo wtedy to już będzie po ptakach ( ͡° ͜ʖ ͡°)
a co do wydajności dysków na serwerze - gdyby miały tylko zapisywać to sobie poradzą, zatyka się gdy jednocześnie ma pełno odczytów zawartości i jednocześnie
via Wykop Mobilny (Android)
  • 0
@super_tux: tylko jak mirki wcześniej zauważyły 500MB powinno się mieścić w ram, więc raczej musisz odpowiedzieć najpierw na pytanie dlaczego baza nie jest w stanie efektywnie korzystać ze swojego cache. Nie znam na tyle wnęczności mysql niestety.

Also kontroler z BBU jest niezależny od systemu, więc ew. panic nie powinien nic popsuć.
@b0rn2frag: Podejrzewam, że efektywnie nie korzysta, bo co z tego ze będzie cache zapytania X, jak ułamek sekundy później wynik tego samego zapytania będzie zupełnie inny ( ͡° ʖ̯ ͡°)
No cóż, będę jeszcze próbować jakoś to wymodzić, ewentualnie wezmę zupełnie inną maszynę do tego celu i na niej zrobię bazę w RAMie niech się replikuje z główną i zrzucę na nią wszystkie operację odczytu i zobaczę
@januzi: Z MySQL Tunera korzystałem, ale no nie bardzo pomogło, bo ruch mi w ostatnich dniach mocno wzrósł i przestało sobie wszystko radzić ( ͡° ͜ʖ ͡°)
Odpaliłem dodatkowy serwer MySQLa, który replikował się z głównym, z tym, że ten jest trzymany w RAMie i d niego wszystkie SELECTy skierowałem ( ͡° ͜ʖ ͡°) pomogło dość mocno, teraz jedyne co, to na tym