First: better open an issue here:
http://github.com/masterzen/mysql-snmp/issues
if you want to get support.

While I don’t exactly know why it behaves like that for you, make sure you at least SNMP v2c or v3 to query mysql-snmp otherwise it won’t answer correctly 64bits counter and will stop scanning the table when encountering a 64 bit value.

You can configure opennms to query less oid per requests (see maxVarsPerPdu in datacollection-config.xml).

Still on the same subject, make sure to use a recent net-snmp on which you should add the following patch:
http://sourceforge.net/tracker/?func=detail&aid=2890931&group_id=12694&atid=312694

This patch (which I originally contributed but wasn’t correctly applied uptream) fixes how counter 64 are handled in perl.

Also, I plan to release 1.0 soon, make sure to try the current 1.0rc2 (from the github repository or download section).

Note: I tried your snmpgetnext command successfully on my own servers and it displays the correct results (with 1.0rc2) and net-snmp 5.4.1 (patched) under debian lenny.
Of course with -v2c it reports the correct result and doesn’t choke on the last oid.
What net-snmp version are you running?

After some effort, I came up with a workaround, though I haven’t yet found the actual problem. It appears that when OpenNMS sends a lot of requests in one packet, mysql-agent responds to all of them, and passes the response back to net-snmp, without any apparent problem. But net-snmp doesn’t like the response and produces an error and unregisters the mysql-agent (which automatically reregisters itself after a few seconds). I was able to reproduce the problem by doing:

snmpgetnext -r0 -t 5 -m “+:/usr/share/snmp/mibs/MYSQL-SERVER-MIB.txt” -v1 -c public hostname .1.3.6.1.4.1.20267.200.1.1 .1.3.6.1.4.1.20267.200.1.2 .1.3.6.1.4.1.20267.200.1.3 .1.3.6.1.4.1.20267.200.1.4 .1.3.6.1.4.1.20267.200.1.5 .1.3.6.1.4.1.20267.200.1.6 .1.3.6.1.4.1.20267.200.1.7

The above will produce an error. If I drop the last OID from the request, it works fine. I am curious if others have the same problem or not. It’s possible there is a problem in the mysql-agent code, but it may also be in the perl snmp library, or even in my OpenNMS configuration… I am running this on a RHEL 5 box, with all of the official patches as of a few weeks ago. None of the newer patches seem related, but I’ll try to patch it again soon.

The workaround was to reconfigure snmp-config.xml so that when talking to the mysql servers, it only sends 1 oid at a time. (I think you could probably go up to 5 or 6, but I just set it down to 1 to be safe.)