FREEZE tbl1[, tbl2, ...]
FREEZE readies a real-time/plain table for a secure backup. Specifically, it:
- Deactivates table compaction. If the table is currently being compacted,
FREEZEwill wait for completion.
- Transfers the current RAM chunk to a disk chunk.
- Flushes attributes.
- Disables implicit operations that could modify the disk files.
- Shows the actual file list associated with the table.
The built-in tool manticore-backup uses
FREEZE to ensure data consistency. You can do the same if you want to create your own backup solution or need to freeze tables for other reasons. Just follow these steps:
FREEZEa table (or a few).
- Capture the output of the
FREEZEcommand and back up the specified files.
UNFREEZEthe table(s) once finished.
+-------------------+---------------------------------+ | 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)
file column indicates the table's file paths within the data_dir of the running instance. The
normalized column displays the absolute paths for the same files. To back up a table, simply copy the provided files without additional preparation.
When a table is frozen, you cannot execute
UPDATE queries; they will fail with the error message "index is locked now, try again later."
REPLACE queries have some restrictions while the table is frozen:
DELETEaffects a document in the current RAM chunk - it is permitted.
DELETEimpacts a document in a disk chunk but was previously deleted - it is allowed.
DELETEwould alter an actual disk chunk - it will wait until the table is unfrozen.
FLUSHing a RAM chunk of a frozen table will report 'success', but no real saving will occur.
TRUNCATE of a frozen table is allowed since these operations are not implicit. We assume that if you truncate or drop a table, you don't need it backed up; therefore, it should not have been frozen initially.
INSERTing into a frozen table is supported but 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 act as if it experienced a dirty shutdown (e.g.,
kill -9): newly inserted data will not be saved in the RAM-chunk on disk, and upon restart, it will be restored from a binary log (if any) or lost (if binary logging is disabled).
UNFREEZE tbl1[, tbl2, ...]
UNFREEZE reactivates previously blocked operations and resumes the internal compaction service. All operations waiting for a table to unfreeze will also be unfrozen and complete normally.
Flushes 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)
Renews 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)