[W.....o]

czego mam szukać jeśli chcę aby serwer #mysql działał w pamięci (solidny cache lub całkowicie w pamięci - obecnie mam wolne ok 60GB ramu). Ważne jest jednak dla mnie, aby w przypadku nieoczekiwanego restartu (wystąpić może raz na rok, chociaż miałem ponad 3 lata spokoju z takimi rzeczami) baza była zrzucona na dysku (kopie wykonuję raz na godzinę, ale to i tak za rzadko, chciałbym aby był jakiś mirroring czy coś takiego na dysku i w ram, normalnie pracuje z ram, ale zmiany też synchronizuje z dyskiem, może być opóźnienie, ale nie duże...

Wiem, ze jest "engine = memory", ale to nie rozwiązuje mojego problemu :)

tmpfs? To dobre rozwiązanie? + rsync? ale to może powodować problemy, przy otwartych plikach, testowałem przy backupie. Jeśli baza jest włączona, nie wykona się dobry backup.

#linux #debian

[b.....s]

@Wladyslaw_Jagiello: a nie mozesz miec jednego 'in memory', a drugiego jako slave na dysku?

[W.....o]

@blues: pewnie mogę, ale nie wiem o czym piszesz, czego jednego? :)

[b.....s]

@Wladyslaw_Jagiello: jedna instancja mysqld - engine=memory, druga instancja mysqld - normalnie, na dysku. Wystaw na innych portach, zestaw replikacje master-slave.

[W.....o]

@blues: właśnie takiej odpowiedzi oczekiwałem, resztę sobie doczytam. Dzięki :)

[RRybak]

@Wladyslaw_Jagiello:
1. żeby było w pamięci - innodb pool size na rozmiar bazy + minimum 10% . Kontaktu z dyskiem nie unikniesz, ale będziesz miał solidne wsparcie RAM. Na ramdysku bazy NIE odplaj.
2. Dobrze zrobić sobie RAID 10, który zabezpieczy Cię przed awarią dysku (i solidnie przyśpieszy)
3. Dobrze mieć z boku replikę, która będzie miała aktualne dane praktycznie na bieżąco w przypadku awarii/restartu serwera głównego
4. oprócz dumpów zainteresuj

[czechu]

@RRybak: "Na ramdysku bazy NIE odplaj." z czystej ciekawości dlaczego nie ?

[RRybak]

@czechu: gościu robi backupy co godzinę, domyśl się.
edit: podpowiedź - "crash recovery"

[czechu]

@RRybak: OK ale skoro masz 2 instancję slave na dysku z replikacją to już nie ma różnicy co ile robisz backup.
Ale ok już wiem o co ci chodziło.

[maniac777]

to już nie ma różnicy co ile robisz backup.

@czechu: Ma, backup jest potrzebny nie tylko przy błędach sprzętu, ale również przy błędach inteligencji białkowej.

[maniac777]

@Wladyslaw_Jagiello: Rozwiązanie proponowane przez RRybak jest poprawne. Pamiętaj że MySQL ma różne pule i cache i spokojnie można na tym polecieć bez trzymania całej bazy w pamięci. Jak mimo wszystko upierasz się by mieć bazę in-memory to taką funkcjonalność posiada storage Engine NDB do MySQL, ale to nie wiem czy nie strzelasz z armaty do wróbla.

[Jurigag]

@Wladyslaw_Jagiello: mysql/mariadb ma wbudowany query cache result, domyślnie nie pamiętam czy jest włączony, powinien być, takze jedyne co możesz zrobićto zwiększyć rozmiar i tyle :P https://dev.mysql.com/doc/refman/5.7/en/query-cache.html tylko jest on mocno ograniczony, tj przy jakiejkolwiek zmianie tabeli wszystkie powiązane selecty/joiny są czyszczone

nie możesz po prostu wykonywać backupu przyrostowego albo różnicowego? https://dev.mysql.com/doc/mysql-enterprise-backup/3.12/en/mysqlbackup.incremental.html

[W.....o]

@Jurigag: backup nie jest problemem, problemem jest czas wykonywania niektórych zapytań i ogólna prędkość gdy boty atakują (skanują) domenę :)
Tamtym się już bawiłem, ale może jeszcze raz rzucę na to okiem

[Jurigag]

@Wladyslaw_Jagiello: no to mysql posiada cache wbudowany, wystarczy go odpalić :P plus to co napisał @RRybak:

no i przerzuć się na mariadb 10.1

[plushy]

@Wladyslaw_Jagiello: Bazy danych to skomplikowany temat i nie myśl że jesteś mądrzejszy od twórców bazy. Kesze bazy + kesze linuksa naprawdę ci powinny wystarczyć, jak masz kłopoty z IO to zainwestuj w szybszy dysk. Do tego optymalizacja zapytań. Jeśli boty cię wykańczają to lepiej się zastanów co jest nie tak z twoim Varnishem.