High Availability MySQL Cookbook phần 7 docx

Chapter 4

129

773/tcp open submit

3306/tcp open mysql

Nmap finished: 1 IP address (1 host up) scanned in 0.089 seconds

Host resolution

If you are not using IP addresses in the config.ini file (strongly recommended), ensure that

you have all of the hosts involved in the cluster in a /etc/hosts file to ensure that a simple

DNS outages does not take down the entire cluster. For example, your /etc/hosts may look

as follows:

[root@node1 mysql-cluster]# cat /etc/hosts

# Do not remove the following line, or various programs

# that require network functionality will fail.

127.0.0.1 node1.xxx.com node1 localhost.localdomain localhost

::1 localhost6.localdomain6 localhost6

10.0.0.1 node1.xxx.com node1

10.0.0.2 node2.xxx.com node2

10.0.0.3 node3.xxx.com node3

10.0.0.4 node4.xxx.com node4

10.0.0.5 node5.xxx.com node5

Memory

It is extremely common for IndexMemory and DataMemory to use more memory than the

system's free memory.

This is commonly caused by running another process on the same server as

a storage node, such as a standard MySQL server (which may use a large

amount of RAM while executing a specific query). It is recommended that

storage nodes only run the storage node processes.

In the case that this becomes a regular problem, it is possible to tune the Linux kernel out of

memory (OOM) killer (this is the piece of code which decides which process to kill in the case

of running out of physical memory) to kill another process and not the ndbd process. There

is a value, /proc/<pid>/oom-adj, which ranges from -16 to +15 (-17 means never kill this

process). The following bash snippet can be used to run after a storage node has started to

significantly reduce the change of the OOM killer, killing ndbd:

[root@node1 mysql-cluster]# for pid in $(pidof ndbd); do echo "-10" > /

proc/$pid/oom_adj; done;

[root@node1 mysql-cluster]#

However, it is still recommended not to come near to running out of physical memory on

a storage node!

MySQL Cluster Troubleshooting

130

Seeking help

In this recipe, we will cover what to do when help is required and where the tips in the

Debugging a MySQL Cluster recipe have not helped.

Getting ready

Before considering Seeking help, it is important to ensure that you have attempted

everything yourself.

If you are experiencing a critical problem with a production system, then it is

likely a good idea to engage professional support immediately (available from

MySQL and other firms).

Community support is excellent for MySQL Cluster and comes in several forms. To use any

support, however, it is important to know exactly what you are asking. In this recipe, we will

first cover confirming exactly what the problem is (and how to describe it), then discuss how to

look for help, and finally briefly cover the process of submitting a bug to MySQL (if this is what

you have found).

How to do it...

Firstly, ensure that you have carried out all the steps in the previous debugging recipe.

It is also a good idea to see if you can reproduce your issue, either on the same cluster or on

a different development cluster. If you can, then write down a clear test case that someone

else could use to recreate your problem for themselves. If you can do this, then the chances

of your problem or bug being resolved increase enormously.

Having established exactly what is wrong and attempted to reproduce it, search the MySQL

online manual at http://dev.mysql.com/doc/. Also search the bugs database at

http://bugs.mysql.com/ to see whether the bug has been reported and fixed. Finally,

search the MySQL mailing list archives at http://lists.mysql.com/. You can also use

http://www.mysql.com/search/ to search all the web pages (this search includes the

manual, mailing list, and forums).

During the searching process, keep a record of URLs that seem to be related

to your problem. Even if they do not help you immediately, including them

when you directly ask the community for help saves someone else a search

and may help others help you.