@human_revolution Я передам ваш адрес электронной почты нашему менеджеру по продажам, не пугайтесь, просто у нас такой порядок, они вам разъяснят экономическую часть и общие принципы нашей работы, вероятно, при участии нашего технического директора. А после, если вам покажутся вкусными наши условия, мы с вами уже увидимся при решении конкретных задач ;)
Уточняющий вопрос: это ваша личная почта? или нужно писать с пометкой "для.. " ?
@human_revolution Я работаю в IT-Аутсорсинговой компании и мы часто занимаемся настройкой почтовых серверов, однако, в данном случае, к сожалению, мы никогда не практиковали передачу полного управления почтовыми сервисами сторонней организации, в данном случае - Яндексу, поэтому, увы, опыта работы с почтовыми серверами на Яндексе, у меня нет и что у них внутри там настроено - представлять не могу, и как следствие и информации никогда по ним не искал.
Если вам интересно, мы могли бы настроить для вас ваш собственный почтовый сервер и администрировать его, не сочтите за рекламу, просто мало ли ;)
@human_revolution Если вам в итоге удастся каким-либо способом обойти данную проблему, я прошу вас изложить её решение здесь, так как я так же могу в какой-то момент времени столкнуться с данной проблемой.
Если не затруднит.
@human_revolution Тогда либо можно продолжать бодаться с гуглом, максимально подгоняя настройки своего почтового сервера под их стандарты, либо изменить настройки почтового клиента своих сотрудников так, чтобы при нажатии кнопки "ответить" - не добавлялось автоматическое "RE". Если парк машин, участвующих в почтовых пересылках достаточно велик - это, безусловно, будет нелегкой задачей, однако и с гуглом бороться - проблема не из простых.
@human_revolution Есть ли у вас SPF-запись?
подогнали ли вы свою рассылку к стандартам по содержанию?
Не думаю, что размер DKIM-подписи как-то существенно влияет, мне всегда казалось, что достаточно её наличия в правильной форме.
На сколько я понимаю, репликация работает так:
1) Мастер пишет все действия, которые на нем выполняются на запись в бинлоги
2) Слейв читает бинлоги
3) Слейв применяет все действия на запись, прочтенные из бинлогов на себя.
На сколько я понимаю, запросы, которые извлекаются из бинлогов - не отображаются явным образом в процесс листе. В процесслисте отображаются только те запросы, которые были созданы непосредственно к слейву, а не переданы на него посредством бинлогов.
Таким образом, мной имелся в виду тяжелый запрос из бинлогов, а не непосредственно к слейву.
Прошу поправить меня, если я не прав.
Таким образом, конечно, нельзя полностью избежать огрехов всех маршрутов через которые пройдут ваши TCP-пакеты, однако улучшить ситуацию все равно можно.
в SHOW FULL PROCESSLIST; отображались лишь процессы, связанные с репликацией ( чтение информации с мастера и ожидание пока мастер пошлет информацию). К слейву впринципе никаких запросов не идет, он используется только для снятия бэкапов.
Можно предположить, что был какой-то большой запрос в бинлоге, однако слейв и мастер - примерно одинаковые по мощности машины и я предполагаю, трехдневное выполнение запроса на запись в одной из таблиц дало бы о себе знать.
P.S. Такое состояние длилось три дня и прошло само по себе, без каких-либо действий.
Впринципе, ваша теория возникала и у нас в головах, однако, подтверждений ей явных нет.
