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 и, соответственно, это может быть реализовано не во всех.
Владимир, зато это могут быть совершенно разные куски кода, если условие "не изменилось ничего" проверяет ядро самого mysql, а не передаёт коду storage engine. Могли решить не менять api storage engine лишний раз ради проброса списка изменённых полей вдобавок к самому таплу ради такой оптимизации.
