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

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

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

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

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

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

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

Иван Шумов, нет.
https://dev.mysql.com/doc/refman/8.0/en/replicatio...

Replication enables data from one MySQL database server (the master) to be copied to one or more MySQL database servers (the slaves). Replication is asynchronous by default; slaves do not need to be connected permanently to receive updates from the master

postgresql - так же синхронная репликация делается строго явным образом.

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

и синхронную репликацию нод

Кстати мне любопытно: а у какой СУБД репликация по-умолчанию именно синхронная?

Долго поднимается SSH на Debian 10, почему?

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

Долго поднимается SSH на Debian 10, почему?

Собственно virtio_rng нужен

Как исправить ошибки при миграции проекта с gitlab с бд postgreSQL?

Подключиться к нужной базе.

Как исправить ошибки при миграции проекта с gitlab с бд postgreSQL?

Возможно не там выполняли. Не в той БД.

Как подменить диск в Linux?

первым запуском rsync перенести данные, вторым запуском rsync скопировать то что изменилось от первого запуска. Как итог downtime сильно меньше.

Почему запрос с IN в СУБД PostgreSQL выполняется значительно медленнее аналогичного запроса с OR?

В чем смысл +0?

Это полностью лишённое смысла действие.
Зато об этом не знает планировщик. Как следствие не рассматривает использование индекса по этому полю как возможный план выполнения запроса.
Можно считать магией DBA. Применять как универсальное средство нельзя, только под конкретные симптомы.

что это такое

Простое сложение двух чисел.

первоначальный запрос IN начинает выполняться также быстро как и вариант с OR.

Быстрее. При том существенно, быстрее в 50 раз.

Поднятие statistic target должно дать ускорение варианта запроса с использованием IN?

Должно выправить статистику. С увеличение объёма статистики все запросы задевающее это поле будут планироваться медленнее, но давать более аккуратную оценку числа строк. Чем точнее оценка - тем точнее косты и более оптимальный план выполнения.

Почему запрос с IN в СУБД PostgreSQL выполняется значительно медленнее аналогичного запроса с OR?

ну так и где вы потеряли этот desc? Добавьте раз нужен.
Сортировка по bigint не изменяется относительно сортировки по bigint+0 потому что сортируются всё равно по результирующему bigint.

Почему запрос с IN в СУБД PostgreSQL выполняется значительно медленнее аналогичного запроса с OR?

order by id + 0 я использовать не могу

Какой это у вас тип данных, что для него определён оператор сложения с числом, но при этом при сложении с константой нарушается сортировка?
asc/desc неважно.

А начните, как я уже сказал, с поднятия statistic target.

Переключение форматирования в psql - команда \x

Почему запрос с IN в СУБД PostgreSQL выполняется значительно медленнее аналогичного запроса с OR?

Всё как я и подумал. Хоть данные статистики и не показали.

Планировщик основываясь на MCV списке статистики решил, что требуемых source в таблице достаточно много. Потому решил исключить сортировку данных и идти по индексу по полю id, выбрасывая по пути в рантайме неподходящее. Реальное распределение данных оказалось однако не таким. И пока набрали limit записей - прошло уже много времени и random io.

Как нетрудно заметить - все три других плана запросов сортируют результат в рантайме и используют другой индекс.

Можно попробовать поднять statistic target для поля и пересобрать статистику. Вероятно вправит оценку планировщика. Или оставить order by id + 0. Это известный костыль для этой вполне известной грабли.

Почему запрос с IN в СУБД PostgreSQL выполняется значительно медленнее аналогичного запроса с OR?

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

Для определённых выводов не хватает данных.

Почему не отрабатывает изменение правил доступа по умолчанию на уровне схемы?

Однако если в правах доступа разрешить не только чтение, а всё (ALL), проблема исчезает.

Сомнительно. Скорее предположу разницу в том, кто именно создаёт таблицы и для кого ALTER DEFAULT PRIVILEGES объявлены.
Соберите воспроизводимый пример из create user, ALTER DEFAULT PRIVILEGES, \ddp, create table и \dp

Сколько нужно создавать слотов для 10 реплик при потоковой репликации?

Полагал что слот - это как в логической репликации - издатель/подписка. Поэтому думал что publisher примерно как слот. А реплики - примерно как подписчики.

В логической репликации publisher может быть один, но каждый подписчик создаёт свой отдельный слот логической репликации на мастер-базе. Да, они тоже - replication slots.

Сколько нужно создавать слотов для 10 реплик при потоковой репликации?

Для каждой реплики отдельный слот репликации если вы хотите использовать слоты репликации.

Я об этом так же написал в ответе.

- replica-1 с 1 БД, полученной с мастера

Потоковая репликация postgresql - всегда полная копия всего инстанса. Не может быть чтобы реплицировалась одна БД с кластера.

Мы не используем слоты репликации для потоковых реплик, увеличиваем вместо этого wal_keep_segments. Здесь оценка риска: без слота репликации реплика может отстать и её надо будет выключать и копировать заново. Слот репликации же будет удерживать WAL от удаления бесконечно пока их не прочитают. Типичная история - мастер лёг потому что кто-то забыл удалить слот репликации и место на диске в итоге кончилось. И вот между "лёг мастер" и "реплика работает но показывает старые данные" - выбор как-то обычно в сторону второго сценария, влияние на сервис менее болезненное.
Мониторить репликацию разумеется надо, но всё равно почему-то it happens.

Как изменить путь к логу postgresql на работающей реплике?

Aborigen1020, зависит от решения администратора либо сопровождающего пакета. Конфиг может лежать в $PGDATA или абсолютно где угодно - но во втором случае его местоположение должно быть указано аргументом при запуске базы.
Второй вариант характерен для debian/ubuntu пакетов, в centos принято в $PGDATA оставлять.

Offset не работает с подзапросами?

И дальше что? Думаете кто-то может догадаться о чём вы вообще говорите если вы оставляете только какие-то фрагментарные обрывки сведений?

Offset не работает с подзапросами?

Значит смотрите explain (analyze, buffers, verbose)