Question-: Which all of the below are correct for the “nodetool tablehistograms� command? A. It provides the current table level statistics. B. It provide the detail of an individual table read and write latency since last 15 minues. C. It provide the information about the entire clutser. D. It provides the latencies of a node. E. It provides all the tables name which are not in sync across the cluster
Answer: A,B
Explanation: The “nodetool tablehistograms� table let you know the last 15 minutes detail for a table in a keyspace. For example, what is the read and write latency for a table since last 15 minutes. It also tells you that partition size, cell count, and number of SSTables for that table. Hence, we should use this command to analyze the performance and tuning the individual table.
Admin only
Question-: Please map the followings A. logback.xml B. system.log C. debug.log D. gc.log
1. You can set the log levels and location of the log files in this. 2. In this you can check when the nodes leaving and joining 3. Access Mostly Uused Products by 50000+ Subscribers 4. You can check the application pause time in this log
Answer: A-1, B-2, C-3, D-4
Explanation: You must need to understand the logging mechanism in Cassandra. Let’s start with basic detail. There are various log levels like “Trace -> Debug -> Info -> Warning -> Error -> OFF (no logging at all) etc.� So when you set log level as Trace , it would print lot of information which you may not need, once your cluster is operational. When you set the INFO then it would print all the information, warnings and Errors if there are any in the cluster. If you set Error then it would print only Errors. So low level of logging you have, it would include more information about the cluster. But please keep in mind that having lot of logs can impact the overall performance of the cluster. So generally, by default you can keep the log level as INFO, which can tell you all the required cluster information as well as if there are any warning and errors then that would be printed in the logs. This log level settings as well as the location of the log files to be created is set on the “logback.xml� file. System.log : This is the default logs for the Cassandra DB. Where you can check the following things - Is there any Uncaught java exceptions. - If there is any issue with the GC like long pauses then it can be printed in this log - When node joins and leaves - If there is any change in the token ownership because nodes are joining and leaving. - Not enough CPU and memory and can cause the high GC pauses. - Is the OS is properly configured or not for the Cassandra DB to be setup on this Linux/Unix node. Debug.log: - This has lot of information to debug the DB. However, you should first check the System.log and then only come to check this log. - It can tell you detail about all the compaction, when they were started and when was finished. And during the compaction which all SSTables were included. - When the memtable flushes on the disk. What was the size of the memtable flush. - Which commit segments was affected by this flush. Gc.log : As name suggest it is mainly for the Java Garbage collection information - You would get to know application pause time - Why the pause happened
Admin only
Question-: Which of the following information you can check with the “system.log� ? A. All the gc pauses B. When the nodes are leaving and joining C. Metadata ownership change information D. Index redistribution E. Which node was attacked by hacker?
Answer: A, B, C, D Exp: Using the system.log you can get the following information about your Cassandra cluster setup. - Is there any Uncaught java exceptions? - If there is any issue with the GC like long pauses then it can be printed in this log - When the long pauses happen, what is current state of the thread when it was paused. - When node joins and leaves. - If Keyspace/tables created, deleted or any other modifications are done. - If there is any change in the token ownership because nodes are joining and leaving. - Not enough CPU and memory and can cause the high GC pauses. - Is the OS is properly configured or not for the Cassandra DB to be setup on this Linux/Unix node. This is done using the startup checks. - It will also tell you if there are any background operations are going on or not. For example Index Redistribution etc.