I use ganglia to monitor hadoop. I choose the metric "dfs.datanode.HeartbeatsAvgTime" to judge whether the datanode(I mean datanode service, not the host.) is down or not.
When the datanode is working fine, the "dfs.datanode.HeartbeatsAvgTime" is remaining changing. That's to say ,the value in the graph is varing.
It looks like this:
but after I stop the datanode service, the value in the graph remains not change.
It looks like this:
The value in the second graph remains unchanged.But the value is not 0 or infinity. So, I can not judge the datanode service is up or down.
It is the same when deal with other metrics.
I've check rrd which is used by ganglia to store the metric data with "rrdtool fetch". The value about the metric is stored in a *.rrd file.when I check the file, I find that after I stop datanode, the value about the metric is also updated. But the value is not varing.
I read the references about rrd in rrd's official website. they says that, if rrd did not receive update date between the interval setted before, rrd write UNKNOWN in the *.rrdfile.
I think that there may be two causes to raise the problem.
when the gmetad did not receive metric. it update rrd with the old value.So the graph stay the same as the old value.
when gmond can not collect metric, it report the old value to gmetad.
But I haven't really find any evidence in the source code in the github of ganglia.
So do you know how to solve the problem that value in the graph remain unchanged? or do you know other details about how to monitor hadoop cluster with ganglia?
#DaveStephens #Lorin Hochstein
After my struggle to solve the problem, I found that if we set dmax of the metric in hadoop-metrics2.properties, when the hadoop break down, ganglia would not receive any data, and return UNKNOW. The graph in the ganglia website will disappear . when ganglia + nagios, nagios will also return UNKNOW status. that's enough to judge whether hadoop is up or down.
dmax means that after dmax time, hadoop will destroy the metric.
Related
MarkLogic 9.0.8.2
We have configured MarkLogic cluster (3 nodes) as follows
PF - primary forest, RF - replica forest
Host1: PF01 RF02 RF03
Host2: PF02 RF01 RF03
Host3: PF03 RF01 RF02
In normal scenario, when we see database status page, PF should be in "open" state and and everything else will be "wait replicating" state.
Now due to some reason, state of RF01 and RF02 became in "open" state, so that means all load is now on Host3
Reindexing is in progress.
Now question is while reindexing is in progress, can we restart RF01-2 & RF02-2, so that PF01 and PF02 are again in "open" state?
Are there any best practices we should follow for forest restart?
See this knowledgbase article What Triggers Failover in MarkLogic Server
If this occurred during a reindex, I suspect that you may not have sufficient resources to support the workload. Depending on what "normal" is for your system, reindexing can cause an increase in resource demands.
Look through your ErrorLog.txt and I suspect you will see signs of trouble. Look for any log events with a severity greater than INFO (NOTICE, WARNING, ERROR, CRITICAL).
You may need to reduce the throttle of your reindexing and consider scaling options to ensure that your cluster is appropriately sized. You might consider opening a MarkLogic Support ticket, if you are eligible.
If you think that the primary hosts are ready to take over, you can "flip the forests" back to the primary by restarting the replica forests that are now open.
See the documentation: Reverting a Failed Over Forest Back to the Primary Host
Also, the following knowledgebase article provides a script that can be executed in order to flip all of the open replicas:
https://help.marklogic.com/Knowledgebase/Article/View/427/0/scripting-failover-flipping-replica-forests-back-to-their-masters-using-xquery
I believe, you should wait until your re-indexing is complete. Once the re-indexing is completed you can flip back forests. As re-indexing started when master was in open state its possible that some documents might not be synced in master forests and re-indexing completed or failed. Those documents might get missed.
After going through H2 developer guide I still don't understand how can I find out what cluster node(s) was/were failing and which database needs to be recovered in the event of temporary network failure.
Let's consider the following scenario:
H2 cluster started with N active nodes (is actually it true that H2 can support N>2, i.e. more than 2 cluster nodes?)
(lots DB updates, reads...)
Network connection with one (or several) cluster nodes gets down and node becomes invisible to the rest of the cluster
(lots of DB updates, reads...)
Network link with previously disconnected node(s) restored
It is discovered that cluster node was probably missing (as far as I can see SELECT VALUE FROM INFORMATION_SCHEMA.SETTINGS WHERE NAME='CLUSTER' starts responding with empty string if one node in cluster fails)
After this point it is unclear how to find out what nodes were failing?
Obviously, I can do some basic check like comparing DB size, but it is unreliable.
What is the recommended procedure to find out what node was missing in the cluster, esp. if query above responds with empty string?
Another question - why urlTarget doesn't support multiple parameters?
How I am supposed to use CreateCluster tool if multiple nodes in the cluster failed and I want to recover more than one?
Also I don't understand how CreateCluster works if I had to stop the cluster and I don't want to actually recover any nodes? What's not clear to me is what I need to pass to CreateCluster tool if I don't actually need to copy database.
That is partially right SELECT VALUE FROM INFORMATION_SCHEMA.SETTINGS WHERE NAME='CLUSTER', will return an empty string when queried in standard mode.
However, you can get the list of servers by using Connection.getClientInfo() as well, but it is a two-step process. Paraphrased from h2database.com:
The list of properties returned by getClientInfo() includes a numServers property that returns the number of servers that are in the connection list. getClientInfo() also has properties server0..serverN, where N is the number of servers - 1. So to get the 2nd server from the list you use getClientInfo('server1').
Note: The serverX property only returns IP addresses and ports and not
hostnames.
And before you say simple replication, yes that is default operation, but you can do more advanced things that are outside the scope of your question in clustered H2.
Here's the quote for what you're talking about:
Clustering can only be used in the server mode (the embedded mode does not support clustering). The cluster can be re-created using the CreateCluster tool without stopping the remaining server. Applications that are still connected are automatically disconnected, however when appending ;AUTO_RECONNECT=TRUE, they will recover from that.
So yes if the cluster stops, auto_reconnect is not enabled, and you stick with the basic query, you are stuck and it is difficult to find information. While most people will tell you to look through the API and or manual, they haven't had to look through this one so, my sympathies.
I find it way more useful to track through the error codes, because you get a real good idea of what you can do when you see how the failure is planned for ... here you go.
The documentation almost exactly the same for both, so I find it really hard to see the difference between them. Based on this Q&A, the sole difference is
[...] that checkpoint node can upload the new copy of fsimage file back to namenode after checkpoint creation where as a secondary namenode can’t upload [...]
It doesn't seem correct, because the Secondary NameNode can upload the new FsImage, based on this and this.
Can the Checkpoint Node be considered as a one-to-one replacement of the Secondary NameNode? What are the added benefits? Was the code cleaned up between the two or something like that?
In the cloudera post you mentioned, the checkpointing process is clearly mentioned in both HighAvailability and NonHighAvailability scenarios. Secondary name node performs the task of checkpointing namenode in Non-HA scenario. In other scenario of HA, we can use standby namenode for checkpointing. In summary, checkpointing is more of a concept and depending of the scenario(HA/nonHA), different nodes perform that operation.
You can read that blog again. And let me know if any corrections are needed. Happy Learning
The difference between SNN and Check point NN is that SNN stores the data locally in file system but it does not upload the merged fsimage (with edit logs) to Active NN which Checkpoint NN does.
Even Apache documentation page does not cover differences properly. From the documentation page, it seems that role of both Secondary Name node & Checkpoint Node seems to be similar.
On a different note, I have raised a bug to correct the documentation page to avoid confusion : https://issues.apache.org/jira/browse/HDFS-8913
I hope this bug will be resolved soon.
Regarding your second query:
Can the Checkpoint Node be considered as a one-to-one replacement of the Secondary NameNode? What are the added benefits? Was the code cleaned up between the two or something like that?
Lot of things have changed with Hadoop 2.x release and Name node is not a single point of failure.
High Availability of Active name node with help of Stand by Name node is key feature in Hadoop 2.x.
You just need Active Name node and Stand by Name Node to achieve high availability.
Hadoop 2.x High Availability has been explained clearly in other SE questions:
Hadoop namenode : Single point of failure
How does Hadoop Namenode failover process works?
Let's say I have 3 nodes. 1 of which is the master.
I have an API (running on another machine) which hits the master and gets my search result. This is through a subdomain, say s1.mydomain.com:9200 (assume the others are pointed to by s2.mydomain.com and s3.mydomain.com).
Now my master fails for whatever reason. How would my API recover from such a situation? Can I hit either S2 or S3 instead? How can I figure out what the new master is? Is there a predictable way to know which one would be picked as the new master should the master go down?
I've googled this and it's given me enough information about how when a master goes down, a failover is picked as the new master but I haven't seen anything clarify how I would need to handle this from the outside looking in.
The master in ElasticSearch is really only for internal coordination. There are no actions required when a node goes down, other than trying to get it back up to get your full cluster performance back.
You can read/write to any of the remaining nodes and the data replication will keep going. When the old master node comes back up, it will re-join the cluster once it has received the updated data. In fact, you never need to worry if the node you are writing on is the master node.
There are some advanced configurations to alter these behaviors, but ElasticSearch comes with suitable defaults.
I am looking for some help in figuring out how to clear what looks like a corruption in Zookeeper. Our setup was running fine with Solr Cloud. At some point the root partition on one of the cluster nodes became full and the system went down. After we brought it back up, Solr was not responding and could not start.
It looks like there is a corruption in the zookeeper data. Anytime a client tries to access the node /overseer/queue it will kill the connection with an error:
..."KeeperException$ConnectionLossException: KeeperErrorCode = ConnectionLoss for /overseer/queue"
Opening up the zk client shell allows us to list other nodes, but if we try to delete/list/clear/etc on the /overseer node it will fail with this error.
Are there any manual steps that could be done to clear this out? Any help would be appreciated.
Edit: Also it looks like there are over 200k child nodes under the /overseer/queue node. Maybe this has something to do with it, but we can't delete the child nodes if we can't even list them out.
The Zookeeper database isn't corrupt, but zookeeper has a limit on the maximum response size, and listing 200k children of a znode exceeds this max response size.
To work around this, you can set jute.maxbuffer to a large value to let you list and delete the nodes under queue. You need to update this setting on all the servers, and the client you are using to clean up.
There is an open bug to fix this, ZOOKEEPER-1162 .