Melkij

Как разделить таблицу, горячие данные оставить на SSD, холодные - на HDD. Для этого во-первых партицирование для разделения таблицы на две. https://habrahabr.ru/post/273933/ (как обычно, внимание на комменты и pg_partman)
Затем, до миграции данных (или сразу при создании партиций), перенос архивных в другой tablespace www.postgresql.org/docs/current/static/sql-createt... stackoverflow.com/a/11228536 на HDD.
Затем миграция данных на партиции.
Вообще-то, это уже может быть вполне достаточно. 1-2млн строк * 365 дней это не запредельно много. Хотя не указан характер данных.

Прозрачный для приложения перенос таблиц на другую железку - FDW, foreign data wrapper. Чем актуальнее postgresql - тем лучше. Пилится штука весьма активно по части оптимального распределения запроса. Дружит ли уже с партицированием - честно, не в курсе.

Прозрачно отправить запрос на две базы и склеить - элементарно view с union all из локальной таблицы и FDW. Только это неинтересный вариант, зачем для запроса на горячие данные дёргать холодную часть базы?

Вдобавок, можете посмотреть в сторону postgresql-xl, greenplum. Первый года полтора назад был не вполне production-ready, сейчас не знаю, второй используется даже в банковской сфере, но как мне помнится катастрофически не годится для OLTP, только OLAP нагрузка.

Едва пролезет мизинец - это по меньшей мере сантиметр места. Это дофига места. Типичное плотное расположение дисков - расстояние в считанные миллиметры.
Что с ними будет при этом - им всё равно. И крайне не всё равно на собственную температуру. По-дурацки спроектированный корпус может допускать перегрев даже одного диска. Смотрите в мониторинг, оптимальная температура диска и в простое и в нагрузке расположена в диапазоне 35-45С.
Соответственно при плотной компоновке может потребоваться более мощный обдув.

SSD - всё равно, жёстких требований к установке и рабочей температуре нет.

Жесткий диск периодически при запуске выдает ошибку об отсутствии.

Для начала проверить исправность железа.
Особенно диска (MHDD, Victoria), посмотреть SMART.

Затем - при каких действиях тормозит и что в этот момент утилизируется максимально?
Если только у вас не резко вычислительная задача, то ваш добротный 4-ядерный i5 вполне актуален до сих пор. Катастрофической разницы в производительности нет, хотя этими черепашьими шагами в пару процентов за поколение нынешние и побыстрее будут.
ОЗУ - возможно просто недостаточно объёма. Но опять же зависит от задач.

Если у вас не только в prerouting стоят первые 4 правила, но и в таблице маршрутизации созданы routing mark соответствующие, то картина ничем не отличается от одного аплинка. Эти правила как раз и обеспечивают ответ на входящее соединение именно на тот канал, откуда запрос пришёл.

Я для удобства в nat завёл цепочку port_forward, в которую перебрасывал пакеты по правилам in-interface=ether2 и in-interface=ether3. А в этой цепочке уже обычный форвардинг без привязки к реальному интерфейсу.

/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether3-gw0
add action=masquerade chain=srcnat out-interface=ether4-gw1
add action=jump chain=dstnat in-interface=ether3-gw0 jump-target=port_forwarding_udp protocol=udp
add action=jump chain=dstnat in-interface=ether4-gw1 jump-target=port_forwarding_udp protocol=udp
add action=jump chain=dstnat in-interface=ether3-gw0 jump-target=port_forwarding_tcp protocol=tcp
add action=jump chain=dstnat in-interface=ether4-gw1 jump-target=port_forwarding_tcp protocol=tcp
add action=dst-nat chain=port_forwarding_udp dst-port=6891 protocol=udp to-addresses=192.168.5.20
add action=dst-nat chain=port_forwarding_tcp dst-port=80 protocol=tcp to-addresses=192.168.7.10

Если с какого-то аплинка порт остаётся закрыт, попробуйте попинговать сам роутер. Если пингов нет на том же самом провайдере - разбирайтесь с routing-mark. Я не раскурил в своё время, как работает эта магия с check-gateway 8.8.8.8.

pgbouncer держит всегда запущенными некоторый пул коннектов (дефолтно, во всяком случае, не в курсе, можно ли его попросить долговременно не держать коннекты вообще). Если вы их утилизируете не все - то будут idle.
А так же это могут быть и старые коннекты, если инициатор соединение ещё не закрыл сам или оно ещё не было закрыто по таймауту. Например, приложение может иметь собственный пул коннектов.

И, разумеется, pgbouncer обрабатывает только те коннекты, которые адресованы именно ему. СУБД он не трогает вовсе, pgbouncer - стороннее приложение, для postgresql - это просто ещё один клиент.

А зачем останавливать репликацию и прочие странные вещи для добавления колонки в postgresql?
Добавляете default null колонку. Транзакционно, мгновенно. Если колонка не должна быть null - то после добавления колонки меняете ей default, затем небольшими пачками обновляете имеющиеся строки, затем drop null.

Давным-давно, в далёкой галактике...
Хм, нет, в этой галактике. И не так уж давно, 199х, начало 200х годов процессоры поставлялись вообще без крышки, кулер устанавливался напрямую на кристалл CPU. Но бывало кристалл при неаккуратном воздействии повреждался. К тому же, в эти года был огромный прогресс производительности CPU, но и весьма заметный рост потребления энергии, что вело к увеличению массы кулера и повышению риска повредить кристалл.
В итоге (не помню, кто первый), начали кристалл прикрывать теплораспределительной (и заодно защитной) крышкой. Одновременно с этим эту крышку начали снимать для разгона. Т.к. лишний посредник, немного ухудшает теплопроводность. К тому же, бывали случаи не совсем брака, кривая (выпуклая или вогнутая) крышка, кулер прижимался неплотно, что ухудшало охлаждение. Бывало, что неравномерно была припаяна сама крышка (а в те времена использовался именно припой) и ядро грелось сильнее, чем одноклассники. Иногда крышку снимали и вообще не ставили обратно. Иногда снимали, меняли термоинтерфейс и ставили крышку обратно. Штука рискованная (припой держится весьма прочно, повредить кристалл просто), давала всего несколько градусов выигрыша, поэтому не слишком популярная.

Несколько лет назад интел офигел от отсутствия конкуренции и больше не использует припой между крышкой и кристаллом. Сначала в дешёвых CPU, начиная с Ivy Bridge LGA1155 (да, если вы не знали позицию интела: 6700K - это дешёвый процессор. Не дешёвый - это $1000 и выше). Сейчас уже и в младших представителях линейки энтузиастов (LGA 2011-3) используется термопаста вместо припоя. На счёт серверных xeon не уверен, но скорей всего там пока держится припой.

Почему использует? Термопаста банально дешевле припоя, и значительно дешевле жидкого металла. На одного человека, выразившего недовольство новой политикой - есть армия тех, кто ничего не заметил. Первыми просто пренебрегли.

Saboteur,

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

Покажите конкурента. AMD Zen - надеемся, ждём. Текущая линейка не конкурент для производительного сегмента.
А пока нет конкурента - можно снижать затраты на производство. Всё закономерно.

select date(`created_at`) as create_date, sum(if(type = 'new', 1,0)) as new_count, sum(if(type = remove, 1,0)) as rm_count
from actions 
where user_id = 1 and created_at > DATE_SUB(CURRENT_DATE, INTERVAL 7 DAY)
group by create_date

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

php > var_dump(password_verify(null, '$2y$05$WjKwE1MiWPyPFghASGGcdupFqfcUHchkb2y/rwTiCWe40iIbqyxKq'));
bool(true)
php > var_dump(password_verify('', '$2y$05$WjKwE1MiWPyPFghASGGcdupFqfcUHchkb2y/rwTiCWe40iIbqyxKq'));
bool(true)

Проверяйте, от чего именно вы получаете хеш. И когда вы его получаете. Где-то там сам пароль потерян и осталась пустая строка.

Разбирать вручную из file_get_contents('php://input');
Возможно, ещё пригодится parse_str, которой PHP сам разбирает query string в $_GET и application/x-www-form-urlencoded в $_POST.