Melkij

скопировать с мастера папку pg_wal с файлами

Если бы нужный сегмент на primary был - его бы уже давно отдали реплике по запросу walreceiver'а. Значит его там нет.
Если у вас на какой-то из реплик все необходимые wal всё же есть - да, их можно подложить в pg_wal. База их в своём обычном цикле опроса источников wal увидит. Или переключить primary_conninfo на эту реплику, сама заберёт.

Которая в свою очередь лочит базу

basebackup не блокирует базу. Это вообще весьма простая и глупая по своей сути штука.

Чтобы реплика при отсутствии необходимых WAL догнала primary - вам нужно знание внутренностей PGDATA. Которого у вас нет, что очевидно по вопросу "не станет ли слейв после этого мастером ?". А потому единственным простым и надёжным способом будет сделать pg_basebackup заново.

в постгрес есть автоматическое переключение мастеров

Нет такого.
Только внешние управляющие (patroni, например). Ну или в форках каких-нибудь, но это вопрос к этим форкам, а не к postgresql.

Как посмотреть дампы базы, если они делались?

Выяснить:
- делались ли вообще
- как именно делались
- куда сохранялись
Восстановить данные используя ответы на предыдущие пункты.

Как правильно вернуть значения в таблицу?

Достать из бекапа

как правильно обеспечить надежность и безотказность ее работы?

Использовать адекватное железо и не мешать базе работать шаловливыми ручками.

доступен 24 часа 7 дней в неделю.

бекап

Объясните, пожалуйста, как это по вашему мнению между собой связано?
Бекапы необходимы, но как они связаны с высокой доступностью?

в случае проблем с доступностью, перезапускать/запускать саму СУБД.

Простой вопрос: зачем?
Если база сложилась и даже не смогла подняться самостоятельно - значит проблема капительная и разбираться надо детально. Рестартом по кругу вы можете скорее сделать совсем плохо, чем что-либо починить.
При том обычно проблемы начинаются от того что разработчики выкатили новую версию приложения и та начинает делать что-то странное. Например, забыли сделать индекс на 50гб табличку и засунули запрос с поиском по ней на главную сайта. Рестартом базы это, разумеется, не исправляется. А делает только больнее.

Многолетней давности pg_postmaster_start_time() впечатлять не буду - мы периодически ставим минорные апдейты на свои базы. И вам тоже весьма рекомендую обновиться до 10.7 или лучше уже на следующих выходных сразу до 10.8.

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

какие операции, запросы или их комбинации нежелательны для БД и могут привести к проблемам.

Большая часть инцидентов с недоступностью сервиса с точки зрения приложения - про уровни блокировок. Кто-нибудь попробует сделать create index вместо create index concurrently и привет ожидание блокировки на всю запись в таблицу. Большинство форм alter table сюда же, но они и чтение заблокируют.

Как человек в этом году неожиданно сменивший деятельность с senior php dev на DBA - хочу задать встречный вопрос:
а вы вообще видите вакансии на начинающего-студента-DBA? Целую одну или хотя бы даже две? Для увидевшего SQL вот только что студента и уже желающего быть DBA всего через пару месяцев? Человека, который даже не написал, какую именно СУБД ему интересно изучать до уровня DBA?

Отдельная позиция DBA в проекте - значит ни штатные системные администраторы (со стороны администрирования) ни старшие разработчики (со знанием SQL) уже не обладают достаточными познаниями в используемой СУБД. Но эта БД важна для бизнеса и ищется специалист по ней, который будет обеспечивать хорошую работу этой базы.
Несколько позиций DBA в кампании чтобы брать стажера - это очень большой проект. Эти могут себе позволить отвлекать своих специалистов от работы и вкладывать деньги в выращивание нового специалиста. Если вы чем-то сильно заинтересуете кампанию.

Я не знаю как стать DBA с нуля. Похоже DBA становятся только имея за плечами заметный опыт администрирования или разработки.

Определитесь с конкретной СУБД и прочитайте полностью её мануал. Например мануал postgresql 10 в pdf занимает свыше 3 тысяч страниц A4. На пару месяцев этого уже хватит. А это только мануал. Только по непосредственно СУБД.
Плюс необходимо знать базовое администрирование той ОС под которой эта СУБД используется (например, я как postgresql dba даже близко не представляю что делать с windows - такая экзотика в жизни не встречается. А вот для MS SQL наверняка необязательно разбираться в linux).
Плюс теория: реляционная логика, обеспечение транзакционного, конкурентного доступа, восстановление после сбоев
Плюс практика - активность в профильных сообществах, форумах. Читаете, проверяете, запоминаете, вежливо переспрашиваете в комментариях если вам кажется что предыдущий отвечающий ошибся, отвечаете на вопросы.

Интересно? Вперёд. Но в DBA за 3 месяца из нулевого студента - не верю.

sudo rm -rf /var/lib/postgresql

Это был home dir пользователя, а не каталог кластера. Каталог кластера в дефолтной поставке в /var/lib/postgresql/версия_pg/ещё_одна_директория_main_или_base

sudo mkdir /media/ad/data/bd1c

Допустим.

su postgres -c '/usr/lib/postgresql/9.6/bin/initdb -D media/ad/data/bd1c --locale=ru_RU.UTF-8'

Внимание на относительный путь. Я не уверен, где в итоге initdb пытался сделать базу.

привел к виду
data_directory = '/var/lib/pgsql'

? Откуда это здесь взялось?

какой из postgresql.conf главнее

Тот, который указан в аргументах запуска postgres. Явным образом через -c config_file либо находящийся в PGDATA в случае отсутствия аргумента с именем конфига.

Зачем set? Таблица связей типично состоит из пары внешних ключей на связываемые таблицы. Т.е. обычно два инта и составной первичный ключ.

Возможность есть понаписать триггер. Только сначала хотелось бы понять смысл.

По порядку:

Повторно запрос выполняется много быстрее.

Значит, вы с головой упёрлись в диск.
Вариант есть только один - ставить быстрый диск.
Вариант похуже, т.к. диск всё равно у вас останется медленный и если не на чтении, то на старте и на записи вы туда упрётесь очень хорошо - использовать больше памяти. Чтобы как можно данных было в памяти. Но при работе эти данные всё равно надо поднимать с медленных дисков, потому базу сначала придётся разогревать. Есть даже штатная утилитка pg_prewarm

В конфиге postgresql менял настройки только авторизации.

По дефолту там что-то несмешное вместо shared_buffers. 32 что ли мегабайта? И это на ключевую характеристику базы.
Увеличивать хотя бы до 20% от общего объёма памяти на машине.

В третьих, актуальный Postgresql довольно плохо умеет развесистый IN. И тому есть не совсем очевидное решение - переписать в join:

select count(*) from test JOIN (VALUES (1),...,(10000)) AS v(val) USING (val);

Такой вот hash join работает быстрее IN. На 10000 элементах получали 10мс против 380мс у IN.

Вы имеете в виду это?
kohanaframework.org/3.3/guide/database/config