Случайные ошибки подключения к MS SQL из приложения nodeJS

У нас есть сервер AWS, на котором запущены некоторые службы nodeJS. Службы, подключающиеся к MS sql, случайным образом аварийно завершают работу с сообщением «Не удалось подключиться к серверу базы данных: 1433 — не удалось подключиться (последовательность)».

Мы работаем на:

Сервер приложений: Linux Ubuntu 14.4 AWS m5 NodeJS: 8.11.2 Службы используют последнюю версию пакета mssql (4.3.0). Это включает в себя утомительные 2.7.1.

Сервер БД: Windows Server 2012. SQL Server 2012

пропускная способность: около 300 об/мин, ошибка возникает и при более низкой пропускной способности (около 20 об/мин). Приложение работает в кластере через PM2 (запускается 4 раза). Мы видим, что ошибка возникает во всех 4 случаях одновременно, но иногда и в 1 или 2 экземплярах.

Что мы пробовали:

  • Обновление до альфа-версии mssql с утомительной 3.0.1. Не имело значения
  • Обновление с компьютера Amazon M4 до компьютера M5 с улучшенной сетью
  • Изменение настроек пула в приложении. Мы попытались установить минимальное количество соединений на 0 или низкое/высокое значение. Max также на низкое / высокое значение, но безрезультатно.
  • Дублировать сервер на новую машину.
  • Установка idleTimeoutMillis на 1 секунду
  • Пингуем сервер БД, чтобы узнать, есть ли проблема с подключением, но мы не видим странных пингов, когда возникает ошибка.

Подключение при запуске приложения:

    App.sqlConnection = new App.SQL.ConnectionPool(config, function(err) {
            if(err){
                    Log.error(err);
                    process.exit(1);
            }

    App.sqlConnection.on('error', err => {
        Log.error(`There was a connection err : ${err}`);

        process.exit(1);
            });
    });

запрос;

var request = new App.SQL.Request(App.sqlConnection);
request.query(sQuery, function(err,results)
{
});

Ошибки перехватываются обработчиком «при ошибке».

Ошибка возникает случайным образом в сервисах. У некоторых больше случаев ошибки, чем у других. У нас заканчиваются варианты. Любая идея, если мы можем увидеть более подробные ошибки?


person timgeudens    schedule 21.12.2018    source источник


Ответы (1)


У меня есть пара предложений.

Во-первых, насколько вы уверены, что эти ошибки действительно являются проблемой? Если ваш код просто повторяет попытку, а не завершает работу, будут ли после этого соединения стабильными или соединение может прерваться в середине запроса?

(Разрывы соединений в середине запросов, очевидно, нехороши, но случайные сбои при соединении, которые можно исправить повторными попытками, — лучшая проблема, которую нужно иметь, ИМХО.)

Игнорируя потенциальное исправление в коде, мне интересно, когда вы говорите, что «продублировали сервер на новую машину» — вы запускали новый AMI с использованием последней версии Windows Server 2012 или вы создали образ и клонировали? Если вашему серверу базы данных уже несколько лет, возможно, в вашем экземпляре используются устаревшие сетевые драйверы, которые могут вызывать некоторые сбои.

Если вы хотите изучить это, вы можете попытаться перестроить весь сервер базы данных с нуля на только что запущенном AMI. В качестве альтернативы вы можете обновить драйвер PV, сетевой адаптер и EC2Config в существующем экземпляре. Инструкции можно найти по следующим ссылкам:

https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/Upgrading_PV_drivers.html#aws-pv-upgrade

https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/sriov-networking.html#enable-enhanced-networking

https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/UsingConfig_Install.html

person Elliot Nelson    schedule 21.12.2018
comment
Что ж, мы клонировали сервер Linux, а не сервер БД, поскольку это сложно сделать в нашей текущей настройке производственной системы. Но я посмотрю, сможем ли мы обновить этот сервер, спасибо за информацию. Что касается повторных попыток: мы аварийно завершаем работу, чтобы убедиться, что следующие запросы смогут нормально подключиться (так всегда и бывает). Я обновлю одну службу, которая повторит попытку подключения и посмотрит, что произойдет. - person timgeudens; 21.12.2018