А
Ещё есть Ent, но пока сыроват
Size: a a a
2021 April 10
А
Лики-то пройденный этап, отключаем логи запросов, выгружаем кеш
AC
А с остальным что делать?
А
По слейвам это к dbal-слою, и не помню там проблем, прописал в конфиг и работает. В чем проблема?
AC
После первого обращения к мастеру все остальные запросы идут дальше к мастеру
AC
У меня коллега делал костыль чтоб этого не было с setConnect
А
Точно запросы не на изменение?
А
То есть, я убеждён, что так)
AC
После пачки селектора апдейт потом пачка селектов
AD
> потом пачка селектов
если среди этих данных есть данные из свежего апдейта, то, возможно, не стоит ходить за ними на слейв?
если среди этих данных есть данные из свежего апдейта, то, возможно, не стоит ходить за ними на слейв?
G
хехе, так что это не баг, это - фича)
AN
Оо, недавно тоже набрал гигабайты в логгере) Вырубил его нафиг. А кэш объектов через
$entityManager->clear(); периодически очищал
$entityManager->clear(); периодически очищал
AC
По бизнес логике там не критично если слейв отстал на пару записей. Так что это таки баг
AD
Всем не критично?
AC
В плане всем?
AD
Всем приложениям не критично запросить отстающие данные после апдейтов?
AC
Да, это микросервис с консольными соркерами. Они делают одну мелкую задачу. Мне нужно чтоб чтение што онли со слейвов а апдейт в мастер
G
тогда прочитайте сначала все, а потом апдейт)
AC
Спасибо, отдам коллеге пусть потестит