Возникло желание обновить Zabbix до последней версии, но с наскока этого сделать не получилось. В процессе столкнулся необходимостью обновить последовательно несколько систем. Различных мануалов по их обновлению хватает, но при отработке обновления на тестовом стенде, я собирал выдержки из них в отдельную инструкцию, чтобы при обновлении на бою ничего не забыть и не запутаться. Слегка причесанной и дополненной комментариями версией этой инструкции и хочу поделиться.

Исходные данные перед обновлением:

  • CentOS 8

  • Zabbix 5.2.6

  • PostgresSQL 12.6

  • TimescaleDB 2.1.1

  • База данных и Zabbix установлены на одной виртуальной машине

Процесс обновления можно разделить на несколько последовательных шагов:

  1. Обновление ОС

  2. Обновление БД

  3. Обновление Zabbix

  4. Обновление Primary keys в таблицах с историческими данными

Работа выполняется под учетной записью root, если не указано иное (просто чтобы не дописывать sudo к каждой команде).

1. Обновление ОС

Так как Red Hat перестал поддерживать CentOS 8 и отключил репозитории, то было принято решение заменить её на Oracle Linux. Благо делается это очень просто и практически в автоматическом режиме.

На моей инсталляции никаких проблем ни во время обновления, ни после него не возникло.

Перед началом рекомендуется обновить все установленные пакеты до последней доступной версии (при первом прогоне обновления я этот шаг пропустил и ничего страшного не случилось):

# Актуализируем ссылки на репозитории CentOS и обновляем установленные пакеты до последних доступных
sed -i 's/mirrorlist/#mirrorlist/g' /etc/yum.repos.d/CentOS-*
sed -i 's|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' /etc/yum.repos.d/CentOS-*
dnf clean all
dnf update
dnf upgrade

Обновление выполняется с помощью скрипта centos2ol.sh от Oracle. По этой ссылке можно ознакомиться с README.md, где описаны особенности использования. Резервную копию копию я делал снэпшотом виртуальной машины, поэтому нигде не описан процесс создания бэкапов.

Предварительные действия:

  • Проверить наличие и удалить нестандартные ядра (Kernels)

  • Отключить устаревшие и сторонние репозитории

  • Убедиться, что в /var/cache есть 5 Gb свободного места

  • Отключены все автоматические обновления

  • Создать резервную копию

Инструкция по обновлению от Oracle (на английском) где все это подробно описано.

# Получаем список активных репозиториев и отключаем сторонние
dnf repolist
# Хочу обратить внимание на то, что это мой список сторонних реп. У вас он скорее всего будет другой.
dnf config-manager --set-disabled epel epel-modular grafana pgdg-common pgdg12 pgdg13 timescale_timescaledb zabbix zabbix-non-supported
# Осталось скачать скрипт, сделать исполняемым и запустить
wget https://raw.githubusercontent.com/oracle/centos2ol/main/centos2ol.sh
chmod +x centos2ol.sh
./centos2ol.sh

После обновления рекомендуется перезагрузить систему:

Switch complete.
Oracle recommends rebooting this system.
[root@zabbix ~]# reboot

2. Обновление БД

Начиная с 6 версии Zabbix требует PostgreSQL 13 или старше. Я принял решение ставить последнюю стабильную на данный момент версию 14.

Так как на текущей PostgreSQL 12.6 установлена TimescaleDB 2.1.1, а для PostgreSQL 14 требуется версия 2.5+, то нужно сначала обновить её. Благодаря тому, что TimescaleDB 2.7 (последняя доступная на текущий момент) поддерживает PostgreSQL 12, обновляться можно напрямую. В противном случае пришлось бы обновляться через промежуточную версию PostgreSQL.

su - postgres
# подключаемся к базе данных zabbix
psql zabbix
# получаем список установленных расширений БД и их версий
zabbix=# \dx
                                      List of installed extensions
    Name     | Version |   Schema   |                            Description
-------------+---------+------------+-------------------------------------------------------------------
 plpgsql     | 1.0     | pg_catalog | PL/pgSQL procedural language
 timescaledb | 2.1.1   | public     | Enables scalable inserts and complex queries for time-series data
(2 rows)
zabbix=# \q
exit

Нужно обновить репозиторий PostgreSQL:

# Обновляем репозиторий PostgreSQL
rpm -Uvh https://download.postgresql.org/pub/repos/yum/reporpms/EL-8-x86_64/pgdg-redhat-repo-latest.noarch.rpm
# Отключаем лишнее
dnf config-manager --set-disabled pgdg10 pgdg11 pgdg13 
# Включаем нужное
dnf config-manager --set-enabled timescale_timescaledb

Ну а дальше уже обновляем TimescaleDB:

# Обновляем пакет
dnf upgrade -y timescaledb-2-postgresql-12
su - postgres
psql zabbix
# Обновляем непосредственно расширение в БД
ALTER EXTENSION timescaledb UPDATE;
# Проверяем, версия обновилась до 2.7.0
\dx
                                      List of installed extensions
    Name     | Version |   Schema   |                            Description
-------------+---------+------------+-------------------------------------------------------------------
 plpgsql     | 1.0     | pg_catalog | PL/pgSQL procedural language
 timescaledb | 2.7.0   | public     | Enables scalable inserts and complex queries for time-series data
(2 rows)

\q

Теперь можно обновить сам PostgreSQL. Тут процесс заключается в установке новой версии и миграции в неё базы. Я сделал это с помощью утилиты pg_upgrade, хотя есть и другие способы.

# Устанавливаем PostgeSQL 14 и TimescaleDB для неё
dnf install -y postgresql14-server timescaledb-2-postgresql-14
# Инициализируем базу
postgresql-14-setup initdb
# С помощью утилиты timescaledb-tune меняем некоторые настройки в файле postgresql.conf:
timescaledb-tune --pg-config=/usr/pgsql-14/bin/pg_config
# Так же в этом файле поменяем порт на отличный от используемого предыдущей версией
# port = 5532 (по умолчанию port = 5432)
vim /var/lib/pgsql/14/data/postgresql.conf
# Добавляем сервис
systemctl enable postgresql-14
# Стоит сравнить файлы конфигураций и подправить необходимые вам настройки
diff /var/lib/pgsql/12/data/pg_hba.conf /var/lib/pgsql/14/data/pg_hba.conf

В файле pg_hba.conf у postgresql 14 по умолчанию прописано шифрование паролей scram-sha-256 (вместо md5 у предыдущих версий). По-хорошему нужно обновить пароли (точнее способ их хэширования) на SCRAM (вот достаточно подробная инструкция на английском), но можно просто поменять обратно на md5.

Я проделывал эту процедуру на уже обновленной базе. Но, думаю, стоит сделать заранее.

Обновление до SCRAM

Для того, чтобы обновить пароли до SCRAM нужно убедиться в 2 вещах:

  1. Используется PostgreSQL 10 или выше.

  2. Драйвера, используемые для подключения к БД поддерживают SCRAM.

Само обновление проходит так:

  1. В файле postgresql.conf установить параметр password_encryption в scram-sha-256.

  2. Определиться с учетными записями, которым нужно обновить пароли. У меня это пользователь zabbix.

  3. Перехешировать пароли, по сути просто ввести новый (естественно, никто не мешает ввести текущий) пароль с помощью команды \password в psql.

  4. Заменить md5 в файле pg_hba.conf на scram-sha-256.

# Установить password_encryption = scram-sha-256
vim /var/lib/pgsql/14/data/postgresql.conf
# Перезагрузить конфигурацию PostgreSQL
service postgresql-14 reload
# Под пользователем postgres запустить psql
su - postgres
psql
# Выбрать учетные записи, которым требуется обновление
SELECT
    rolname, rolpassword ~ '^SCRAM-SHA-256\$' AS has_upgraded
FROM pg_authid
WHERE rolcanlogin;
# У меня такой результат:
 rolname  | has_upgraded
----------+--------------
 postgres | t
 zabbix   | f
(2 rows)
# Если в выборке у пользователя параметр has_upgraded установлен в false (f), то ему требуется перехешировать пароль.
# Вводим пароль для пользователя zabbix
\password zabbix
# Проверяем что для всех пользователей возвращается TRUE (t)
SELECT rolname, rolpassword ~ '^SCRAM-SHA-256\$' AS has_upgraded FROM pg_authid WHERE rolcanlogin;
# Теперь у всех true
 rolname  | has_upgraded
----------+--------------
 postgres | t
 zabbix   | t
(2 rows)
# Выход из psql
\q
# Осталось заменить md5 в файле pg_hba.conf на scram-sha-256
vim /var/lib/pgsql/14/data/pg_hba.conf
# Возвращаемся в УЗ root
exit
# И еще раз перезагрузить конфигурацию PostgreSQL
service postgresql-14 reload

# Теперь убедимся, что кластер готов к обновлению.
# Для этого запускаем pg_upgrade с ключом --check. При этом никакие изменения не происходят.
sudo -iu postgres /usr/pgsql-14/bin/pg_upgrade \
  --old-datadir=/var/lib/pgsql/12/data \
  --new-datadir=/var/lib/pgsql/14/data \
  --old-bindir=/usr/pgsql-12/bin \
  --new-bindir=/usr/pgsql-14/bin \
  --old-options '-c config_file=/var/lib/pgsql/12/data/postgresql.conf' \
  --new-options '-c config_file=/var/lib/pgsql/14/data/postgresql.conf' \
  --check
  
# Получаем примерно такой результат выполнения:
Performing Consistency Checks on Old Live Server
------------------------------------------------
Checking cluster versions                                   ok
Checking database user is the install user                  ok
Checking database connection settings                       ok
Checking for prepared transactions                          ok
Checking for system-defined composite types in user tables  ok
Checking for reg* data types in user tables                 ok
Checking for contrib/isn with bigint-passing mismatch       ok
Checking for user-defined encoding conversions              ok
Checking for user-defined postfix operators                 ok
Checking for presence of required libraries                 ok
Checking database user is the install user                  ok
Checking for prepared transactions                          ok
Checking for new cluster tablespace directories             ok

*Clusters are compatible*
# Ошибок нет, всё готово к обновлению.

Перед запуском миграции нужно убедиться, что оба (старый и новый) сервиса PostgeSQL остановлены. Да и Zabbix тоже можно остановить.

service postgresql-12 stop
service postgresql-14 stop
service zabbix-server stop
service zabbix-agent2 stop
# Запускаем миграцию данных
sudo -iu postgres /usr/pgsql-14/bin/pg_upgrade \
  --old-datadir=/var/lib/pgsql/12/data \
  --new-datadir=/var/lib/pgsql/14/data \
  --old-bindir=/usr/pgsql-12/bin \
  --new-bindir=/usr/pgsql-14/bin \
  --old-options '-c config_file=/var/lib/pgsql/12/data/postgresql.conf' \
  --new-options '-c config_file=/var/lib/pgsql/14/data/postgresql.conf'
# Если все завершилось без ошибок, то меняем используемые порты в старой и новой версии
# port = 5432
vim /var/lib/pgsql/14/data/postgresql.conf
# port = 5532
vim /var/lib/pgsql/12/data/postgresql.conf
# Запускаем сервисы и проверяем работоспособность Zabbix
service postgresql-14 start
service zabbix-server start
service zabbix-agent2 start
# Можно выполнить анализ базы и сбор статистики:
sudo -iu postgres /usr/pgsql-14/bin/vacuumdb --all --analyze-in-stages
# Если все впорядке, можно удалить данные старой БД:
/var/lib/pgsql/delete_old_cluster.sh
# При желании можно удалить и сам PostgreSQL 12
dnf remove postgresql12-server-12.11-1PGDG.rhel8.x86_64 postgresql12-libs-12.11-1PGDG.rhel8.x86_64

Вот теперь, наконец-то, можно обновлять сам Zabbix.

3. Обновление Zabbix

Сам Zabbix обновляется достаточно просто, если инсталляция не сильно большая.

Стоит учитывать, что Zabbix и Zabbix Proxy должны быть одной мажорной версии, в противном случае Zabbix не примет с него данные. Так что нет смысла оставлять прокси работать, пока обновляется сервер. Прокси нужно обновлять параллельно с сервером.

Ну и в зависимости от размера БД ее обновление до 6 версии может занять значительное время.

Перед обновлением стоит ещё раз сделать резервные копии базы и конфигурационных файлов. Ну или сделать снэпшот.

# Останавливаем zabbix-server
service zabbix-server stop
# Обновляем репозиторий заббикса:
rpm -Uvh https://repo.zabbix.com/zabbix/6.0/rhel/8/x86_64/zabbix-release-6.0-1.el8.noarch.rpm
# Очищаем и пересоздаем кэш (хотя это можно и не делать):
dnf clean all
dnf makecache
# Проверим список установленных пакетов zabbix в системе
rpm -qa | grep zabbix
# У меня такой список получился:
zabbix-release-6.0-1.el8.noarch
zabbix-get-5.2.7-1.el8.x86_64
zabbix-nginx-conf-5.2.6-1.el8.noarch
zabbix-web-deps-5.2.6-1.el8.noarch
zabbix-web-pgsql-5.2.6-1.el8.noarch
zabbix-agent2-5.2.5-1.el7.x86_64
zabbix-web-5.2.6-1.el8.noarch
zabbix-server-pgsql-5.2.6-1.el8.x86_64
zabbix-java-gateway-5.2.6-1.el8.x86_64
# Устанавливаем обновление zabbix на сервер, выбирая установленные у вас пакеты:
dnf upgrade zabbix-web zabbix-web-pgsql zabbix-server-pgsql zabbix-agent2 zabbix-get zabbix-server zabbix-java-gateway
# Запускаем zabbix-server и ждём пока обновится формат базы
service zabbix-server start

4. Обновление Primary keys

Сразу оставлю ссылку на раздел в документации Zabbix, там этот шаг достаточно подробно и понятно изложен.

Основное, что надо знать:

  • Не забудьте сделать бэкап базы

  • Zabbix не должен быть запущен во время обновления

  • CSV файлы с данными занимают очень много места

  • На Zabbix Proxy для обновления достаточно выполнить скрипт history_pk_prepare.sql

 # Установить пакет “zabbix-sql-scripts”:
dnf install -y zabbix-sql-scripts
# Остановить Zabbix:
service zabbix-server stop
# Выполням скрипт history_pk_prepare.sql на базе zabbix от пользователя zabbix.
# Этот скрипт переименует старые таблицы с историей и создаст новые.
sudo -u zabbix psql zabbix < /usr/share/doc/zabbix-sql-scripts/postgresql/history_pk_prepare.sql

Дальнейшие действия зависят от того, нужно переносить исторические данные или нет. Если нет, тогда обновление завершено. Нужно удалить старые таблицы и запустить заббикс.

Если же данные надо сохранить, то их нужно выгрузить из старой таблицы, создать временную таблицу и загрузить данные в неё, вставить данные из временной таблицы в постоянную. И так 5 раз (по числу таблиц с историческими данными).

Для TimescaleDB в официальной документации Zabbix приведён пример обновления одной таблицы.

# Под пользователем postgres запускаем psql
su - postgres
psql
# Далее выполняем нижеприведенный код
history.sql
 -- Посмотрим, сколько места на диске займут несжатые данные после выгузки в CSV.
select sum(before_compression_total_bytes)/1024/1024 as before_compression_total_mbytes, sum(after_compression_total_bytes)/1024/1024 as after_compression_total_mbytes FROM chunk_compression_stats('history_old');

-- Выгрузить данные в файл
\copy (select * from history_old) TO '/tmp/history.csv' DELIMITER ',' CSV

CREATE TEMP TABLE temp_history (
    itemid     bigint NOT NULL,
    clock      integer  DEFAULT '0' NOT NULL,
    value      DOUBLE PRECISION DEFAULT '0.0000'   NOT NULL,
    ns  integer  DEFAULT '0' NOT NULL
);
-- Загрузить данные из файла
\copy temp_history FROM '/tmp/history.csv' DELIMITER ',' CSV

-- Создадим hypertable и заполним её данными
select create_hypertable('history', 'clock', chunk_time_interval => 86400, migrate_data => true);
INSERT INTO history SELECT * FROM temp_history ON CONFLICT (itemid,clock,ns) DO NOTHING;

-- Включаем сжатие
select set_integer_now_func('history', 'zbx_ts_unix_now', true);
alter table history set (timescaledb.compress,timescaledb.compress_segmentby='itemid',timescaledb.compress_orderby='clock,ns');

-- В hypertable_schema стоит заменить public на свою схему, если она отличается
-- Возвращенный ID задачи (<JOB_ID>) нужно будет подставить в run_job
select add_compression_policy('history', (
    select extract(epoch from (config::json->>'compress_after')::interval) from timescaledb_information.jobs where application_name like 'Compression%%' and hypertable_schema='public' and hypertable_name='history_old'
    )::integer
);

select alter_job((select job_id from timescaledb_information.jobs where hypertable_schema='public' and hypertable_name='history'), scheduled => true);

-- Запустить задачу сжатия данных (вместо <JOB_ID> нужно поставить ID задачи из предыдущего шага)
call run_job(<JOB_ID>);
-- Может появиться уведомление 'NOTICE:  no chunks for hypertable public.history_uint that satisfy compress chunk policy', это нормально.

history_uint.sql
 -- Verify that there is enough space to allow export of uncompressed data
select sum(before_compression_total_bytes)/1024/1024 as before_compression_total_mbytes, sum(after_compression_total_bytes)/1024/1024 as after_compression_total_mbytes FROM chunk_compression_stats('history_uint_old');

-- Export data
\copy (select * from history_uint_old) TO '/tmp/history_uint.csv' DELIMITER ',' CSV

CREATE TEMP TABLE temp_history_uint (
    itemid     bigint NOT NULL,
    clock      integer  DEFAULT '0' NOT NULL,
    value      numeric(20)     DEFAULT '0' NOT NULL,
    ns  integer  DEFAULT '0' NOT NULL
);
-- Import data
\copy temp_history_uint FROM '/tmp/history_uint.csv' DELIMITER ',' CSV

-- Create hypertable and populate it
select create_hypertable('history_uint', 'clock', chunk_time_interval => 86400, migrate_data => true);
INSERT INTO history_uint SELECT * FROM temp_history_uint ON CONFLICT (itemid,clock,ns) DO NOTHING;

-- Enable compression
select set_integer_now_func('history_uint', 'zbx_ts_unix_now', true);
alter table history_uint set (timescaledb.compress,timescaledb.compress_segmentby='itemid',timescaledb.compress_orderby='clock,ns');

-- Substitute your schema in hypertable_schema
-- Job id will returned, it should be passed to run_job
select add_compression_policy('history_uint', (
    select extract(epoch from (config::json->>'compress_after')::interval) from timescaledb_information.jobs where application_name like 'Compression%%' and hypertable_schema='public' and hypertable_name='history_uint_old'
    )::integer
);

select alter_job((select job_id from timescaledb_information.jobs where hypertable_schema='public' and hypertable_name='history_uint'), scheduled => true);

-- Run compression job
call run_job(<JOB_ID>);
-- May show 'NOTICE:  no chunks for hypertable public.history_uint that satisfy compress chunk policy', it is fine.

history_str.sql
 -- Verify that there is enough space to allow export of uncompressed data
select sum(before_compression_total_bytes)/1024/1024 as before_compression_total_mbytes, sum(after_compression_total_bytes)/1024/1024 as after_compression_total_mbytes FROM chunk_compression_stats('history_str_old');

-- Export data
\copy (select * from history_str_old) TO '/tmp/history_str.csv' DELIMITER ',' CSV

CREATE TEMP TABLE temp_history_str (
    itemid     bigint NOT NULL,
    clock      integer  DEFAULT '0' NOT NULL,
    value      varchar(255)    DEFAULT ''  NOT NULL,
    ns  integer  DEFAULT '0' NOT NULL
);
-- Import data
\copy temp_history_str FROM '/tmp/history_str.csv' DELIMITER ',' CSV

-- Create hypertable and populate it
select create_hypertable('history_str', 'clock', chunk_time_interval => 86400, migrate_data => true);
INSERT INTO history_str SELECT * FROM temp_history_str ON CONFLICT (itemid,clock,ns) DO NOTHING;

-- Enable compression
select set_integer_now_func('history_str', 'zbx_ts_unix_now', true);
alter table history_str set (timescaledb.compress,timescaledb.compress_segmentby='itemid',timescaledb.compress_orderby='clock,ns');

-- Substitute your schema in hypertable_schema
-- Job id will returned, it should be passed to run_job
select add_compression_policy('history_str', (
    select extract(epoch from (config::json->>'compress_after')::interval) from timescaledb_information.jobs where application_name like 'Compression%%' and hypertable_schema='public' and hypertable_name='history_str_old'
    )::integer
);

select alter_job((select job_id from timescaledb_information.jobs where hypertable_schema='public' and hypertable_name='history_str'), scheduled => true);

-- Run compression job
call run_job(<JOB_ID>);
-- May show 'NOTICE:  no chunks for hypertable public.history_uint that satisfy compress chunk policy', it is fine.

history_log.sql
-- Verify that there is enough space to allow export of uncompressed data
select sum(before_compression_total_bytes)/1024/1024 as before_compression_total_mbytes, sum(after_compression_total_bytes)/1024/1024 as after_compression_total_mbytes FROM chunk_compression_stats('history_log_old');

-- Export data
\copy (select * from history_log_old) TO '/tmp/history_log.csv' DELIMITER ',' CSV

CREATE TEMP TABLE temp_history_log (
    itemid     bigint NOT NULL,
    clock      integer  DEFAULT '0' NOT NULL,
    timestamp  integer  DEFAULT '0' NOT NULL,
    source     varchar(64)     DEFAULT ''  NOT NULL,
    severity   integer  DEFAULT '0' NOT NULL,
    value      text     DEFAULT ''  NOT NULL,
    logeventid integer  DEFAULT '0' NOT NULL,
    ns  integer  DEFAULT '0' NOT NULL
);
-- Import data
\copy temp_history_log FROM '/tmp/history_log.csv' DELIMITER ',' CSV

-- Create hypertable and populate it
select create_hypertable('history_log', 'clock', chunk_time_interval => 86400, migrate_data => true);
INSERT INTO history_log SELECT * FROM temp_history_log ON CONFLICT (itemid,clock,ns) DO NOTHING;

-- Enable compression
select set_integer_now_func('history_log', 'zbx_ts_unix_now', true);
alter table history_log set (timescaledb.compress,timescaledb.compress_segmentby='itemid',timescaledb.compress_orderby='clock,ns');

-- Substitute your schema in hypertable_schema
-- Job id will returned, it should be passed to run_job
select add_compression_policy('history_log', (
    select extract(epoch from (config::json->>'compress_after')::interval) from timescaledb_information.jobs where application_name like 'Compression%%' and hypertable_schema='public' and hypertable_name='history_log_old'
    )::integer
);

select alter_job((select job_id from timescaledb_information.jobs where hypertable_schema='public' and hypertable_name='history_log'), scheduled => true);

-- Run compression job
call run_job(<JOB_ID>);
-- May show 'NOTICE:  no chunks for hypertable public.history_uint that satisfy compress chunk policy', it is fine. 

history_text.sql
 -- Verify that there is enough space to allow export of uncompressed data
select sum(before_compression_total_bytes)/1024/1024 as before_compression_total_mbytes, sum(after_compression_total_bytes)/1024/1024 as after_compression_total_mbytes FROM chunk_compression_stats('history_text_old');

-- Export data
\copy (select * from history_text_old) TO '/tmp/history_text.csv' DELIMITER ',' CSV

CREATE TEMP TABLE temp_history_text (
    itemid     bigint NOT NULL,
    clock      integer  DEFAULT '0' NOT NULL,
    value      text     DEFAULT ''  NOT NULL,
    ns  integer  DEFAULT '0' NOT NULL
);
-- Import data
\copy temp_history_text FROM '/tmp/history_text.csv' DELIMITER ',' CSV

-- Create hypertable and populate it
select create_hypertable('history_text', 'clock', chunk_time_interval => 86400, migrate_data => true);
INSERT INTO history_text SELECT * FROM temp_history_text ON CONFLICT (itemid,clock,ns) DO NOTHING;

-- Enable compression
select set_integer_now_func('history_text', 'zbx_ts_unix_now', true);
alter table history_text set (timescaledb.compress,timescaledb.compress_segmentby='itemid',timescaledb.compress_orderby='clock,ns');

-- Substitute your schema in hypertable_schema
-- Job id will returned, it should be passed to run_job
select add_compression_policy('history_text', (
    select extract(epoch from (config::json->>'compress_after')::interval) from timescaledb_information.jobs where application_name like 'Compression%%' and hypertable_schema='public' and hypertable_name='history_text_old'
    )::integer
);

select alter_job((select job_id from timescaledb_information.jobs where hypertable_schema='public' and hypertable_name='history_text'), scheduled => true);

-- Run compression job
call run_job(<JOB_ID>);
-- May show 'NOTICE:  no chunks for hypertable public.history_uint that satisfy compress chunk policy', it is fine.

Ну и последним шагом удаляем старые таблицы:

DROP TABLE history_old;
DROP TABLE history_uint_old;
DROP TABLE history_str_old;
DROP TABLE history_log_old;
DROP TABLE history_text_old;
\q

Вышеприведенные sql скрипты удобнее сохранить в файлы (без последней команды call run_job) и вызывать отдельно. А call run_job(<JOB_ID>); уже запускать после выполнения скрипта.

Примерно так:
touch history_text.sql
vi history_text.sql
sudo -u zabbix psql zabbix < /tmp/history_text.sql
# Дальше вывод работы скрипта
 before_compression_total_mbytes | after_compression_total_mbytes
---------------------------------+--------------------------------
            292.0625000000000000 |            70.7031250000000000
(1 row)

COPY 1359548
CREATE TABLE
COPY 1359548
     create_hypertable
----------------------------
 (15,public,history_text,t)
(1 row)

INSERT 0 1359548
 set_integer_now_func
----------------------

(1 row)

ALTER TABLE
 add_compression_policy
------------------------
                   1007
(1 row)

                                               alter_job
-------------------------------------------------------------------------------------------------------
 (1007,"1 day",00:00:00,-1,01:00:00,t,"{""hypertable_id"": 15, ""compress_after"": 612000}",-infinity)
(1 row)

# Вызываем run_job с Job ID = 1007
echo "call run_job(1007);" |sudo -u zabbix psql zabbix
CALL

Остаётся запустить Zabbix:

service zabbix-server start

Собственно всё, на этом моя сборная солянка из инструкций заканчивается. Надеюсь, что это будет кому-нибудь полезно.

Комментарии (1)


  1. Sin2x
    19.06.2022 21:02

    То, что в проде изначально была x.2, это не очень хорошо, рекомендуется LTS -- x.0

    По поводу 14 постгреса важная новость: https://www.opennet.ru/opennews/art.shtml?num=57367