Mysql input: Slave_IO_Running can have values other than Yes and No

[jnguiot]

Relevant telegraf.conf:

[[inputs.mysql]]
   servers = [ "monitoring:XXX@tcp(127.0.0.1:3306)/"]
   gather_process_list                       = true
   gather_user_statistics                    = true
   gather_info_schema_auto_inc               = true
   gather_slave_status                       = true

System info:

Ubuntu 16.04
telegraf 1.12.5-1
influxdb 1.7.9-1
mariadb-server-10.0 10.0.38-0ubuntu0.16.04.1

Steps to reproduce:

1. Have a replicated mysql server with its plugin mysql configured and monitoring slave side.
   Since everything is right, the value of slave_slave_io_running is 0 (In mysql SHOW SLAVE STATUS\G: Slave_IO_Running: Yes
   If slave is stopped (STOP SLAVE;), the value is slave_slave_io_running is 1. (In mysql SHOW SLAVE STATUS\G: Slave_IO_Running: No)
2. Stop master myqsl (service mysql stop)
3. The value of slave_slave_io_running is now "Connecting" (In mysql SHOW SLAVE STATUS\G: Slave_IO_Running: Connecting

Since in normal operation, slave_slave_io_running is an integer, when master crashes, it value become a string and influxdb throw it
received error partial write: field type conflict: input field "slave_slave_io_running" on measurement "mysql" is type string, already exists as type integer dropped=1; discarding points

Expected behavior:

slave_slave_io_running should return an integer value (1 or more in case of connecting)

Actual behavior:

slave_slave_io_running may return a string or an integer, depending on the content.

Additional info:

[jnguiot]

In documentation, Slave_IO_Running can have three values: Yes No and Connection
However, a fourth "bonus" value exists: Preparing (cf code)

[jnguiot]

I would suggest a correction like this (NB: I did not test it since I don't know how to compile telegraf)

diff --git a/plugins/inputs/mysql/v2/convert.go b/plugins/inputs/mysql/v2/convert.go
index a3ac3e97..00985d8d 100644
--- a/plugins/inputs/mysql/v2/convert.go
+++ b/plugins/inputs/mysql/v2/convert.go
@@ -55,6 +55,14 @@ func ParseValue(value sql.RawBytes) (interface{}, error) {
                return 0, nil
        }
 
+       if bytes.EqualFold(value, []byte("Connecting")) {
+               return 2, nil
+       }
+
+       if bytes.EqualFold(value, []byte("Preparing"))  {
+               return 3, nil
+       }
+
        if val, err := strconv.ParseInt(string(value), 10, 64); err == nil {
                return val, nil
        }

[danielmotaleite]

well, the logic would be 0 no IO thread, 1 preparing, 2 connecting, 3 a connected io thread, so we can do < and > tests. but this may break existent setups
Another alternative is to consider preparing and connecting as failed, as they are not yet connected so if they stay that way for a long time, it is the same as not connected

[jnguiot]

I would say that standard would be a 0 for a working replication (as 0 is the standard OK return code). Plus, it is coherent with current telegraf usage. But I don't have preferences for the others ones. However, I would also consider Connecting and Preparing as not working replication, and thus, marking them as errors (>0)

[danielmotaleite]

@reimda @fxedel
are you sure that #9403 fixed this? i don't know Go enough, but i see no check for "Connecting" or "Preparing" in that PR

[fxedel]

Hey @danielmotaleite, #9403 does not fix this issue, feel free to reopen. I think that's a mistake by GitHub's autoclosing, since I commented "This could be easily extended to fix #6671 as well." The variable conversion mapping currently only exists for status and variables, but could be extended to slave status.

[danielmotaleite]

i'm not the but owner, i can't reopen, @jnguiot or maybe @danielnelson can you please reopen this bug as this is still not fixed

[jnguiot]

I cannot reopen it.

[srebhan]

Reopened on user-request.