But for session data, do we really care?
If the Cluster is history then the sessions are most likely to be obsolete when the cluster recovers.
And do we want to use disk space and disk band width for the session data?
If you answer "no" on the questions above, then you can create a table that is not checkpointed nor redo logged, by setting the session variable
mysql> use test;
#enable no logging
mysql> set ndb_table_no_logging=1;
Query OK, 0 rows affected (0.02 sec)
#a grossly simplified structure:
# this table will not be checkpointed or redo logged, because of
mysql> create table session(id bigint primary key, data varbinary(1024), expiry_time timestamp) engine=ndb;
Query OK, 0 rows affected (1.21 sec)
# disable creation of tables with no logging (i.e, enable logging again, default behavior):
mysql> set ndb_table_no_logging=0;
Query OK, 0 rows affected (0.00 sec)
To verify that the table is not logged (look for Temporary table):
johan@stingray:~$ ndb_desc -d test session
-- session --
Fragment type: 5
K Value: 6
Min load factor: 78
Max load factor: 80
Temporary table: yes
Number of attributes: 3 Number of primary keys: 1
Length of frm data: 289
Row Checksum: 1 Row GCI:
1 SingleUserMode: 0
-- Attributes --
id Bigint PRIMARY KEY DISTRIBUTION KEY AT=FIXED ST=MEMORY
data Longvarbinary(1024) NULL AT=MEDIUM_VAR ST=MEMORY
expiry_time Timestamp NOT NULL AT=FIXED ST=MEMORY
-- Indexes --
PRIMARY KEY(id) - UniqueHashIndex
PRIMARY(id) - OrderedIndex
NDBT_ProgramExit: 0 - OK
If the Cluster crashes and later recovers the
sessiontable will not contain any data, but will be completely empty.
I don't think this works with Disk data tables, but i haven't tried so I don't know the error you will get.
This is a technique that we have implemented with quite a few customers using Cluster for session management.