FREEZE prepares a real-time/plain table for a safe backup. In particular it:
- Disables table compaction. If the table is being compacted right now
FREEZEwill wait for it to finish. - Flushes current RAM chunk into a disk chunk.
- Flushes attributes.
- Disables implicit operations that may change the files on disk.
- Displays actual list of the files belonging to the table.
Built-in tool manticore-backup uses FREEZE to guarantee data consistency. So can you if you want to make your own backup solution or need to freeze tables for whatever else reason. All you need to do is:
FREEZEa table.- Grab output of the
FREEZEcommand and backup the provided files. UNFREEZEthe table once you are done.
- Example
FREEZE t;+-------------------+---------------------------------+
| file | normalized |
+-------------------+---------------------------------+
| data/t/t.0.spa | /work/anytest/data/t/t.0.spa |
| data/t/t.0.spd | /work/anytest/data/t/t.0.spd |
| data/t/t.0.spds | /work/anytest/data/t/t.0.spds |
| data/t/t.0.spe | /work/anytest/data/t/t.0.spe |
| data/t/t.0.sph | /work/anytest/data/t/t.0.sph |
| data/t/t.0.sphi | /work/anytest/data/t/t.0.sphi |
| data/t/t.0.spi | /work/anytest/data/t/t.0.spi |
| data/t/t.0.spm | /work/anytest/data/t/t.0.spm |
| data/t/t.0.spp | /work/anytest/data/t/t.0.spp |
| data/t/t.0.spt | /work/anytest/data/t/t.0.spt |
| data/t/t.meta | /work/anytest/data/t/t.meta |
| data/t/t.ram | /work/anytest/data/t/t.ram |
| data/t/t.settings | /work/anytest/data/t/t.settings |
+-------------------+---------------------------------+
13 rows in set (0.01 sec)The column file provides paths to the table's files inside data_dir of the running instance. The column normalized shows absolute paths of the same files. If you want to back up a table it's safe to just copy the provided files with no other preparations.
When a table is frozen, you can't perform UPDATE queries on it; they will fail with the error message index is locked now, try again later.
Also, DELETE and REPLACE queries have some limitations while the table is frozen:
- If
DELETEaffects a document stored in a current RAM chunk - it is allowed. - If
DELETEaffects a document in a disk chunk, but it was already deleted before - it is allowed. - If
DELETEis going to change an actual disk chunk - it will wait until the table is unfrozen.
Manual FLUSH of a RAM chunk of a frozen table will report 'success', however no actual save will happen.
DROP/TRUNCATE of a frozen table is allowed, since such operation is not implicit. We assume that if you truncate or drop a table - you don't need it backed up anyway, therefore it should not have been frozen in the first place.
INSERT into a frozen table is supported, but also limited: new data will be stored in RAM (as usual), until rt_mem_limit is reached; then new insertions will wait until the table is unfrozen.
If you shut down the daemon with a frozen table, it will behave as in case of a dirty shutdown (e.g. kill -9): new inserted data will not be saved in the RAM-chunk on disk, and on restart it will be restored from a binary log (if any), or lost (if binary logging is disabled).
UNFREEZE re-enables previously blocked operations and restarts the internal compaction service. All the operations that are waiting for a table unfreeze get unfrozen too and finish their operations normally.
- Example
UNFREEZE tbl;FLUSH ATTRIBUTESFlushes all in-memory attribute updates in all the active disk tables to disk. Returns a tag that identifies the result on-disk state (basically, a number of actual disk attribute saves performed since the server startup).
mysql> UPDATE testindex SET channel_id=1107025 WHERE id=1;
Query OK, 1 row affected (0.04 sec)
mysql> FLUSH ATTRIBUTES;
+------+
| tag |
+------+
| 1 |
+------+
1 row in set (0.19 sec)FLUSH HOSTNAMESRenews IPs associates to agent host names. To always query the DNS for getting the host name IP, see hostname_lookup directive.
mysql> FLUSH HOSTNAMES;
Query OK, 5 rows affected (0.01 sec)