[mysql] Work _get_slave_status in case of performance_schema is dis…

[hirose31]

What does this PR do?

This PR makes replication: true works correctly in case of MySQL >= 5.5 with performance_schema is disabled and MySQL 5.1.

Detail

_collect_metrics calls _get_slave_status without the nonblocking parameter.

            results.update(self._get_slave_status(db))

_get_slave_status (nonblocking is True implicitly) queries SELECT THREAD_ID, NAME FROM performance_schema.threads WHERE NAME LIKE '%worker'.

    def _get_slave_status(self, db, nonblocking=True):
...
                if nonblocking:
                    cursor.execute("SELECT THREAD_ID, NAME FROM performance_schema.threads WHERE NAME LIKE '%worker'")
                else:
                    cursor.execute("SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST WHERE COMMAND LIKE '%Binlog dump%'")
...

that causes:

• MySQL >= 5.5 w/ performance_schema = off
  • metrics mysql.replication.slaves_connected is always 0, becuse there is no record in performance_schema.threads
• MySQL <= 5.1 (does not support performance_schema)
  • raise exception because performance_schema.threads does not exist

2016-12-06 18:33:35 JST | ERROR | dd.collector | checks.mysql(mysql.py:313) | error!
Traceback (most recent call last):
  File "/opt/datadog-agent/agent/checks.d/mysql.py", line 306, in check
    self._collect_metrics(host, db, tags, options, queries)
  File "/opt/datadog-agent/agent/checks.d/mysql.py", line 532, in _collect_metrics
    results.update(self._get_slave_status(db), False)
  File "/opt/datadog-agent/agent/checks.d/mysql.py", line 872, in _get_slave_status
    cursor.execute("SELECT THREAD_ID, NAME FROM performance_schema.threads WHERE NAME LIKE '%worker'")
  File "/opt/datadog-agent/embedded/lib/python2.7/site-packages/pymysql/cursors.py", line 134, in execute
    result = self._query(query)
...
ProgrammingError: (1146, u"Table 'performance_schema.threads' doesn't exist")

Additional Notes

passing performance_schema_enabled to _get_slave_status is dropped on @e614fa0593f449213c5c07982e6b59b785287f2d . I don't know why.

[degemer]

Thank you for your detailed description @hirose31 !
You're right, this was changed in #2603 (whereas the description states the exact opposite).
I missed it during the review, I'm going to ask @truthbk to have a look, if he remembers why he changed this behaviour.