Postgres синхронная репликация?

Devtime,

хотим обкатать самый простой вариант масштабирования системы.

Но смотрите как раз на самый сложный.

Ростелеком, мда. А селектел какие-нибудь чего? Хорошее железо под базу у них есть.

Postgres синхронная репликация?

Я по неопытности думал что после сохранения на жесткий диск все транзакции уже применены (до этого они лежат в оперативной памяти)

Здесь нюанс - сохранение чего именно.
Получение потока изменений - это один процесс, walreceiver. WAL он получает с primary, пишет на диск (synchronous_commit = remote_write), дёргает fsync для гарантии того что в случае краха эта транзакция уже сохранена локально (on)
применение изменений к базе - выполняется полностью отдельно и асинхронно от получения данных - процесс startup (remote_apply)
И оба они имеют лишь опосредованное отношения к записи применённых изменений непосредственно в базе на диск - этим занимаются отдельные процессы bgwriter и checkpointer (ну, в норме, если успевают - если не успевают то и startup придётся писать датафайлы)

Можете посоветовать хороший балансировщик, который можно дополнительно настроить скриптами правила маршрутизации запроса?

select * from something;
Это запрос читающий или пишущий? Да неизвестно! Что даёт вам основание решить, что something - это таблица, а не, например, view поверх пишущей хранимки?
Кто это знает наверняка? Разработчик приложения. Следовательно наиболее корректное место для деления запросов по серверам - это само приложение.
Делить запросы необходимо на следующие группы:
- запись и чтение критичное к лагу
- чтение oltp, быстрые запросы, малое отставание реплик
- чтение olap некритичное к лагу. Долгие запросы, реплики могут отставать заметно

Балансировать по наборам равнозначных серверов - например, haproxy. Но выбор на какую группу серверов отправлять - задача приложения.

Чтение с синхронной реплики... Ну, попробуйте. Есть большие опасения что хорошо это работать не будет. Синхронные реплики они в первую очередь про "не потерять транзакцию" чем про лаг репликации.

Фанатично убирать всё чтение с мастера только потому что это чтение, а это - мастер - бесполезные хлопоты, будете героически решать несуществующие проблемы. (ну да, понимаю, это в традициях IT - искать проблемы где их никогда не было и героически решать) Когда команда только начинает упираться в один сервер - понятное дело что приложение рассчитано на работу на одном сервере СУБД. Но очень хорошего результата можно достичь убрав на реплику всего несколько запросов точечно. Включите pg_stat_satements, через сутки посмотрите что у вас в топе по нагрузке и наверняка увидите то, что можете легко унести на обычную асинхронную реплику. Может быть настроенную на малое отставание, а может - отдельно для тяжёлых запросов некритичных к лагу вообще.

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

Dmytro Boyko,
выкинуть диск из массива, сделать таблицу разделов, добавить sda1 в массив. Не забыть поставить загрузчик.

О чем говорит результат запрса? Или какой вывод можно сделать?

там, откуда дерево блокировок начинается.

Как правильно обратится полю таблицы в БД?

и где в запросе упомянута таблица second_name?
Multiple-table syntax вполне определённый, смотрите примеры в документации.

Как правильно обратится полю таблицы в БД?

Я, например, тоже совершенно не понимаю что такой запрос задуман делать. У вас нет таблицы second_name в запросе

По какой причине RAID1 при удалении одного из дисков блокируется?

zersh,

А ubuntu / Centos - редактировать его не обязательно, если это не системный раздел,

Обязательно если не хотите сюрпризов при перезагрузке системы. (обычно сопровождается автоматической сборкой массива, но с самовольным переименованием куда-нибудь в md127)

По какой причине RAID1 при удалении одного из дисков блокируется?

Другими словами, то что происходит в моем случае, является нормальной ситуацией?

Определённо нет.

zersh, забыли упомянуть редактирование /etc/mdadm/mdadm.conf и сопутствующее с ним обновление initramfs.

Чем отличается materialized view от with?

Bavashi, да, целью было inline частей cte в основной запрос: https://www.postgresql.org/message-id/E1gv7F7-0003...
Который затем планируется как единая штука.

Чем отличается materialized view от with?

with - просто синтаксический сахар для удобства написания запроса

опасное заблуждение.
в частности, до postgresql 12 cte материализуется всегда и не может пробрасывать условия из внешнего запроса. А потом более интересные фокусы из-за того что результат cte местами эквивалентен black box и никакой вменяемой оценки не имеет, а потому планировщик может хотеть делать странное.

Чем отличается materialized view от with?

Специфично для субд. Вы про какую спрашиваете?

Ну например, materialized view - это совсем не временная штука.
А под временной таблицей обычно имеют в виду вполне конкретный create temporary table. а не cte

По какой причине RAID1 при удалении одного из дисков блокируется?

Дело в том, что я не знаю где dmesg находиться:(

Это команда консольная.

Куда "потерялась" часть размера таблицы?

ну я так и подумал что вы используете какую-то странную терминологию. А сравниваете тогда с чем?

Проверяю полный размер таблицы - 3996 Мб.

Вот это?

Поэкспериментировал с методом хранения столбца external (сжатие не допускается) - тоже "потерянный" кусок есть.

Ну и это заодно уточните, после SET STORAGE таблицу переписывали?

Куда "потерялась" часть размера таблицы?

Что такое "всех слоёв"?

По какой причине RAID1 при удалении одного из дисков блокируется?

anton13ms, а вы так и будете отвечать только на часть вопросов?
явно что-то странное делаете с суперблоком. Либо неисправны диски. Куда суперблок с sdd1 делся?

По какой причине RAID1 при удалении одного из дисков блокируется?

mdadm -D /dev/md1
mdadm -E /dev/sdc1
mdadm -E /dev/sdd1
cat /etc/mdadm/mdadm.conf
плюс описание что конкретно вы делаете и с чем (виртуалка? физическая железка?)

По какой причине RAID1 при удалении одного из дисков блокируется?

Посмотрите в dmesg что ядро про массивы писало.

Как работает кластеризация mysql или другой БД кластер?

Ссылку на определение кластера-то дадите?

HA это настройка (можно считать фича), которая может быть у кластера или не быть

Согласен и не спорю с этим.
Например, мастер и N асинхронных реплик. Здесь может не быть HA для мастера и используется ручное переключение. Но это тем не менее кластер. Верно? Либо объясните почему это не подходит под ваше описание, которое я на данный момент определённо не могу назвать чётким.

И откуда из вашего варианта определения вытекает синхронная репликация? Это точно так же опция.

HA это не кластер

Кластер собранный на двух хостах только для целей HA методом cold standby - это кластер по описанию в вики.

Как работает кластеризация mysql или другой БД кластер?

По англоязычной вики HA cluster - это кластер. Cold standby - это HA cluster. Следовательно cold standby является кластером.
А ваш вариант определения, исключающего HA решения из понятия кластера, ссылкой на что можете подкрепить?

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

Мастер + N асихронных равноценных реплик. Что вам не позволяет их назвать кластером? Под указанное вами описание подходит.

Как работает кластеризация mysql или другой БД кластер?

define "кластер". Как я упомянул в своём ответе - это не чётко определённое понятие, вероятно и вы закладываете что-то другое в это слово.
cold standby из двух нод - это всё ещё HA кластер. Быть ему на синхронной репликации или асинхронной - решение конкретного проекта. Из слова "кластер" это не следует.