2015-01-19 17:15 GMT+02:00 Petru Ratiu <[email protected]>: > Hello, > > In urma unui incident minor recent am realizat ca ar fi o idee buna sa fiu > mai aware de rata de generare a binary logs pe serverele mysql (la > granularitate gen "cati KB/min se genereaza acum", nu "cati GB de binloguri > am pe ultimele $expire_log_days zile"). > > In afara de metoda golaneasca de luat pozitia de master si transformata cu > L*S+P (unde L e numarul binlogului, S e size-ul la care se roteste si P e > pozitia), e vreo metoda mai eleganta de a obtine un counter monoton care sa > reflecte cati bytes s-au scris in binloguri so far? Fac eu derivate si > integrale pe el dupa aia (cam ca la statisticile de eth-uri de exemplu). > > Bonus points daca e ceva plugin de collectd (sau snmp, sau ganglia, sau > whatever) gata facut pentru asta. > > > PS: Alte solutii care mi-au venit in minte in timp ce scriam mailul: > > - show binary logs + stat pe fiecare + calculata suma (dar trebuie stabilit > cum se alege o origine) > - returnata doar pozitia din binlogul curent si ma bazez ca scula de > monitorizare face poll suficient de des incat sa fie neglijabile datele > pierdute inainte de rotitul logului (asta ar fi cea mai cheap solutie, dar > trebuie sa fac un calcul cu marja de eroare). > > PS2: Pentru cine e curios despre incidentul minor pomenit, acum ma uit cu > jale la faptul ca pe o legatura cross-datacenter se downloadeaza binloguri > de aproximativ 7 ori mai lent decat au fost generate (si a fost sustinuta > cam 1h viteza aia de scriere in binlog). > > 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.
"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": 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. -- flo.ro _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
