Daca sunt multe baze de date replicate GTID iti rezolva problema de qps pentru ca executi query in paralel pe slave. Eu l-am folosit cu succes.
Folosesti slave_compressed_protocol ? 2015-01-20 13:54 GMT+02:00 Petru Ratiu <[email protected]>: > 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 > _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
