fix: inconsistent metric types in mysql

[fxedel]

Fixed two issues with inconsistent metric types in mysql:

• mysql variables that are stored as uint64 in mysql and are too big for int64 (currently parsed as float by telegraf)
• mysql variables with "ON", "OFF" and other string values (currently parsed as integer for "ON"/"OFF" and string otherwise)

The fix included uint parsing (if int fails) and a mapping for some MySQL statuses/variables, pinning them to a specific type.

Note that InfluxDB 1.x doesn't support uint, so outputted values will be capped to max int, but that's a problem with the InfluxDB plugin and not MySQL. (Possible fix: add influxdb option to output uints as floats).

Fixes #8319, #5711, #5055, #7421

See #5529, #6624

This could be easily extended to fix #6671 as well.

[telegraf-tiger]

Thanks so much for the pull request!
🤝 ✒️ Just a reminder that the CLA has not yet been signed, and we'll need it before merging. Please sign the CLA when you get a chance, then post a comment here saying !signed-cla

[fxedel]

!signed-cla

[telegraf-tiger]

Looks like new artifacts were built from this PR. Get them here!

Artifact URLs

• darwin_amd64.tar.gz

• windows_amd64.zip

• windows_i386.zip

• x86_64.rpm

• freebsd_amd64.tar.gz

• linux_amd64.tar.gz

• amd64.deb

• armv6hl.rpm

• freebsd_armv7.tar.gz

• linux_armhf.tar.gz

• armhf.deb

• s390x.rpm

• linux_s390x.tar.gz

• s390x.deb

• armel.rpm

• linux_armel.tar.gz

• armel.deb

• aarch64.rpm

• linux_arm64.tar.gz

• arm64.deb

• static_linux_amd64.tar.gz

• i386.rpm

• freebsd_i386.tar.gz

• linux_i386.tar.gz

• i386.deb

• ppc64le.rpm

• linux_ppc64le.tar.gz

• ppc64el.deb

• linux_mipsel.tar.gz

• mipsel.deb

• linux_mips.tar.gz

• mips.deb

[srebhan]

Looks good codewise, but I have no way of testing this...

[MyaLongmire]

@eraac @bluebob @bolek2000 This pull request might resolve the issues you opened, if you are still having the issues would you mind testing this fix? #9403 (comment)

[reimda]

Hi @fxedel I took a quick look at the changes here. I'm a little concerned about backward compatibility. If someone was using "transaction_write_set_extraction" or any of the other ~20 variables which change type because of this PR, they may run into issues. Do you think these fixes would require a new metric_version=3?

[fxedel]

Hi @reimda, the issues that could be introduced by this PR are actually the same issues that we're facing today. For example transaction_write_set_extraction is currently stored either as int (when OFF) or string (when MURMUR32) – see #7421. With this PR, it's always stored as string. If the variable has always been set to OFF, it will produce new issues, but, as least for InfluxDB, only until the next shard is created. If the variable has always been changing, the issues were always present and will disappear in future. If the variable has always been set to MURMUR32, there will be no issues.

As this is merely a bug fix, I wouldn't introduce a new metric version, as all users of v2 would benefit in the long-term. A typical shard duration is one week, so InfluxDB users would see no issues after at most seven days.

Of course, a new metric version v3 would also be acceptable.

[reimda]

Thanks for the explanation, I see what you mean that issues that could be introduced by this PR are actually already happening. I think this change will fix a lot of the existing mysql conversion problems.

I have a couple more questions after looking a little more closely at the code.