s3:libads/sasl: use gensec_max_{input,wrapped}_size() in ads_sasl_spnego_ntlmssp_bind
[Samba.git] / ctdb / web / testing.html
blobd0d39a35f8dca08603d859d5c61763863ed4ffce
1 <!--#set var="TITLE" value="CTDB Testing" -->
2 <!--#include virtual="header.html" -->
4 <H2 align="center">Starting and testing CTDB</h2>
6 The CTDB log is in /var/log/log.ctdb so look in this file if something
7 did not start correctly.<p>
9 You can ensure that ctdb is running on all nodes using
10 <pre>
11 onnode all service ctdb start
12 </pre>
13 Verify that the CTDB daemon started properly. There should normally be at least 2 processes started for CTDB, one for the main daemon and one for the recovery daemon.
14 <pre>
15 onnode all pidof ctdbd
16 </pre>
18 Once all CTDB nodes have started, verify that they are correctly
19 talking to each other.<p>
21 There should be one TCP connection from the private ip address on each
22 node to TCP port 4379 on each of the other nodes in the cluster.
23 <pre>
24 onnode all netstat -tn | grep 4379
25 </pre>
28 <h2>Automatically restarting CTDB</h2>
30 If you wish to cope with software faults in ctdb, or want ctdb to
31 automatically restart when an administration kills it, then you may
32 wish to add a cron entry for root like this:
34 <pre>
35 * * * * * /etc/init.d/ctdb cron > /dev/null 2>&1
36 </pre>
39 <h2>Testing CTDB</h2>
41 Once your cluster is up and running, you may wish to know how to test that it is functioning correctly. The following tests may help with that
43 <h3>The ctdb tool</h3>
45 The ctdb package comes with a utility called ctdb that can be used to
46 view the behaviour of the ctdb cluster.<p>
48 If you run it with no options it will provide some terse usage information. The most commonly used commands are:
49 <pre>
50 ctdb status
51 ctdb ip
52 ctdb ping
53 </pre>
55 <h3>ctdb status</h3>
57 The status command provides basic information about the cluster and the status of the nodes. when you run it you will get some output like:
59 <pre>
60 <strong>Number of nodes:4
61 vnn:0 10.1.1.1 OK (THIS NODE)
62 vnn:1 10.1.1.2 OK
63 vnn:2 10.1.1.3 OK
64 vnn:3 10.1.1.4 OK</strong>
65 Generation:1362079228
66 Size:4
67 hash:0 lmaster:0
68 hash:1 lmaster:1
69 hash:2 lmaster:2
70 hash:3 lmaster:3
71 <strong>Recovery mode:NORMAL (0)</strong>
72 Recovery master:0
73 </pre>
75 The important parts are in bold. This tells us that all 4 nodes are in
76 a healthy state.<p>
78 It also tells us that recovery mode is normal, which means that the
79 cluster has finished a recovery and is running in a normal fully
80 operational state.<p>
82 Recovery state will briefly change to "RECOVERY" when there ahs been a
83 node failure or something is wrong with the cluster.<p>
85 If the cluster remains in RECOVERY state for very long (many seconds)
86 there might be something wrong with the configuration. See
87 /var/log/log.ctdb.
89 <h3>ctdb ip</h3>
91 This command prints the current status of the public ip addresses and which physical node is currently serving that ip.
93 <pre>
94 Number of nodes:4
95 192.168.1.1 0
96 192.168.1.2 1
97 192.168.2.1 2
98 192.168.2.1 3
99 </pre>
101 <h3>ctdb ping</h3>
102 this command tries to "ping" each of the CTDB daemons in the cluster.
103 <pre>
104 ctdb ping -n all
106 response from 0 time=0.000050 sec (13 clients)
107 response from 1 time=0.000154 sec (27 clients)
108 response from 2 time=0.000114 sec (17 clients)
109 response from 3 time=0.000115 sec (59 clients)
110 </pre>
112 <!--#include virtual="footer.html" -->