Тайм-аут соединения с Golang MySQL после обновления Ubuntu - PullRequest
0 голосов
/ 26 сентября 2018

У меня проблема с проектом golang, извлекающим данные из базы данных MySQL.Этот проект работал без проблем, пока я не обновил Ubuntu 16.04 до Ubuntu 18.04.01.Время ожидания приложения при подключении к базе данных.

Моей первой мыслью было, что что-то сломалось в обновлении с 16.04 по 18.04.Чтобы доказать это, я развернул новую виртуальную машину, работающую 16.04, выполнил «do-release-upgrade» и довел ее до 18.04.Однако на этой виртуальной машине мое приложение работает без проблем.

Я в недоумении, куда идти отсюда, чтобы выяснить причину происходящего.Вот краткое изложение двух конфигураций.Виртуальная машина (работающая) и сервер (не работающая):

Ubuntu 18.04.01 LTS x86_64
Kernal 4.15.0-34-generic
Go 1.11
MySQL 5.7.23-0ubuntu

Вот моя тестовая программа:
основной пакет

import (
        "fmt"
        "database/sql"
        _"github.com/go-sql-driver/mysql"
)

func main() {
        fmt.Printf("Connecting to db\n")
        db,err := sql.Open("mysql","Test:@/Test")
        if err != nil {
                panic(err)
        }
        fmt.Printf("Trying query Row\n")
        var Data int 
        err = db.QueryRow("SELECT Data FROM Test WHERE ID=2").Scan(&Data)
        fmt.Printf("After Query\n")
        if err != nil {
                panic(err)
        }
        fmt.Printf("Got Data=%d\n",Data)
        db.Close()
}

На виртуальной машине программа выполняется без проблем и возвращает некоторые действительные данные.Сервер висит на строке QueryRow.Через 2 минуты я получаю этот ответ

$ time ./test
Connecting to db
Trying query Row
After Query
panic: dial tcp 127.0.0.1:3306: connect: connection timed out

goroutine 1 [running]:
main.main()
    /home/daedalus/test/sqltest.go:20 +0x263

real    2m10.874s
user    0m0.001s
sys 0m0.009s

Я понимаю, что проблема в том, что программа не может подключиться к базе данных или база данных не отвечает, но я не могу понять, почему.Ничего не регистрируется ни в системном журнале, ни в файлах журнала mysql.В MySQL нет ничего плохого, что я вижу.Я могу подключиться и выполнять запросы в качестве тестового пользователя просто отлично.

Я не уверен, что делать, чтобы отследить причину сбоя сервера, но виртуальная машина работает, когда обе конфигурации одинаковы.

Буду признателен за любую помощь.

Ответы [ 2 ]

0 голосов
/ 10 октября 2018

Отвечая на мой вопрос, просто чтобы закрыть его, но спасибо, Питер, за ваши комментарии, которые привели к моему решению.

Проблема была именно в моих правилах брандмауэра.У меня есть некоторые строгие правила в отношении страны происхождения, но случайно заблокировал трафик с 127.0.0.1.Как только я сделал исключение для этого, все работает отлично.

0 голосов
/ 26 сентября 2018

Я могу подумать о 2 возможностях:

  • На сервере MySQL отсутствует пользователь "Test@127.0.0.1", но есть пользователь "Test @ localhost"
  • Брандмауэр сервера блокирует доступ кпорт 3306 на 127.0.0.1
...