Melkij

Это должны быть те /sys/class/net/*, у которых существует /sys/class/net/$iface/wireless

HDD - это расходники. Нет смысла обсуждать "меньше" или "больше" проживут. Сдохнут гарантированно. Если повезёт, то ещё в гарантийный период - бесплатно поменяете.

Для SOHO разница между линейками по большей части неважна. Вот что стоит уточнить - SMR или CMR диск и готовы ли с этим мириться. Достаточную ли вам предлагают скидку за террабайт, чтобы вляпываться в SMR. В одной и той же линейке дисков могут быть одновременно и SMR и CMR диски, уточнять нужно модели.
Далее, скорость вращения диска. 7200 чуть быстрее, 5400 медленнее но их попроще охлаждать в среднем. Различие скорости для личной медиатеки скорей всего неважно, но на достаточно хорошем интернет-канале торренты могут заметно озадачить массив количеством IO.

Зеркало будет надежно или лучше пожертвовать местом и сделать raid5 или 6?

Звучит как полное непонимание вопроса. Каким местом жертвовать, если именно зеркало даст меньше всего форматируемую ёмкость массивов? Местом придётся жертвовать, если делать как раз зеркало.
На примере шести 10ТБ дисков для удобства счёта, из 60ТБ RAW ёмкость массива:

raid0 или JBOD - дадут вам все 60ТБ, выпадение любого диска фатально.
raid1 - зеркало - даст вам как максимум 3 массива по 10ТБ, до 30ТБ форматируемой ёмкости. В каждом массиве соответственно можно потерять по соседнему диску. То есть хранилка выпадение одного любого диска переживёт, выпадение второго диска - смотря какому из дисков не повезёт. Можно потерять один из массивов полностью. (raid1 на всех 6 дисках вряд ли входит в вопрос, 10ТБ итоговой ёмкости, но чтобы их потерять из-за отказа диска нужно чтобы отказали все 6 дисков)
raid5 - даст вам 50ТБ форматируемой ёмкости. Переживёт выпадение одного любого диска, выпадение второго диска - фатально для всего массива.
raid6 - ближайший родственник raid5 - даст вам 40ТБ ёмкости. Но зато гарантированно переживёт выпадение любых двух дисков. Только отказ третьего будет фатален для массива.
raid10 - даст вам 30ТБ ёмкости как raid1, гарантированно выдержит выпадение одного диска, в идеале может работать на только половине дисков массива но критично зависит от структуры raid10, какие именно номера дисков могут быть потеряны без краха всего массива. Отказ второго диска может оказаться фатален. Используется не когда нужна ёмкость или возможность пережить несколько выпавших дисков, а когда нужна производительность, особенно на запись. То есть вряд ли ваш случай.

Что ещё надо упомянуть - вот диск из массива умер, сколько времени вам нужно это заметить, купить новый на замену, заменить? Плюс на таких объёмах займёт ещё сутки-двое-трое на восстановление массива. Вот тут причина, почему существует RAID6, хотя он по ёмкости хуже RAID5 и не лучше по производительности - пока у вас массив деградировал до 5/6 дисков, он переживёт выпадение ещё одного из дисков пока вы ставите замену и массив восстанавливается.

У яндекса весьма медлительные сетевые диски, совершенно верно. Именно по latency, что куда более критично для СУБД чем обещанная полоса пропускания или IOPS (которые у большинства хранилок предполагают совершенно абсурдную для СУБД глубину очереди команд).

Ведь когда мы создаем переменную, то в нее копируется значение другой переменной и мы работаем с копией

Неа. См. zval

Начав работать с языком Go начал придавать значение экономии памяти - не создавать лишних переменных.

Разве компилятор go недостаточно умён для элементарных оптимизаций кода?
Вы проверяли байткод, ваша оптимизация действительно имеет место или это самообман?

resize2fs /dev/centos/home с указанием размера файловой системы с каким-то запасом, до 400ГБ например обрезать. Критично следующим шагом не обрезать часть файловой системы.
lvresize /dev/centos/home до желаемого размера
lvresize /dev/centos/root до желаемого размера
resize2fs /dev/centos/home
resize2fs /dev/centos/root

Если wal_status становится lost - значит max_slot_wal_keep_size был изменён с дефолтного значения -1 и установлен в какое-то другое значение.
Потому что именно для этого добавляли настройку max_slot_wal_keep_size, чтобы отставший слот репликации не ронял базу.

Любой. Это расходник.

Критерии:
- цена за террабайт
- длительность гарантии (учесть, что это не гарантия того что диск столько проработает, а вероятность получить исправную замену в течении указанного срока, переплачивать х2 только за гарантию нет смысла, надёжнее будет взять два HDD)
- CMR если нет чёткого понимания что для задачи сгодится SMR и только если SMR очень ощутимо выгоднее

Стандарт SATA изначально требует поддержку hot swap. Но конечно могут быть нюансы для конкретных реализаций диска, контроллера или ОС.

В linux имеет смысл скомандовать echo 1 > /sys/block/(device)/device/delete перед отключением питания. Ядро сбросит буфера и скомандует остановку шпинделя диску.

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

remaining connection slots are reserved for non-replication superuser connections

означает, что у базы заняты все возможные max_connections - superuser_reserved_connections, поэтому не может принимать больше коннектов, пока не отключится кто-то из подключившихся ранее (либо не будет обнаружен обрыв tcp сессии и поэтому коннект будет освобождён).

Если посмотреть спецификации, то будет видно что про материнки так и пишут OC, например

Support for DDR5 7200(OC)/ 6800(OC)/ 6600(OC)/ 6400(OC)/ 6200(OC)/ 6000(OC)/ 5600(OC)/ 5200/ 4800/ 4400 MT/s memory modules

OC = overclock, то есть разгон.

При том, интел или амд без разницы

14th and 13th Generation Intel® Core™ i9/i7 Pocessors:
- Support for DDR5 7600(O.C.) /7400(O.C.) /7200(O.C.) /7000(O.C.) /6800(O.C.) /6600(O.C.) / 6400(O.C.) / 6200(O.C.) / 6000(O.C.) / 5800(O.C.) / 5600 / 5400 / 5200/ 4800/4400 MT/s memory modules

Оба основных производителя CPU давно занижают спецификации памяти.