Возникло желание обновить Zabbix до последней версии, но с наскока этого сделать не получилось. В процессе столкнулся необходимостью обновить последовательно несколько систем. Различных мануалов по их обновлению хватает, но при отработке обновления на тестовом стенде, я собирал выдержки из них в отдельную инструкцию, чтобы при обновлении на бою ничего не забыть и не запутаться. Слегка причесанной и дополненной комментариями версией этой инструкции и хочу поделиться.
Исходные данные перед обновлением:
CentOS 8
Zabbix 5.2.6
PostgresSQL 12.6
База данных и Zabbix установлены на одной виртуальной машине
Процесс обновления можно разделить на несколько последовательных шагов:
Обновление ОС
Обновление БД
Обновление Zabbix
Обновление 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 вещах:
Используется PostgreSQL 10 или выше.
Драйвера, используемые для подключения к БД поддерживают SCRAM.
Само обновление проходит так:
В файле postgresql.conf установить параметр password_encryption в scram-sha-256.
Определиться с учетными записями, которым нужно обновить пароли. У меня это пользователь zabbix.
Перехешировать пароли, по сути просто ввести новый (естественно, никто не мешает ввести текущий) пароль с помощью команды \password в psql.
Заменить 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
Собственно всё, на этом моя сборная солянка из инструкций заканчивается. Надеюсь, что это будет кому-нибудь полезно.
Sin2x
То, что в проде изначально была x.2, это не очень хорошо, рекомендуется LTS -- x.0
По поводу 14 постгреса важная новость: https://www.opennet.ru/opennews/art.shtml?num=57367