Почему не удалось перенести базу zabbix?

базу-то пересоздали перед второй попыткой импорта?

ALTER DATABASE zabbix_two OWNER TO zabbix_user2;

не вы первый для кого это неожиданно, но owner базы даёт права только на саму базу. То есть CREATE (создание новых схем, публикаций, trusted extensions (замечу, даже не create table, оно в грантах уровня schema)), CONNECT (возможность подключиться к этой базе), TEMPORARY (возможность сделать create temp table) но ничего сверх этого. Никаких рекурсивно выданных прав на объекты внутри этой базы.

а как то можно сменить владельца таблиц разом?

написать запрос, который сформирует список (внимательно не зацепить системный каталог) alter table .. owner .. и выполнить полученные alter'ы. Плюс аналогично сиквенсы и что ещё было.
для обычных дел есть reassign owned, но оно будет плохой идеей для смены владельца с суперпользователя на обычную учётку. Зацепит много лишнего и возможно даже с фейерверками

Как забрать с раздела 500ГБ и передать их другому разделу?

Adamos, не я администратор этого сервера, не могу угадывать задачи и вероятные потребности. Но два соображения есть сразу:

1. centos 7 емнип делает lvm по-умолчанию - то есть об этом могли не думать вовсе
   
2. это виртуалка, поэтому возможно предполагалось иметь возможность дальнейшего расширения места методом добавления новых виртуальных дисков, что легко решается через lvm
   

Как забрать с раздела 500ГБ и передать их другому разделу?

Adamos, lvm как раз-таки не новомодная умная прослойка, а очень древняя и тупая. И никаких взмахов мышей не подразумевает. Примерно как назвать 800.COM флопиком, который можно будет прочитать на любом компьютере.
Ну, если работать с linux так же часто как я с виндами (то есть только на картинках), то да.

Кластер postgres не инициализирует настройки?

Напишу прямо: бесполезно искать или пытаться менять любым способом max_locks_per_transaction в конфигурации самого postgresql. Все вопросы только к patroni. patroni намеренно передаёт часть настроек напрямую аргументами бинарнику базы при запуске. Это высший приоритет и ничем в конфигурации базы не переопределить.
Как менять эти 6 параметров найдите в документации patroni и только в его документации, потому что это сделано и задокументировано в patroni именно так намеренно.

Как забрать с раздела 500ГБ и передать их другому разделу?

файловая система-то какая?

Как забрать с раздела 500ГБ и передать их другому разделу?

если файловые системы какие-то отличные от ext4, то использовать вместо resize2fs подходящий инструмент.
PS: если xfs - то проблема, он уменьшаться не умеет вообще

Как забрать с раздела 500ГБ и передать их другому разделу?

У него сначала идет акцептор, потом своп, и под конец - донор.

и полностью не имеет значения потому что это один lvm том.

Как pgbouncer обрабатывает idle сесии?

PDO::ATTR_EMULATE_PREPARES => true + pgbouncer

если у вас на базе не 50к tps, то вы на самом деле не хотите ввязываться в это граблехранилище. Если у вас больше - то... Что ж, вы тем более не хотите связываться без поддержки DBA.

Как объеденить данные с двух запросов между собой, если их ничего не объеденяет?

Не понял, в чём вопрос-то? Надо за вас догадаться, какие данные вам всё-таки нужны?

Почему постоянно срабатывает OOM при работе бота на сервере?

Maksim Ivanov, прочитайте остальную часть комментария. 25% ram это точно не про ваш случай

Почему постоянно срабатывает OOM при работе бота на сервере?

для микросервера на 512мб ram, ещё и совмещённого с приложением (непонятно сколько памяти потребляющим) дефолтных 128мб shared_buffers явно слишком много. Рекомендация выдавать под shared_buffers 25% ram - это про выделенные сервера именно под базу и при хотя бы 8гб ram.

Можно ли всем строковым полям задавать тип TEXT и повлияет ли это сильно на производительность?

Для postgresql ничего сакрального в varchar(255) нет. Одна и та же строка длиной 200 символов будет занимать одинаково места будь то поле varchar(220), varchar(255), varchar(300) или text.

Если интересно закопаться в детали, то строка длиной до 126 байт (здесь именно байт, а не символов) хранится с коротким однобайтовым заголовком. Но этот короткий заголовок применяется исходя из фактической длины данных, независимо от того, как объявлена колонка.

И часто замечаю лимиты количество символов для сообщений

Ограничения могут быть как обоснованные реализацией, так и просто взятыми с потолками (тот же самый якобы дефолтный varchar(255) в головах многих разработчиков)
Заголовок сообщения, наверное, не должен быть гигабайтного размера. Но каким объёмом ограничиться? Обычно это и есть какое-то взятое с потолка значение.

Можно ли всем строковым полям задавать тип TEXT и повлияет ли это сильно на производительность?

оу, не смешите публику, если не знаете, кто такой Tom Lane в IT и для postgresql в особенности.

char отличное решение там, где он действительно нужен, где строго определено кол-во символов. но если у вас не высоконагруженное решение, и лишний байт на каждое поле не проблема, то можно всегда использовать varchar.

какой такой байт? Нет ни одного сценария, где char(n) займёт хотя бы на один байт меньше, чем varchar(n)

Как настроить слоты репликации в patroni для сохранения неограниченного кол-ва WAL при отключении реплики?

ну если patroni удаляет неактивный слот (я не помню так ли это) - то чем тут max_slot_wal_keep_size может помочь... Конечно не нужно учитывать слоты которые администратор удалил.

по второму скрину впрочем видно, что слот сохранён и wal'ы он удерживает как положено. Почему отстаёт реплика надо поинтересоваться у реплики, в первую очередь в логах

Как настроить слоты репликации в patroni для сохранения неограниченного кол-ва WAL при отключении реплики?

покажите show max_slot_wal_keep_size; что по этому поводу думает сама база

По какому принципу работает набор индексов в одной таблице?

Сначала потребность (конкретные критерии, какие данные нужно искать достаточно часто и/или нужно искать быстро чтобы оправдать существование индекса) - потом индексы для решения этой потребности. Не наоборот.

Иметь одновременно btree(a), btree(b), btree(c) и btree(a,b,c) смысла нет. Среди них btree(a) будет избыточен. Одновременное существование btree(b), btree(c) и btree(a,b,c) может быть целесообразным.

По какому принципу работает набор индексов в одной таблице?

Индекс btree(a,b,c) и три индекса btree(a), btree(b), btree(c) - разные вещи

универсального индекса нет. Любой индекс - частная потребность конкретной задачи поиска данных.

По какому принципу работает набор индексов в одной таблице?

Индекс может быть вообще не отсортирован никак. Например, hash. Если говорить именно о btree - тогда да, это отсортированная структура данных.
Планировщик анализирует не только where, а много чего. И много чего ещё, напротив, не анализирует, чтобы не тратить слишком много времени на создание возможных и выбор единственного плана выполнения.

btree(name, brand, price) может использоваться для поиска по условию name="user" так же как и btree(name). А вот btree(prand, name, price) уже эффективно использоваться не может.

Как оптимизировать вложенный запрос?

в mysql вроде появились lateral: https://dev.mysql.com/doc/refman/8.0/en/lateral-de...
если ваша версия субд позволяет, то должно помочь

Как в локализации указать в качестве ключа строку?

попробуйте хотя бы имеющий смысла с точки зрения синтаксиса вариант 'person.' . $credit->occupation->name