(am vrut sa dau vineri da' prea e material de flama si mai bine nu intind coarda).
Am o inginerie de cluster HA-linux pe care munceste cu drag si spor un mysql si pare sa munceasca cam ineficient. Stiu un numar de bottlenecks la care as putea umbla, dar nu vreau sa risc sa pierd date, asa ca nu mi-ar strica niste pareri suplimentare. Stackul de storage e cam asa: mysql 5.1 cu innodb -> ext4 -> LVM -> DRBD -> LVM -> HW RAID10. Kernelul e cel din Debian stable, 64bit. Conditia numarul zero e ca nu e tolerata pierderea de tranzactii (am innodb_flush_log_at_trx_commit=1 si syc_binlog=1 si drbd-ul foloseste protocol C). Am tot citit 'jde idei de crescut performanta, dar in general cam toate vin cu warnings ca se pot pierde date, ceea ce nu ma coafeaza de nici un fel. However, tinand cont ca drbd-ul garanteaza ca ce-i pe disc e pe ambele discuri, ma gandesc ca asta mi-ar permite sa relaxez putin paranoia, nu-mi dau seama exact insa cat (_cred_ ca pot garanta ca nu crapa ambele servere simultan, dar nu bag mana in foc), asa ca mi-ar prinde bine niste idei in plus. Ce-mi permit sa schimb de mai sus: - optiuni de montare ale ext4 - poate chiar ext4 (cand am facut research acum cateva luni nu m-au convins foarte tare diferentele intre xfs si ext4) - optiuni de drbd (posibil ca protocolul B sa fie good enough, diversi gigei pe care i-am gasit cu google se jurau ca nu vad diferenta, asa ca recomandau tot C ca e mai safe) - optiuni de innodb (multi se jura pe O_DIRECT) - kernelul (cel din stable e deja cam vechi, as lua unul din backports sau chiar hand-made dar doar pentru vreun feature anume) Ce nu pot sa schimb: - mysql cu altceva sau alta versiune (o sa trec si la 5.5 candva, nu tine doar de mine, de postgres sau altceva nu poate fi vorba) - linux cu bsd sau windows Tinand cont ca-mi ia cam o zi sa refac baza de date in caz ca se buseste ceva, parca n-as incerca foarte multe experimente. O sa incerc for now sa scot barriers de la ext4 sa vad ce se intampla cand il scot din priza, dar daca aveti alte sugestii feel free to chip in. -- Petre. _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
