5

Uruchomiliśmy interfejs API Sails.js w Google Container Engine z bazą danych Cloud SQL, a ostatnio odkryliśmy, że niektóre z naszych punktów końcowych uległy zwłoce, nigdy nie wysyłając odpowiedzi.Google Cloud SQL Brak odpowiedzi

Posiadałem kontrolę stanu zdrowia/v1/status i uzyskałem 100% uptime, gdy miałem następującą prostą odpowiedź;

status: function(req, res){ 
    res.ok('Welcome to the API');  
} 

Gdy tylko dodaliśmy zapytanie do bazy danych, punkt końcowy zaczął upływać. Nie zdarza się to cały czas, ale pozornie w przypadkowych odstępach czasu, czasem po wiele godzin. Właśnie to zmieniliśmy zapytanie na;

status: function(req, res){ 
    Email.findOne({ value: "[email protected]" }).then(function(email){ 
     res.ok('Welcome to the API'); 
    }).fail(function(err){ 
     res.serverError(err); 
    }); 
} 

raczej podejrzanie, to wszystko działa dobrze w naszych warunkach postoju i rozwojowych, to tylko wtedy, gdy kod jest rozmieszczony w produkcji który występuje limit czasu i to występuje tylko raz na jakiś czas . Jedyną rzeczą, która zmienia się pomiędzy wystawieniem i produkcją, jest baza danych, z którą się łączymy i obciążenie serwera.

Jak wspomniałem wcześniej, używamy adaptera Google Cloud SQL i Sails-MySQL. Mamy następujące stosy błędów z serwera produkcyjnego;

AdapterError: Invalid connection name specified 
at getConnectionObject (/app/node_modules/sails-mysql/lib/adapter.js:1182:35) 
at spawnConnection (/app/node_modules/sails-mysql/lib/adapter.js:1097:7) 
at Object.module.exports.adapter.find (/app/node_modules/sails-mysql/lib/adapter.js:801:16) 
at module.exports.find (/app/node_modules/sails/node_modules/waterline/lib/waterline/adapter/dql.js:120:13) 
at module.exports.findOne (/app/node_modules/sails/node_modules/waterline/lib/waterline/adapter/dql.js:163:10) 
at _runOperation (/app/node_modules/sails/node_modules/waterline/lib/waterline/query/finders/operations.js:408:29) 
at run (/app/node_modules/sails/node_modules/waterline/lib/waterline/query/finders/operations.js:69:8) 
at bound.module.exports.findOne (/app/node_modules/sails/node_modules/waterline/lib/waterline/query/finders/basic.js:78:16) 
at bound [as findOne] (/app/node_modules/sails/node_modules/lodash/dist/lodash.js:729:21) 
at Deferred.exec (/app/node_modules/sails/node_modules/waterline/lib/waterline/query/deferred.js:501:16) 
at tryCatcher (/app/node_modules/sails/node_modules/waterline/node_modules/bluebird/js/main/util.js:26:23) 
at ret (eval at <anonymous> (/app/node_modules/sails/node_modules/waterline/node_modules/bluebird/js/main/promisify.js:163:12), <anonymous>:13:39) 
at Deferred.toPromise (/app/node_modules/sails/node_modules/waterline/lib/waterline/query/deferred.js:510:61) 
at Deferred.then (/app/node_modules/sails/node_modules/waterline/lib/waterline/query/deferred.js:521:15) 
at Strategy._verify (/app/api/services/passport.js:31:7) 
at Strategy.authenticate (/app/node_modules/passport-local/lib/strategy.js:90:12) 
at attempt (/app/node_modules/passport/lib/middleware/authenticate.js:341:16) 
at authenticate (/app/node_modules/passport/lib/middleware/authenticate.js:342:7) 
at Object.AuthController.login (/app/api/controllers/AuthController.js:119:5) 
at bound (/app/node_modules/sails/node_modules/lodash/dist/lodash.js:729:21) 
at routeTargetFnWrapper (/app/node_modules/sails/lib/router/bind.js:179:5) 
at callbacks (/app/node_modules/sails/node_modules/express/lib/router/index.js:164:37) 

Error (E_UNKNOWN) :: Encountered an unexpected error : 
Could not connect to MySQL: Error: Pool is closed. 
at afterwards (/app/node_modules/sails-mysql/lib/connections/spawn.js:72:13) 
at /app/node_modules/sails-mysql/lib/connections/spawn.js:40:7 
at process._tickDomainCallback (node.js:381:11) 

Patrząc na samych błędów, chciałbym mieć pokusę, aby powiedzieć, że mamy coś źle skonfigurowanego. Ale fakt, że działa przez jakiś czas (i wcześniej działał dobrze!), Pozwala mi wierzyć, że działa tu jakaś inna czarna magia. Nasza instancja Cloud SQL to D0 (chociaż próbowaliśmy podnieść rozmiar do D4), a nasza polityka aktywacji to "Always On".

EDYCJA: Widziałem, jak inni narzekają na Google Cloud SQL, np. this SO post i byłem podejrzliwy, ale od tego czasu przenieśliśmy naszą bazę danych do Amazon RDS i nadal widzimy te same problemy, więc musi to być problem z żaglami i adapterem mysql.

Ten problem prowadzi do godzin przestoju w ciągu dnia, potrzebujemy go rozwiązać, każda pomoc jest doceniana!

Odpowiedz

1

Czy jest jakiś sposób osiągnięcia limitu QPS dla Google Cloud SQL? Zobacz poniżej: https://cloud.google.com/sql/faq#sizeqps

+0

W łączu wyjaśnia, że ​​nie ma limitu QPS, ale maksymalny limit równoczesnych połączeń. Używamy instancji D0, która ma limit równy 250 równoczesnych połączeń, z których najwięcej korzystaliśmy już 12. Dziękujemy za sugestię! –

1

Dlaczego moja instancja bazy danych czasami nie odpowiada? Aby zminimalizować kwotę naliczaną za wystąpienia w poszczególnych planach użytkowania, domyślnie instancja staje się pasywna, jeśli nie jest dostępna przez 15 minut. Przy następnym dostępie nastąpi krótkie opóźnienie, gdy zostanie aktywowane. Możesz zmienić to zachowanie, konfigurując politykę aktywacji instancji. Na przykład zobacz Edytowanie instancji przy użyciu Cloud SDK.

Może to być związane z ustawieniem zasad. Jeśli ustawisz go na ON_DEMAND, instancja będzie spać, aby zapisać budżet, tak aby pierwsze zapytanie aktywujące wystąpienie było wolne. Może to spowodować przekroczenie limitu czasu.

https://cloud.google.com/sql/faq?hl=en

+0

Dzięki za sugestię, ale nie używamy zasady aktywacji "Zawsze w", dodam tę informację do mojego pytania. –

2

To wydaje się być sails issue, niekoniecznie związane z Cloud SQL.

+0

Dzięki Nick! Przeszliśmy i przenieśliśmy całą bazę danych do Amazon RDS jako test, ale wciąż widzimy te same problemy. Tak jak mówisz, musi to być żagiel, choć ten problem jest dość stary. To może być to samo, przynajmniej teraz musimy coś przetestować! –