Once tiered storage has been enabled on a service, individual chunks from a hypertable may be tiered to the object storage tier.
Before you start, you need a list of chunks to tier. In this example, you use a hypertable called example, and tier chunks older than three days. Data on the object storage tier cannot be modified - so inserts, updates, and deletes will not work on tiered data. So make sure that you are not tiering data that is being actively modified to the object storage tier
At the psql prompt, select all chunks in the table
examplethat are older than three days:SELECT show_chunks('example', older_than => INTERVAL '3 days');
This returns a list of chunks. Take a note of the chunk names:|1|_timescaledb_internal_hyper_1_2_chunk||2|_timescaledb_internal_hyper_1_3_chunk|
When you are happy with the list of chunks, you can use the
tier_chunk function to manually tier each one.
At the psql prompt, tier the chunk:SELECT tier_chunk( '_timescaledb_internal_hyper_1_2_chunk');
Tiering a chunk is an asynchronous process that schedules the chunk to be tiered.
Repeat for all chunks you want to tier.
Tiering a chunk schedules the chunk for migration to the object storage tier but, won't be tiered immediately. It may take some time tiering to complete. You can continue to query a chunk during migration.
To see which chunks are tiered into the object storage tier, use the
SELECT * FROM timescaledb_osm.tiered_chunks;
Chunks are tiered asynchronously. Chunks are tiered one at a time in order to minimize db resource
consumption during the tiering process. You can see chunks scheduled for tiering (either by the policy or
by a manual call to
tier_chunk) but have not yet been moved to the object storage tier using this view.
SELECT * FROM timescaledb_osm.chunks_queued_for_tiering ;
If you need to untier your data, see the manually untier data section.
Most users don't need to manually tier chunks and instead create a tiering policy to automate when chunks are tiered.
Found an issue on this page?Report an issue!