Skip to content

Latest commit

 

History

History
126 lines (102 loc) · 4.15 KB

step2.md

File metadata and controls

126 lines (102 loc) · 4.15 KB
Write Path ℹ️ For technical support, please contact us via email.
⬅️ Back Step 2 of 2 Next ➡️
Observe the memtables and commit log before and after a flush

✅ Execute the following nodetool command:

nodetool tablestats keyspace1.standard1

cassandra-stress created keyspace1 and the standard1 table and populated its data. Running nodetool tablestats gives you the statistics for that table.

Output

### {"execute":false}
Total number of tables: 59
----------------
Keyspace : keyspace1
        Read Count: 0
        Read Latency: NaN ms
        Write Count: 250000
        Write Latency: 0.013440336 ms
        Pending Flushes: 0
                Table: standard1
                SSTable count: 2
                Space used (live): 59575885
                Space used (total): 59575885
                Space used by snapshots (total): 0
                Off heap memory used (total): 699116
                SSTable Compression Ratio: -1.0
                Number of partitions (estimate): 252290
                Memtable cell count: 1180
                Memtable data size: 319780
                Memtable off heap memory used: 388020
                Memtable switch count: 11
                ...

Check that the Write Count matches the number of rows we told cassandra-stress to insert. nodetool tablestats also reports the number of SSTables, space used, and bloom filter statistics.

✅ Make note of the Memtable statistics in the nodetool tablestats output. Specifically, the memtable for the keyspace1.standard1 table is not empty.

✅ Execute the following nodetool command to flush the memtable content of all tables in all keyspaces to disk:

nodetool flush

✅ Check the statistics for the keyspace1.standard1 table again by executing:

nodetool tablestats keyspace1.standard1

Confirm that the Memtable statistics have zeroed out because we flushed the previous memtable to disk.

Output

### {"execute":false}
      ...
      Memtable cell count: 0
      Memtable data size: 0
      Memtable off heap memory used: 0
      Memtable switch count: 12
      ...

✅ Run the following commands to shut down the node and clear out the system logs:

nodetool stopdaemon
rm -f ./node/logs/*.log

✅ Start up the node again using the following command:

cassandra

Wait for the node to finish starting up before continuing.

✅ Open the system.log file, located at ~/node/logs/system.log, using a command-line editor.

nano ~/node/logs/system.log

✅ In the system.log, look for messages that includes the word CommitLog.java.

### {"execute":false}
... CommitLog.java:194 - Replaying /home/ubuntu/node/data/commit-log/CommitLog-680-1586320327793.log, /home/ubuntu/node/data/commit-log/CommitLog-680-1586320327794.log
... CommitLog.java:196 - Log replay complete, 37 replayed mutations

If there are existing commit log files while Cassandra is starting up, it will replay the mutations in those logs into memtables and then automatically flush the memtables to disk.

If there happen to be no commit log segments found during start up, then no replay needs to be done.

⬅️ Back Next ➡️