Прерывистый 2013, Потеряно соединение с сервером MySQL при «чтении начального пакета связи», системная ошибка: 0 для CloudSQL

В воскресенье я установил старое приложение Django на новый экземпляр GCE и указал его на новый экземпляр CloudSQL с импортированными туда данными. Этот код и данные успешно работали в течение последних нескольких лет на различных конфигурациях выделенного хостинга, в EC2 и EC2+RDS.

С воскресенья у меня были прерывистые отчеты за 2013 год: «Потеряно соединение с сервером MySQL при« чтении начального пакета связи », системная ошибка: 0» из приложения. В частности, сегодня это произошло двумя очередями по 3 человека, разделенными примерно 7 часами.

Я запаниковал из-за предыдущих сбоев и перезапустил приложение и экземпляр CloudSQL, что помогло. Однако последние сегодня исправились через несколько минут.

Я никогда не сталкивался с этой ошибкой до работы с MySQL, и любой поиск по ошибке дает результаты, относящиеся к людям, у которых есть общие проблемы с доступом к БД.

Что касается GCE, то единственное отличие, которое я могу придумать, от предыдущих настроек заключается в том, что он использует готовый образ Debian от Google вместо Ubuntu 12.04. На стороне MySQL я понятия не имею, так как я успешно запустил это как на MySQL 5.x, так и на MariaDB.

Есть ли способ выяснить, почему это происходит, и исправить это?

Спасибо.


mysql google-cloud-sql google-compute-engine
person Conor O'Neill    schedule 18.11.2014    source источник
comment
У меня точно такая же проблема, но с PHP-приложениями все работало без проблем до трех часов назад, у меня такая же ошибка исходного пакета связи   -  person Mohammad Abu Musa    schedule 18.11.2014

Ответы (2)


arrow_upward
1
arrow_downward

Вы пытались изменить настройки поддержания активности для TCP-соединений? В GCE есть правила брандмауэра, которые прерывают простаивающие TCP-соединения через 10 минут:

https://cloud.google.com/compute/docs/troubleshooting#communicatewithinternet

Вы можете проверить текущее значение 'tcp_keepalive_time':

cat /proc/sys/net/ipv4/tcp_keepalive_time

И измените его на 60 секунд:

vi /etc/sysctl.conf
# Add this line
net.ipv4.tcp_keepalive_time = 60
# Reload Sysctl interface
sudo /sbin/sysctl   --load=/etc/sysctl.conf

Возможно, вам придется перезапустить сервер Django, чтобы выбрать новые настройки поддержания активности.

Примечание. Если эта проблема возникла только вчера (18 ноября 2014 г.) и ваши экземпляры Cloud SQL расположены в ЕС, вы могли столкнуться с этим:

https://groups.google.com/forum/#!topic/google-cloud-sql-announce/k5raPT48hc0

person saket    schedule 19.11.2014
comment
Я попробую изменить TCP, они могут объяснить проблему с ночным подключением. Проблема вчерашнего дня произошла точно в указанное выше время. Спасибо, что сообщили мне об этом. - person Conor O'Neill; 19.11.2014
comment
Я внес эти изменения вчера, но ошибка 2013 года снова произошла в 22:11 сегодня вечером. Был ли у CloudSQL еще один сбой или есть какая-либо другая известная нестабильность? Понаблюдаю еще несколько дней. - person Conor O'Neill; 21.11.2014
comment
Можете ли вы также проверить, установлена ​​ли политика активации для экземпляра «всегда», а план выставления счетов — «пакет»? cloud.google.com/sql/pricing#pricing-example - person saket; 24.11.2014
comment
Да, оба были настроены с самого начала так. - person Conor O'Neill; 24.11.2014

arrow_upward
0
arrow_downward

Кажется, есть проблема с брандмауэром, предотвращающим входящие соединения, просто измените местоположение с сервера на другое зеркало, и все должно пройти нормально. Это сработало для меня

person Mohammad Abu Musa    schedule 18.11.2014