https://bugzilla.wikimedia.org/show_bug.cgi?id=48694

Tim Landscheidt <t...@tim-landscheidt.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |sprin...@wikimedia.org
         Resolution|FIXED                       |---

--- Comment #4 from Tim Landscheidt <t...@tim-landscheidt.de> ---
(In reply to comment #3)
> Looks like it's working fine to me.

No, as discussed on IRC, it's still running under my personal account.

As it would be useful to show replication lag for every MariaDB slave, I wanted
to discuss this as a wider change with Asher.  But:

a) chance never came about, and
b) it's already there!  For db1035, go to
http://ganglia.wikimedia.org/latest/?c=MySQL%20eqiad&h=db1035.eqiad.wmnet&m=cpu_report&r=hour&s=descending&hc=4&mc=2
and search for "mysql_slave_lag".

However, this isn't available for labsdb* yet (cf.
http://ganglia.wikimedia.org/latest/?c=MySQL%20eqiad&h=labsdb1001.eqiad.wmnet&m=cpu_report&r=hour&s=descending&hc=4&mc=2),
and at the moment can't be enabled anyway as the monitoring for db1035 et al.
assumes that only /one/ MariaDB instance runs on any server, while on labsdb*
there are several and so mysql_slave_log & Co. need to be prefixed by, for
example, "s1_".

So to resolve this bug, we need to:

a) refactor the monitoring bits and pieces that they handle multiple instances
on one server,
b) enable such monitoring for labsdb*, and
c) create a ganglia::view where *_mysql_slave_lag for labsdb* is combined in
one report so that the information isn't scattered over three pages and
literally hundreds of graphs.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

Reply via email to