Задача у меня следующая - сделать дамп одной базы и восстановить его в новой базе.
При попытке сделать бэкап стандартными средствами pg_dump, появляются следующие ошибки
Суть в том, что гиппертаблицы изначально пустые, а данные хранятся в чанках.
Вот пример как посмотреть:
По хорошему, в приложении делать миграции, создавать таким обарзом структуру данных, а данные сохранять и восстанавливать используя sql файл ( pg_dump --data-only)
Но, есть интересная и в целом рабочая утилита https://github.com/timescale/timescaledb-backup
нам потребуются бинарники под linux x86-64
Создаём обязательно чистую базу под восстановление (этой утилитой нельзя "добавлять" данные при наличии какой-либо схемы, даже не требуется выполнение
CREATE EXTENSION IF NOT EXISTS timescaledb; )
То что модуль будет подключен - проверить можно командой \dx timescaledb или указанной командой выше.
ts-dump --db-URI postgresql://userassword@localhost/databasename --dump-dir /home/backup/data
(в dump-dir самой папки data не должно существовать, нужно написать имя той, которая планируется к созданию, в ней будут бэкапы)
и аналогично для восстановления:
ts-restore --db-URI postgresql://userassword@localhost/databasename --dump-dir /home/backup/data
Важно! При создании бэкапа, в папке так же будут файлы roles.sql и tablespaces.sql - это потребуется, если база была только установлена (например на другом сервере и к ней не созданы никакие роли и тейблспейсы. В общем поможет восстановить необходимое. Пользователей в любом случае придётся прописать в файле конфигов для доступов.
Можно добавить параметр --verbose для вывода подробностей и дампе или восстановлении.
P.S. - пишите вопросы если возникли сложности.
При попытке сделать бэкап стандартными средствами pg_dump, появляются следующие ошибки
pg_dump: NOTICE: there are circular foreign-key constraints on this table:
pg_dump: hypertable
pg_dump: You might not be able to restore the dump without using --disable-triggers or temporarily dropping the constraints.
pg_dump: Consider using a full dump instead of a --data-only dump to avoid this problem.
pg_dump: NOTICE: there are circular foreign-key constraints on this table:
pg_dump: chunk
pg_dump: You might not be able to restore the dump without using --disable-triggers or temporarily dropping the constraints.
pg_dump: Consider using a full dump instead of a --data-only dump to avoid this problem.
pg_dump: NOTICE: hypertable data are in the chunks, no data will be copied
DETAIL: Data for hypertables are stored in the chunks of a hypertable so COPY TO of a hypertable will not copy any data.
HINT: Use "COPY (SELECT * FROM <hypertable>) TO ..." to copy all data in hypertable, or copy each chunk individually.
Суть в том, что гиппертаблицы изначально пустые, а данные хранятся в чанках.
Вот пример как посмотреть:
Код:
postgres=# \d+ devices
Table "public.devices"
Column | Type | Collation | Nullable | Default | Storage | Stats target | Description
--------+--------------------------+-----------+----------+---------+---------+--------------+-------------
time | timestamp with time zone | | not null | | plain | |
device | integer | | not null | | plain | |
temp | double precision | | | | plain | |
Indexes:
"devices_pkey" PRIMARY KEY, btree ("time", device)
"devices_device_time_idx" btree (device, "time" DESC)
"devices_time_idx" btree ("time" DESC)
Triggers:
ts_insert_blocker BEFORE INSERT ON devices FOR EACH ROW EXECUTE FUNCTION _timescaledb_internal.insert_blocker()
Child tables: _timescaledb_internal._dist_hyper_1_10_chunk,
_timescaledb_internal._dist_hyper_1_11_chunk,
_timescaledb_internal._dist_hyper_1_12_chunk,
_timescaledb_internal._dist_hyper_1_13_chunk,
_timescaledb_internal._dist_hyper_1_14_chunk,
_timescaledb_internal._dist_hyper_1_15_chunk,
_timescaledb_internal._dist_hyper_1_1_chunk,
_timescaledb_internal._dist_hyper_1_2_chunk,
_timescaledb_internal._dist_hyper_1_3_chunk,
_timescaledb_internal._dist_hyper_1_4_chunk,
_timescaledb_internal._dist_hyper_1_5_chunk,
_timescaledb_internal._dist_hyper_1_6_chunk,
_timescaledb_internal._dist_hyper_1_7_chunk,
_timescaledb_internal._dist_hyper_1_8_chunk,
_timescaledb_internal._dist_hyper_1_9_chunk
По хорошему, в приложении делать миграции, создавать таким обарзом структуру данных, а данные сохранять и восстанавливать используя sql файл ( pg_dump --data-only)
Но, есть интересная и в целом рабочая утилита https://github.com/timescale/timescaledb-backup
нам потребуются бинарники под linux x86-64
- ts-dump_0.1.1_Linux_x86_64 - для бэкапа
- ts-restore_0.1.1_Linux_x86_64 - для восстановления
Создаём обязательно чистую базу под восстановление (этой утилитой нельзя "добавлять" данные при наличии какой-либо схемы, даже не требуется выполнение
CREATE EXTENSION IF NOT EXISTS timescaledb; )
То что модуль будет подключен - проверить можно командой \dx timescaledb или указанной командой выше.
ts-dump --db-URI postgresql://userassword@localhost/databasename --dump-dir /home/backup/data
(в dump-dir самой папки data не должно существовать, нужно написать имя той, которая планируется к созданию, в ней будут бэкапы)
и аналогично для восстановления:
ts-restore --db-URI postgresql://userassword@localhost/databasename --dump-dir /home/backup/data
Важно! При создании бэкапа, в папке так же будут файлы roles.sql и tablespaces.sql - это потребуется, если база была только установлена (например на другом сервере и к ней не созданы никакие роли и тейблспейсы. В общем поможет восстановить необходимое. Пользователей в любом случае придётся прописать в файле конфигов для доступов.
Можно добавить параметр --verbose для вывода подробностей и дампе или восстановлении.
P.S. - пишите вопросы если возникли сложности.