2015-01-20 12:18 GMT+02:00 Florin Popovici <[email protected]>:
> 2015-01-19 17:15 GMT+02:00 Petru Ratiu <[email protected]>: > > > Hello, > > > In primul rand mersi de reply, incepusem sa ma ingrijorez ca nu s-a trimis mailul :P > > M-a muscat si pe mine mai demult problema asta; am ales abordarea de > "ciocan mai mare", sa monitorizez pe slave "seconds behind master" -- este > chiar plugin gata facut de Nagios, check_mysql_slave parca ii zice. > > Nope, aia rezolva alta problema. Si, btw, "seconds behind master" e o informatie care te minte, ce vrei de fapt e sa vezi cat de vechi sunt datele efectiv (eu rezolv asta cu pt-heartbeat, da' tot ce face e sa faca update-uri continuu cu un timestamp undeva si tot ce faci pe slaves e sa verifici cat de vechi e timestampul din datele curente). > "cati KB/min se genereaza acum" mi se pare informatie "non-actionable". > Poate in minutul asta viteza de generare e ceva mai mare decat > $available_bandwidth_between_datacenter, dar poti fi sigur ca in minutul > urmator situatia va continua? > > BTW, la "mysql WAN replication" se pare ca KB/s si bandwidthu nu-s foarte > importante (mai ales daca ai statement-based replication), ci qps combinat > cu "latency is a bitch": > qps e relativ relevant, (si aici chiar am mai putine solutii de numarat write statements server-side, daca ai facut-o chiar sunt curios cum, eu o fac momentan pe client) dar in cazul meu, cineva seta niste variabile huge care ajungeau in binlog si ca atare tranzactiile deveneau de zeci de K si ca atare stateam dupa io_thread, nu dupa sql_thread (situatie pe care n-am mai intalnit-o pana acu). Iar informatiile nu sunt neaparat non-actionable, asta e o chestie care se aplica la alerte. Vreau sa am informatia acolo just in case. Cum zice legea unui mare ganditor din domeniu: "If it moves, graph it; if it doesn't move graph it anyway, just in case it moves" (aka. Laurie's law). > http://blog.9minutesnooze.com/performance-mysql-replication-high-latency/ > Nu stiu sa existe o solutie simpla ca sa maresti throughputul de qps, in > afara de solutii de clustering gen Percona create anume pentru scenariul > Multi-DC. > > Problema in cazul meu era ca aveam qps mult prea mare ;) Incerc sa-mi dau seama cum masor ce inseamna "prea mare" in situatia mea. -- P. _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
