Ok ...
I've put the agent up for public upload. I haven't seen anything weird
so far, but results may vary. Mind, its still beta quality as far as I'm
concerned.
To get this to work, as well as solve the problem detailed below
(reconnecting to a ndb cluster), you need net-snmp 5.1.4 or later.
Reconnecting to a MySQL database, as before, works.
As yet I have got it to work with net-snmp 5.1.3.1 and 5.1.4. The 5.2
and 5.3 series of net-snmp do compile, yet do not work (no snmp
whatsoever, agent running or not). Probably my 5.1 configuration is not
accepted by 5.2 or 5.3. I will look into that later on.
I'll file bugs for those mentioned in my previous mail; Another bug (?)
I found;
I can't seem to get a field type of 'ENUM' or 'SET' from the
mysql_fetch_fields retrieved from a SELECT * from database.table limit
1; It seems to return these as STRING types.
I'll file that one as well.
Feel free to retrieve it from http://www.reverze.net/mysql_snmp.tar.gz.
I'll put it there until I've found a more permanent location.
Stewart; please ignore the mail I sent to you over the weekend; I've
updated the sources significantly since then.
Cheers,
Michel
Stewart Smith wrote:
> On Fri, 2006-06-30 at 15:53 +0200, Michel Stam wrote:
>
>> Weekly status update;
>> Still having some problems when the cluster management node goes down.
>> For some reason the agent doesn't properly respond anymore after this.
>> From a few traces it seems that the agent fails to auto-reregister with
>> the snmpd daemon periodically (which it is supposed to do) and the snmpd
>> daemon gives up on it. At the very least, SNMP requests don't seem to be
>> forwarded. I need a little more time on that, perhaps I'll try with a
>> more recent net-snmp (I'm using 5.1.3.1).
>>
>
>
>
>> Other than that I've added SNMP traps, which are now sent whenever the
>> agent loses or regains connection with either the cluster or the mysqld
>> daemon itself. Also a simple trap is sent upon startup or shutdown.
>> Agent daemonizes too (or not, at the option of the admin).
>>
>
> great, this looks like a useful feature for people. with the
> auto-reregister working this would mean that people can know when their
> monitor can no longer talk to the cluster (or has crashed, caught on
> fire etc).
>
>
>> Code seems mostly clean (I am adding a couple of headers on functions so
>> they can be more easily reused), and a rudimentary Makefile is in place
>> (I haven't looked into autoconf/automake which would be fairly useless
>> if it will end up in the MySQL tree at some point in the future). No
>> testing as yet on any other version than 4.1.18.
>>
>
> great!
>
>
>> Workarounds necessary:
>>
>> * Missing include files for mysql/ndb/mgmapi. It seems that at least
>> ndb_global.h and ndb_net.h are not installed in mysql/ndb when
>> executing 'make install'. See ndb/include/Makefile.am in the
>> source tree for 4.1. Unfortunately, mysql/ndb/ndb_types.h, which
>> is included by mysql/ndb/mgmapi/mgmapi.h #includes ndb_global.h,
>> which will cause compiles to fail. Any reason why
>> ndb/include/Makefile.am lists ndb_global.h and ndb_net.h under
>> noinst_HEADERS? A workaround is copying both from the sourcetree
>> (ndb/include) into INSTALLPATH/mysql/ndb
>> * mysql/ndb/mgmapi/mgmapi.h defines 2 const values, namely const
>> struct Ndb_Mgm_Error_Msg ndb_mgm_error_msgs[] and const int
>> ndb_mgm_noOfErrorMsgs. If mgmapi.h is included in 2 or more
>> sourcefiles in a project, it will cause the link stage to fail
>> with a multiple definition error unless -zmuldefs is specified at
>> linkstage
>> * In mysql/ndb/mgmapi/mgmapi.h ndb_mgm_event_category and
>> ndb_mgm_clusterlog_level are two enums. However; strict C checking
>> does not allow for these types to be used without the 'enum'
>> keyword prepended. A workaround is typedef-ing both to 'int' prior
>> to including the mgmapi.h
>>
>
> file bugs for these and we'll investigate.
>
>
>> I can provide a beta (it is properly running on my system, though I'm
>> still testing it). Let me know where I should send it to.
>>
>
> great! just putting it up on the net somewhere is fine, i can pull it
> from there.
>
> if you'd prefer it privately, we can organise something for that (or
> rather, I get to find out where the uploads to ftp.mysql.com or
> somewhere go).
>
>
