PlanetMysql.ru — информация о СУБД MySQL

There will be a live webinar on Wednesday January 12 describing the new ways that you can manage MySQL Cluster (with a bit of monitoring thrown in). As always, the webinar is free but you need to register here. The event is scheduled for 09:00 Pacific / 17:00 UK / 18:00 Central European time but if you can’t make the live webinar it’s still worth registering so that you’re emailed the replay after the event.

By their very nature, clustered environments involve more effort and resource to administer than standalone systems, and the same is true of MySQL Cluster, the database designed for web-scale throughput with carrier-grade availability.

In this webinar, we will present an overview of the three latest enhancements to provisioning, monitoring and managing MySQL Cluster – collectively serving to lower costs, enhance agility and reduce the risk of downtime caused by manual configuration errors.

In this webinar, we will present:

• NDBINFO: released with MySQL Cluster 7.1, NDBINFO presents real-time status and usage statistics, providing developers and DBAs with a simple means of pro-actively monitoring and optimizing database performance and availability.
• MySQL Cluster Manager: available as part of the commercial MySQL Cluster Carrier Grade Edition simplifies the creation and management of MySQL Cluster by automating common management tasks, delivering higher administration productivity and enhancing cluster agility. Tasks that used to take 46 commands can be reduced to just one!
• MySQL Cluster Advisors & Graphs: part of the MySQL Enterprise Monitor and available in the commercial MySQL Cluster Carrier Grade Edition, the Enterprise Advisor includes automated best practice rules that alert on key performance and availability metrics from MySQL Cluster data nodes.

You will also learn how you can get started evaluating and using all of these tools to simplify MySQL Cluster management.

This session will be approximately 1 hour in length and will include interactive Q&A throughout. Please join us for this informative webinar!

WHO:

• Andrew Morgan, MySQL Cluster Product Management, Oracle
• Mat Keep, MySQL Cluster Product Management, Oracle

PlanetMySQL Voting: Vote UP / Vote DOWN

A few months ago, I posted a walkthrough of how to extend MySQL Enterprise Monitor in order to monitor MySQL Cluster. The great news is that as of MySQL Enterprise Monitor 2.3 (available from Oracle E-Delivery since 1st November) this functionality is included in the core product and so there is no need to add the extra features in manually. Of course, that post might still be of interest if you want to further extend MySQL Enterprise Monitor.

This post briefly steps through the new (Cluster-specific) functionality but if you’re interested, why not try it for yourself and download the new MySQL Enterprise Monitor software from Oracle E-Delivery. If you like what you see then the good news is that if you take out a subscription for MySQL Cluster CGE (or buy a license) then this now also entitles you to use MySQL Enterprise Monitor.

There are two main aspects that have been extended to cover MySQL Cluster:

• A new MySQL Cluster Advisor has been added. This Advisor is made up of a set of rules that check various aspects of the data nodes and raise alerts if a configurable threshold is exceeded
• A set of new graphs have been added so that you can monitor the usage of key resources over time.

Note that MySQL Enterprise Monitor has no direct connection to the data nodes and so one or more of the MySQL Servers from the Cluster is effectively used as a proxy. There is nothing special for you to configure on the servers, behind the scenes, Enterprise Monitor is reading the contents of the ndbinfo database that was introduced in MySQL Cluster 7.1.

If using an older version of MySQL Cluster then you get less benefit from MySQL Enterprise Monitor but there is still some value in using it to monitor the MySQL Servers that are part of the cluster:

• Use the Query Analyzer to keep track of how your applications access the database and troubleshoot performance issues
• Monitor the state of the MySQL Server itself (number of client connections, CPU usage etc.)
• Generate alerts when data nodes are out of service.

There is documentation covering installing and running the MySQL Enterprise Monitor service manager and agents and so I won’t repeat the steps here except to point out that you need one or more of the agents to be configured to monitor one or more of the MySQL Servers in your Cluster. Of course, you could monitor multiple MySQL Cluster deployments from the same dashboard – just make sure that you have an agent monitoring at least one MySQL Server from each one.

By default, none of the rules from the MySQL Cluster Advisor are scheduled against any of your servers and so the first thing you need to do is go to the “Advisors” tab and from their select “Add to Schedule”. Select the server(s) on the left and then check the radio button(s) against the whole Cluster advisor or against one or more of the rules within it and click the “schedule” button. You’ll then be given the option to override the default frequency that each rule is run before confirming the activation (scheduling) of the rule(s) for your server(s). This is also the point where you can indicate whether or not an SNMP Trap should be raised when the alert is raised/cleared (the destinations for the SNMP notifications can be set under the “Settings” tab).

Note that if you try scheduling the Cluster Advisor rules against a MySQL Server that is not part of a MySQL Cluster 7.1 (or later) deployment they you will get errors indicating that the server cannot provide the required data.

 

 

 

 

 

 

 

The new MySQL Cluster graphs are activated by default and you can view them from the “Graphs” tab but note that if there are no MySQL Cluster 7.1 servers in the list that you highlight on the left of the browser then the Cluster graphs will be hidden.

 

 

 

 

 

Note that there is still scope for simple customizations directly from the the MySQL Enterprise Monitor GUI. For example if you don’t think that the default thresholds are appropriate for your configuration then select “Manage Rules” within the “Advisors” tab and then click “edit” next to the rule in question – you then get the option to alter the threshold values.

As a final configuration step, go back to the “Monitor” tab and click on “edit favorites” to promote your favourite Cluster graphs to the home screen.

 

Any Critical alerts (including ones for the newly scheduled Cluster rules) will appear on the Monitor page – to see the Info and Warning alerts, select the “Events” tab. Clicking on any of these alerts will give you extra details and the opportunity to close the alert.

PlanetMySQL Voting: Vote UP / Vote DOWN

From MySQL Cluster 7.1.9 it is possible to get better stats on disk data tables. In fact, the statistics makes it possible to tune the DiskPageBufferMemory parameter (similar to innodb_bufferpool), in order to avoid disk seeks. It is much (understatement) faster to fetch data from the DiskPageBufferMemory than disk.

Here is an example/tutorial how to use this information and how to check the hit ratio of the DiskPageBufferMemory. Next time, I will explain about other counters you can get from ndbinfo.diskpagebuffer.

Finally, so no more guess work and educated guesses are needed.

Let's take an example.

I have a table t1 with 650000 record

CREATE TABLE `t1` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`data1` varchar(512) DEFAULT NULL,
`data2` varchar(512) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=ndbcluster TABLESPACE ts_1 STORAGE DISK  ENGINE=ndbcluster 

Then doing Random reads on this table with bencher:

 src/bencher -r 100000 -t 1 -q \
            "SET @x=FLOOR(1 + (RAND() * 650000));  SELECT * FROM t1 WHERE id=@x"

DiskPageBufferMemory=64M
The initial performance after 340 seconds into the run:

Thread 0 - 274 tps (average tps measured after 335 secs)
Thread 0 - 273 tps (average tps measured after 340 secs)

and the hit ratio:

mysql> SELECT
node_id,
100*(sum(page_requests_direct_return)/
 (sum(page_requests_direct_return)+sum(page_requests_wait_io))) as hit_ratio_pct
FROM diskpagebuffer GROUP BY node_id;
+---------+---------------+
| node_id | hit_ratio_pct |
+---------+---------------+
|       3 |       93.3577 |
|       4 |       93.6565 |
+---------+---------------+

2 rows in set (0.01 sec

A hit ratio of ~93% - not so great.

So let's increase the DiskPageBufferMemory ( i am using the configurator scripts for this)

# change DiskPageBufferMemory to 512M in config.ini
vi ../config/config.ini
# do a rolling restart of the data nodes
./rolling-restart.sh --layer=storage
## the sit back and wait for the data nodes to be rolled..
hostx: (324s elapsed) Node 3: starting (Last completed phase 100) (mysql-5.1.51 ndb-7.1.9)
hostx: Data node 3 is STARTED  
## then wait for node 4..
hosty: (98s elapsed) Node 4: starting (Last completed phase 4) (mysql-5.1.51 ndb-7.1.9)

Increasing DiskPageBufferMemory=512M
Of course, while doing the rolling restart, the same traffic is still happening on the cluster. Let's check what the hit_ratio is now (while restarting node 3).

695 seconds into the run we have:

mysql>  "see above"
+---------+---------------+
| node_id | hit_ratio_pct |
+---------+---------------+
|       4 |       91.2639 |
+---------+---------------+
1 row in set (0.00 sec)

and perf is...

Thread 0 - 200 tps (average tps measured after 690 secs)
Thread 0 - 200 tps (average tps measured after 695 secs)

not good at all.

After increase to DiskPageBufferMemory=512M
When the rolling restart has completed the ./rolling-restart prints out:

Cluster: Cluster has performed a rolling restart  

Let's check what hit ratio we got:

mysql>  "see above"
+---------+---------------+
| node_id | hit_ratio_pct |
+---------+---------------+
|       3 |       98.2487 |
|       4 |       98.6386 |
+---------+---------------+
2 rows in set (0.01 sec)

Hit ratio is picking up and performance as well:

Thread 0 - 1141 tps (average tps measured after 1310 secs)
Thread 0 - 1149 tps (average tps measured after 1315 secs)

Now, we just have to wait for a while and let the system enter a steady state.
Then we can check back on the hit ratio and perhaps increase the DiskPageBufferMemory even more.

If you have 99.5 -- 99.9% hit ratio i would say you are good.

After 1780 seconds into the run we have:

+---------+---------------+
| node_id | hit_ratio_pct |
+---------+---------------+
|       3 |       99.2035 |
|       4 |       99.5251 |
+---------+---------------+
2 rows in set (0.00 sec)

and

Thread 0 - 1669 tps (average tps measured after 1775 secs)
Thread 0 - 1674 tps (average tps measured after 1780 secs)

... wow .. tuning the DiskPageBufferMemory really helped. And 2000 sec into the run, perf and hit ratio is still climbing.
PlanetMySQL Voting: Vote UP / Vote DOWN

MySQL Cluster 7.1 introduced the ndbinfo database which contains views giving real-time access to a whole host of information that helps you monitor and tune your MySQL Cluster deployment. Because this data can be accessed through regular SQL, various systems can be configured to monitor the Cluster. This post gives one example, extending MySQL Enterprise Monitor to keep an eye on the amount of free memory on the data nodes (through a graph) and then raise an alarm when it starts to run low – even generating SNMP traps if that’s what you need.

One of the features of MySQL Enterprise Monitor is that you can define custom data collectors and that those data collectors can run SQL queries to get the data. The information retrieved by those custom data collectors can then be used with rules that the user defines through the MySQL Enterprise Monitor GUI to create warning/alarms.

In this example, I create two new data collectors in the file”<MySQL Enterprise Monitor installation directory>/agent/share/mysql-proxy/items/cluster.xml” before starting up the MySQL Enterprise Monitor agent (note that these should be created for the agent of each MySQL Server in the Cluster that you would like to use to present the information from the data nodes):

cluster.xml:

<?xml version="1.0" encoding="utf-8"?>
<classes>
  <class>
    <namespace>mysql</namespace>
    <classname>cluster_max_used</classname>
    <query><![CDATA[SELECT MAX(used) AS Used FROM ndbinfo.memoryusage WHERE memory_type = 'Data Memory';]]></query>
  </class>
  <class>
    <namespace>mysql</namespace>
    <classname>cluster_min_avail</classname>
    <query><![CDATA[SELECT MIN(total) AS Total FROM ndbinfo.memoryusage WHERE memory_type = 'Data Memory';]]></query>
  </class>
</classes>

So that the agent picks up this file, it should be referenced within <MySQL Enterprise Monitor installation directory>/agent/mysql-monitor-agent.ini:

agent-item-files = share/mysql-monitor-agent/items/quan.lua,share/mysql-monitor-agent/items/items-mysql-monitor.xml,
share/mysql-monitor-agent/items/custom.xml,share/mysql-monitor-agent/items/cluster.xml

In MySQL Enterprise Monitor, events are raised by rules. Rules are grouped together into Advisors and so I create a new Advisor called “MySQL Cluster” and then create just one new rule within that Advisor group.

As shown in Fig. 1 the rule is called “Data Node Low Memory”. The “Variable Assignment” section is used to define 2 variables %used_mem% and %config_mem% which are populated from the Used and Total results from the 2 new data collectors. The “Expression” section is used to test “((Total - Used)/Total)x100< THRESHOLD” and then the values to be substituted for THRESHOLD are defined in the “Thresholds” section – indicating at what points the Info, Warning and Critical Alters should be raised.

There are then a number of optional sections that you can use to add useful information to the person investigating the alert.

Once the rule has been created, the next step is to schedule and (if desired) tag that the alerts should also result in SNMP traps being raised. This is standard MySQL Enterprise Monitor practice and so it isn’t explained here except to point out that this rule is monitoring information from the data nodes but the rule has to be applied to a MySQL Server in the Cluster (MySQL Enterprise Monitor has no idea what a data node is) and so you need to schedule the rule against one or more arbitrary MySQL Server instances in the Cluster).

To test the functionality, start adding more data to your MySQL Cluster until the Warning alert is triggered as shown in Fig. 2. As you can see, the optional information we included is shown – including values from Used and Total.

 

 

 

 

 

I then add more data to the database until the critical alert is raised and confirm that it’s displayed on the main monitoring panel of the MySQL Enterprise Monitor dashboard. Note that if you requested these alerts be included with the SNMP feed then SNMP traps will also be raised.

Please note that this example is intended to illustrate the mechanics of setting up monitoring on an arbitrary piece of data from ndbinfo and obviously in the real world you would want to monitor more than just the memory and even for the memory, you might want to use a more sophisticated rule.

 

 

 

 

It is sometimes more useful to see how a value changes over time. For this, MySQL Enterprise Monitor provides graphs. The data collectors created for the rule can also be used to add a new graph to Enterprise monitor. The graph is defined by creating the following file:

<com_mysql_merlin_server_graph_Design>
  <version>1.0</version>
  <uuid>b0bc2bba-ea9b-102b-b396-94aca32b0b28</uuid>
  <tag></tag>
  <name>Per Data Node Data Memory Use</name>
  <rangeLabel>MB</rangeLabel> <frequency>00:01:00</frequency>
  <series>
    <label>Used</label>
    <expression>cluster_data_node_used_data_memory/1024/1024</expression>
  </series>
  <series>
    <label>Avail</label>
    <expression>cluster_data_node_config_data_memory/1024/1024</expression>
  </series>
  <variables>
    <name>cluster_data_node_used_data_memory</name>
    <dcItem>
      <nameSpace>mysql</nameSpace>
      <className>cluster_max_used</className>
      <attribName>Used</attribName>
    </dcItem>
    <instance>local</instance>
  </variables>
  <variables>
    <name>cluster_data_node_config_data_memory</name>
    <dcItem>
      <nameSpace>mysql</nameSpace>
      <className>cluster_min_avail</className>
      <attribName>Total</attribName>
    </dcItem>
    <instance>local</instance>
  </variables>
</com_mysql_merlin_server_graph_Design>
 

Click on Import/Export in the Graphs tab in Enterprise Monitor (2.2) and then import the file defining the graph.

The graph will then appear on the graphs tab and can also be configured to appear on the main dashboard as shown in Fig. 5

PlanetMySQL Voting: Vote UP / Vote DOWN

You may have read Berd’s recent post that explained how to try out some new beta functionality for MySQL Cluster and wondered what kind of use you could put the new ndb$info to. ndb$info uses tables/views to give real-time access to a whole host of information that helps you monitor and tune your MySQL Cluster deployment. This article gives one example, extending MySQL Enterprise Monitor to keep an eye on the amount of free memory on the data nodes and then raise an alarm when it starts to run low – even generating SNMP traps if that’s what you need.

One of the features of MySQL Enterprise Monitor is that you can define custom data collectors and that those data collectors can run SQL queries to get the data. The information retrieved by those custom data collectors can then be used with rules that the user defines through the MySQL Enterprise Monitor GUI to create warning/alarms.

In this example, I create two new data collectors and store the files in the “<MySQL Enterprise Monitor installation directory>/agent/share/mysql-proxy/items/” directory before starting up the MySQL Enterprise Monitor agents:

cluster_max_used.xml:

<?xml version="1.0" encoding="utf-8"?>
<classes>
  <class>
    <namespace>mysql</namespace>
    <classname>cluster_max_used</classname>
    <query><![CDATA[SELECT MAX(used) as Used FROM ndbinfo.memoryusage
      WHERE DATA_MEMORY = 'DATA_MEMORY']]>
    </query>
  </class>
</classes>

cluster_min_avail.xml:

<?xml version="1.0" encoding="utf-8"?>
<classes>
  <class>
    <namespace>mysql</namespace>
    <classname>cluster_min_avail</classname>
    <query><![CDATA[SELECT MIN(max)as Max FROM ndbinfo.memoryusage
       WHERE DATA_MEMORY = 'DATA_MEMORY']]>
    </query>
  </class>
</classes>

In MySQL Enterprise Monitor, rules are grouped together into Advisors and so I create a new Advisor called “MySQL Cluster” and then create just one new rule within that Advisor group.

As shown in Fig. 1 the rule is called “Data Node Low Memory”. The “Variable Assignment” section is used to define 2 variables %used_mem% and %config_mem% which are populated from the Used and Max results from the 2 new data collectors. The “Expression” section is used to test “(Max - Used) < THRESHOLD” and then the values to be substituted for THRESHOLD are defined in the “Thresholds” section – indicating at what points the Info, Warning and Critical Alters should be raised.

There are then a number of optional sections that you can use to add useful information to the person investigating the alert.

Once the rule has been created, the next step is to schedule it and (if desired) tag that the alerts should also result in SNMP traps being raised. This is standard MySQL Enterprise Monitor practice and so it isn’t explained here except to point out that this rule is monitoring information from the data nodes but the rule has to be applied to a MySQL Server (MySQL Enterprise Monitor has no idea what a data node is) and so you need to schedule the rule against one or more arbitrary MySQL Server instances in the Cluster.

 
 
To test the functionality, start adding more data to your MySQL Cluster until the Warning alert is triggered as shown in Fig. 2. As you can see, the optional information we included is shown – including values from Used and Max.
 
 
 
 
 
 

I then add more data to the database until the critical alert is raised and confirm that it’s displayed on the main monitoring panel of the MySQL Enterprise Monitor dashboard. Note that if you requested these alerts be included with the SNMP feed then SNMP traps will also be raised.

Please note that this example is intended to illustrate the mechanics of setting up monitoring on an arbitrary piece of data from ndbinfo and obviously in the real world you would want to monitor more than just the memory and even for the memory, you might want to use a more sophisticated rule.

PlanetMySQL Voting: Vote UP / Vote DOWN

The main new features in MySQL Cluster 7.1.1 (beta) is the following:

• ndbinfo (aka ndb$info) - Finally!! System tables for MySQL Cluster describing live usage of a lot of resources (RedoBuffer, Redo Log space, counters etc etc). Looks promising - makes Cluster a lot more transparent. See examples below.
  
• Cluster/J - for more information and to learn more about, register to a webinar and meet the architect and developer behind it!
  

Severalnines/Configurator supports 7.1.1 - to try it out!

NDBINFO - examples

Ever wondered how much for the RedoBuffer you are actually using?

mysql>  SELECT * FROM ndbinfo.logbuffers;
+---------+----------+--ç------+----------+----------+--------+
|       3 | REDO     |      0 |        1 | 33554432 | 229376 |
|       3 | REDO     |      0 |        2 | 33554432 | 229376 |
|       3 | REDO     |      0 |        3 | 33554432 |  98304 |
|       3 | REDO     |      0 |        4 | 33554432 | 229376 |
|       4 | REDO     |      0 |        1 | 33554432 | 262144 |
|       4 | REDO     |      0 |        2 | 33554432 |  65536 |
|       4 | REDO     |      0 |        3 | 33554432 |  98304 |
|       4 | REDO     |      0 |        4 | 33554432 | 262144 |
+---------+----------+--------+----------+----------+--------+

And how about the Redo log space?

mysql>  SELECT * FROM ndbinfo.logspaces;
+---------+----------+--------+----------+------------+-----------+
| node_id | log_type | log_id | log_part | total      | used      |
+---------+----------+--------+----------+------------+-----------+
|       3 | REDO     |      0 |        0 | 3221225472 | 200278016 |
|       3 | REDO     |      0 |        0 | 3221225472 | 201326592 |
|       3 | REDO     |      0 |        0 | 3221225472 | 202375168 |
|       3 | REDO     |      0 |        0 | 3221225472 | 202375168 |
|       4 | REDO     |      0 |        0 | 3221225472 | 201326592 |
|       4 | REDO     |      0 |        0 | 3221225472 | 201326592 |
|       4 | REDO     |      0 |        0 | 3221225472 | 202375168 |
|       4 | REDO     |      0 |        0 | 3221225472 | 202375168 |
+---------+----------+--------+----------+------------+-----------+
8 rows in set (0.00 sec)

Statistics ...

mysql> SELECT * FROM ndbinfo.counters;
+---------+------------+----------------+------------+--------------+-----------+
| node_id | block_name | block_instance | counter_id | counter_name | val       |
+---------+------------+----------------+------------+--------------+-----------+
|       3 | DBLQH      |              1 |         10 | OPERATIONS   |   1747971 |
|       3 | DBLQH      |              2 |         10 | OPERATIONS   |   1748870 |
|       3 | DBLQH      |              3 |         10 | OPERATIONS   |   1749056 |
|       3 | DBLQH      |              4 |         10 | OPERATIONS   |   1777925 |
|       4 | DBLQH      |              1 |         10 | OPERATIONS   |   1747976 |
|       4 | DBLQH      |              2 |         10 | OPERATIONS   |   1749008 |
|       4 | DBLQH      |              3 |         10 | OPERATIONS   |   1749033 |
|       4 | DBLQH      |              4 |         10 | OPERATIONS   |   1777928 |
|       3 | DBTC       |              0 |          1 | ATTRINFO     | 470827014 |
|       3 | DBTC       |              0 |          2 | TRANSACTIONS |    245150 |
|       3 | DBTC       |              0 |          3 | COMMITS      |    245137 |
|       3 | DBTC       |              0 |          4 | READS        |        25 |
|       3 | DBTC       |              0 |          5 | SIMPLE_READS |         0 |
|       3 | DBTC       |              0 |          6 | WRITES       |   3512472 |
|       3 | DBTC       |              0 |          7 | ABORTS       |        13 |
|       3 | DBTC       |              0 |          8 | TABLE_SCANS  |        29 |
|       3 | DBTC       |              0 |          9 | RANGE_SCANS  |         0 |
|       4 | DBTC       |              0 |          1 | ATTRINFO     | 472683577 |
|       4 | DBTC       |              0 |          2 | TRANSACTIONS |    218857 |
|       4 | DBTC       |              0 |          3 | COMMITS      |    218834 |
|       4 | DBTC       |              0 |          4 | READS        |        10 |
|       4 | DBTC       |              0 |          5 | SIMPLE_READS |         1 |
|       4 | DBTC       |              0 |          6 | WRITES       |   3501562 |
|       4 | DBTC       |              0 |          7 | ABORTS       |        22 |
|       4 | DBTC       |              0 |          8 | TABLE_SCANS  |         3 |
|       4 | DBTC       |              0 |          9 | RANGE_SCANS  |         0 |
+---------+------------+----------------+------------+--------------+-----------+
26 rows in set (0.12 sec)

And there is a lot more!

mysql> show tables;
+-------------------+
| Tables_in_ndbinfo |
+-------------------+
| blocks            |
| config_params     |
| counters          |
| logbuffers        |
| logspaces         |
| memoryusage       |
| nodes             |
| pools             |
| resources         |
| transporters      |
+-------------------+
10 rows in set (0.01 sec)

PlanetMySQL Voting: Vote UP / Vote DOWN

The main new features in MySQL Cluster 7.1.1 (beta) is the following:

• ndbinfo (aka ndb$info) - Finally!! System tables for MySQL Cluster describing live usage of a lot of resources (RedoBuffer, Redo Log space, counters etc etc). Looks promising - makes Cluster a lot more transparent. See examples below.
  
• Cluster/J - for more information and to learn more about, register to a webinar and meet the architect and developer behind it!
  

Severalnines/Configurator supports 7.1.1 - to try it out!

NDBINFO - examples

Ever wondered how much for the RedoBuffer you are actually using?

mysql>  SELECT * FROM ndbinfo.logbuffers;
+---------+----------+--ç------+----------+----------+--------+
|       3 | REDO     |      0 |        1 | 33554432 | 229376 |
|       3 | REDO     |      0 |        2 | 33554432 | 229376 |
|       3 | REDO     |      0 |        3 | 33554432 |  98304 |
|       3 | REDO     |      0 |        4 | 33554432 | 229376 |
|       4 | REDO     |      0 |        1 | 33554432 | 262144 |
|       4 | REDO     |      0 |        2 | 33554432 |  65536 |
|       4 | REDO     |      0 |        3 | 33554432 |  98304 |
|       4 | REDO     |      0 |        4 | 33554432 | 262144 |
+---------+----------+--------+----------+----------+--------+

And how about the Redo log space?

mysql>  SELECT * FROM ndbinfo.logspaces;
+---------+----------+--------+----------+------------+-----------+
| node_id | log_type | log_id | log_part | total      | used      |
+---------+----------+--------+----------+------------+-----------+
|       3 | REDO     |      0 |        0 | 3221225472 | 200278016 |
|       3 | REDO     |      0 |        0 | 3221225472 | 201326592 |
|       3 | REDO     |      0 |        0 | 3221225472 | 202375168 |
|       3 | REDO     |      0 |        0 | 3221225472 | 202375168 |
|       4 | REDO     |      0 |        0 | 3221225472 | 201326592 |
|       4 | REDO     |      0 |        0 | 3221225472 | 201326592 |
|       4 | REDO     |      0 |        0 | 3221225472 | 202375168 |
|       4 | REDO     |      0 |        0 | 3221225472 | 202375168 |
+---------+----------+--------+----------+------------+-----------+
8 rows in set (0.00 sec)

Statistics ...

mysql> SELECT * FROM ndbinfo.counters;
+---------+------------+----------------+------------+--------------+-----------+
| node_id | block_name | block_instance | counter_id | counter_name | val       |
+---------+------------+----------------+------------+--------------+-----------+
|       3 | DBLQH      |              1 |         10 | OPERATIONS   |   1747971 |
|       3 | DBLQH      |              2 |         10 | OPERATIONS   |   1748870 |
|       3 | DBLQH      |              3 |         10 | OPERATIONS   |   1749056 |
|       3 | DBLQH      |              4 |         10 | OPERATIONS   |   1777925 |
|       4 | DBLQH      |              1 |         10 | OPERATIONS   |   1747976 |
|       4 | DBLQH      |              2 |         10 | OPERATIONS   |   1749008 |
|       4 | DBLQH      |              3 |         10 | OPERATIONS   |   1749033 |
|       4 | DBLQH      |              4 |         10 | OPERATIONS   |   1777928 |
|       3 | DBTC       |              0 |          1 | ATTRINFO     | 470827014 |
|       3 | DBTC       |              0 |          2 | TRANSACTIONS |    245150 |
|       3 | DBTC       |              0 |          3 | COMMITS      |    245137 |
|       3 | DBTC       |              0 |          4 | READS        |        25 |
|       3 | DBTC       |              0 |          5 | SIMPLE_READS |         0 |
|       3 | DBTC       |              0 |          6 | WRITES       |   3512472 |
|       3 | DBTC       |              0 |          7 | ABORTS       |        13 |
|       3 | DBTC       |              0 |          8 | TABLE_SCANS  |        29 |
|       3 | DBTC       |              0 |          9 | RANGE_SCANS  |         0 |
|       4 | DBTC       |              0 |          1 | ATTRINFO     | 472683577 |
|       4 | DBTC       |              0 |          2 | TRANSACTIONS |    218857 |
|       4 | DBTC       |              0 |          3 | COMMITS      |    218834 |
|       4 | DBTC       |              0 |          4 | READS        |        10 |
|       4 | DBTC       |              0 |          5 | SIMPLE_READS |         1 |
|       4 | DBTC       |              0 |          6 | WRITES       |   3501562 |
|       4 | DBTC       |              0 |          7 | ABORTS       |        22 |
|       4 | DBTC       |              0 |          8 | TABLE_SCANS  |         3 |
|       4 | DBTC       |              0 |          9 | RANGE_SCANS  |         0 |
+---------+------------+----------------+------------+--------------+-----------+
26 rows in set (0.12 sec)

And there is a lot more!

mysql> show tables;
+-------------------+
| Tables_in_ndbinfo |
+-------------------+
| blocks            |
| config_params     |
| counters          |
| logbuffers        |
| logspaces         |
| memoryusage       |
| nodes             |
| pools             |
| resources         |
| transporters      |
+-------------------+
10 rows in set (0.01 sec)

PlanetMySQL Voting: Vote UP / Vote DOWN

Bernhard blogged over at http://ocklin.blogspot.com/2010/02/mysql-cluster-711-is-there.html that MySQL Cluster 7.1.1 Beta has been released. The big feature (from my point of view) is the SQL interface on top of NDB$INFO. This means there is now full infrastructure from the NDB data nodes right out to SQL in the MySQL Server for adding monitoring to any bit of the internals of the data nodes.

PlanetMySQL Voting: Vote UP / Vote DOWN