Hi Moon's Father,
a) When you subscribe to data change events occurring on a table, the
Ndb data nodes internally track changes occurring on tables that you
specify, and send these changes to your API node.
b) There is no overhead for non-DML operations - e.g. read-only queries.
- If you subscribe to a subset of columns in a table, only those columns
are sent from the data node to the API.
For situations where the number of arriving row events / second is high,
you should attempt to ensure that your listening thread is not starved
of CPU.
- If the listening thread in the API lags too far behind the 'latest
event' occurring on the cluster, the data nodes may disconnect your API
node.
- In extreme cases, the links from the data nodes to the Api node may
become overloaded by event information, resulting in new operations
involving the Api failing until the overload situation passes.
As with most things cluster, best to prototype and measure.
Frazer
Moon's Father wrote:
> We use MySQL NDB event API to monitor DB data change. But I have two
> confusion to consult with us.
>
> a. How this mechanism works internally in mySQL?
>
> b. If an event is defined on some columns of a table and DML
> operations is not quite often (say one update/delete/insert per minute),
> when the table is populated with large amount of data (say 10 million
> records), what’s the performance impact?
>
>
> Any reply is appreciated.
>
>
--
Frazer Clement, Software Engineer, MySQL Cluster
Sun Microsystems - www.mysql.com
Office: Edinburgh, UK
Are you MySQL certified? www.mysql.com/certification
