А кто сказал что сервис предназначен именно для землян?
ах, просто вероятностное допущение, тут обычно земляне пишут, а они известные шовинисты, не учитывают существование других обитателей вселенной.
Из-за латентности и дороговизны межпланетной связи, впрочем, партицировать пользователей скорей всего по-прежнему не очень разумно, скорей всего придёте к решению шардировать по региональному признаку. Как минимум одна копия сервиса на планету, а может даже и несколько в разных населённых регионах планеты.
password authentication failed for user точно говорит, что pg_hba выполняет парольную аутентификацию (plain text password, md5 или же scram). При неуспехе других методов аутентификации используются другие тексты ошибок.
Следовательно, проверяйте ваш пароль. Который вы задали для пользователя именно в базе, а не в системе.
pgbouncer не даст использовать другому клиенту соединение с базой с открытой транзакцией. Коннект с незакрытой транзакцией при отключении клиента будет закрыт баунсером (т.е. неявный rollback). "ERROR: current transaction is aborted" таким образом не получить. Смотреть нужно на первую из ошибок в этой транзакции, которая повлекла за собой переход в aborted состояние.
посмотрите в логе базы что было до того. Обычное сообщение об ошибке за попытку что-то делать в транзакции, ранее поймавшей ошибку. Вот с этой более ранней ошибкой разбираться и необходимо.
изучить LARTC и настроить соответствующим образом. Linux kernel, iproute2 да conntrack на firewall, ничего экзотического там нет. Материалов по multihoming и LARTC в сети навалом, я специально указал как такая конфигурация называется.
ага, именно что типа батарейка. Схематически, на сколько знаю, там действительно конденсатор.
про ограничение записи в зависимости от напряжения не слышал, но в общем возможно. Для нас ведь прошивка - чёрный ящик...
угу, ситуация полностью аналогично контроллеру с writeback кэшом без батарейки. С точки зрения именно ОС на это не повлиять, сама команда flush (недвусмысленно именованная FLUSH CACHE в ATA и аналоги в прочих стандартах) и должна была собой гарантировать, что данные реально дошли до постоянной памяти. А если по умыслу или ошибке такой гарантии нет - то ОС об этом даже не может узнать.
Можно поискать нет ли управляющих команд для конкретных SSD (по типу вендорской утилиты настроек рейд-контроллера для переключения cache mode), но я сомневаюсь в благополучном исходе.
В общем-то, напрасно. Десктопные модели в угоду себестоимости и маркетинга (как бы нарисовать производительность повыше в бенчмарках) довольно вольно обращаются с гарантиями durability которые должны бы обеспечивать. Например, когда файловой системе отчитались flush, а на самом деле контроллер SSD ещё не записал все данные во flash, а только в буфер (или вовсе лишь только в HMB в случае nvme) и который даже не прикрыт конденсатором, позволяющим корректно дописать всё что уже пообещали при внезапном отключении питания.
очевидно нет.
В postgresql errdetail (ака ПОДРОБНОСТИ) бы указал конкретную причину: не та мажорная версия, несовместимая версия системного каталога, отличающийся byte order, MAXALIGN или же float format. А что тут прошники подразумевают - ведомо прошникам. Может у вас другой форк на primary запущен?
по окончанию репликации на мастере удалил слот репликации.
Владимир, я вот про это handler::update_row в api передаются только данные старого тапла и нового, если storage engine хочет, то может сверять данные самостоятельно, что изменилось в полях. Но ядро эту информацию не передаёт в явном виде. Но я плохо знаю internals mysql, внутрянка postgresql как-то ближе. Может ядро mysql и вовсе само не проверяет, что изменилось в данных, а делают это всегда сами storage engine и, соответственно, это может быть реализовано не во всех.
