Кластер Postgres для 1С. Повествование об интеллектуальных скитаниях инженера со счастливым концом

Тоже всегда так делал, пока мне не рассказали и сам не проверил по тж - последняя платформа 1С дает команду analyze самостоятельно при создании временных таблиц.

Очень ценный комментарий, но к сожалению не указана версия платформы.

Нигде тут не нашел упоминания что такое "последняя платформа", просьба указать версию(Например (8.3.17.2316) (z) ), где вы проверяли такое поведение платформы.

MySQL: казнить нельзя помиловать

Тут больше о том, что таким евентом можно точно знать отставание. А что делать с отставанием — другой вопрос.

MySQL: казнить нельзя помиловать

Напишу, вдруг кому полезно будет.
Уже достаточно давно использую решение такой проблемы (на Mysql5.5, Percona5.6, Percona5.7) в случаях, когда мастер и слейв заранее известны и автоматически меняться местами не будут.

Минусы такой схемы:
…
Слейв до завершения выполнения транзакции еще не знает, что он отстает в slave_status по seconds_behind_master.

Делается таблица max_delay_sec int, date_last_update datetime и 2 евента: для реплики и для мастера.
На мастере поле date_last_update обновляется евентом раз в 2 секунды.
На слейве сравнивается date_last_update с now() и выясняется приемлимость задержки.
После того, как в бд есть реальная задержка репликации можно уже что угодно делать.

Например, у меня закрывается возможность подключения для хапрокси:

Update mysql.user  
    set Host= (select if(abs(timestampdiff(second, date_last,now()))<=Setup.max_delay_sec ,'%','127.0.0.2')  
                     from Setup 
                     Where id_Setup=1
                  ) 
    Where user='robot_haproxy';
  If row_Count() is not null and row_count()>0 Then
      flush privileges;

Как бы коряво этот костыль не выглядел, но он успешно живет 6 лет и перенаправляет/разделяет поток чтения с базы в условиях, когда железо виртуальное, исключительно нестабильное.
Сейчас изменение пользователя заменено на скрипт типа такого github.com/olafz/percona-clustercheck