Abstract
This section describes the NdbEventOperation
class, which is used to monitor changes (events) in a database. It
provides the core functionality used to implement MySQL Cluster
Replication.
Parent class. None
Child classes. None
Description.
NdbEventOperation represents a database event.
Creating an Instance of NdbEventOperation.
This class has no public constructor or destructor. Instead,
instances of NdbEventOperation are created as
the result of method calls on Ndb
and NdbDictionary objects,
subject to the following conditions:
There must exist an event which was created using
Dictionary::createEvent(). This method returns an instance of theEventclass.An
NdbEventOperationobject is instantiated usingNdb::createEventOperation(), which acts on an instance ofEvent.
An instance of this class is removed by invoking
Ndb::dropEventOperation.
A detailed example demonstrating creation and removal of event operations is provided in Section 2.4.8, “NDB API Event Handling Example”.
Known Issues. The following issues may be encountered when working with event operations in the NDB API:
The maximum number of active
NdbEventOperationobjects is currently fixed at compile time at 2 *MaxNoOfTables.-
Currently, all
INSERT,DELETE, andUPDATEevents—as well as all attribute changes—are sent to the API, even if only some attributes have been specified. However, these are hidden from the user and only relevant data is shown after callingNdb::nextEvent().Note that false exits from
Ndb::pollEvents()may occur, and thus the followingnextEvent()call returns zero, since there was no available data. In such cases, simply callpollEvents()again.See Section 2.3.14.1.16, “
Ndb::pollEvents()”, and Section 2.3.14.1.15, “Ndb::nextEvent()”. Event code does not check the table schema version. When a table is dropped, make sure that you drop any associated events.
-
If you have received a complete epoch, events from this epoch are not re-sent, even in the event of a node failure. However, if a node failure has occurred, subsequent epochs may contain duplicate events, which can be identified by duplicated primary keys.
In the MySQL Cluster replication code, duplicate primary keys on
INSERToperations are normally handled by treating such inserts asREPLACEoperations.
To view the contents of the system table containing created events, you can use the ndb_select_all utility as shown here:
ndb_select_all -d sys 'NDB$EVENTS_0'
Methods. The following table lists the public methods of this class and the purpose or use of each method:
| Method | Purpose / Use |
|---|---|
execute() |
Activates the NdbEventOperation
|
getBlobHandle() |
Gets a handle for reading blob attributes |
getEventType() |
Gets the event type |
getGCI() |
Retrieves the GCI of the most recently retrieved event |
getLatestGCI() |
Retrieves the most recent GCI (whether or not the corresponding event has been retrieved) |
getNdbError() |
Gets the most recent error |
getPreBlobHandle() |
Gets a handle for reading the previous blob attribute |
getPreValue() |
Retrieves an attribute's previous value |
getState() |
Gets the current state of the event operation |
getValue() |
Retrieves an attribute value |
isConsistent() |
Detects event loss caused by node failure |
mergeEvents() |
Makes it possible for events to be merged |
tableFragmentationChanged() |
Checks to see whether the fragmentation for a table has changed |
tableFrmChanged() |
Checks to see whether a table .FRM file has changed |
tableNameChanged() |
Checks to see whether the name of a table has changed |
tableRangeListChanged() |
Checks to see whether a table range partition list name has changed |
For detailed descriptions, signatures, and examples of use for each
of these methods, see
Section 2.3.19.2, “NdbEventOperation Methods”.
Types.
NdbEventOperation defines one enumerated type,
the State type.
Class diagram.
This diagram shows all the available members of the
NdbEventOperation class:
