Otrzymujemy informację, że są problemy z działaniem bazy danych. MySQL zwraca błąd, że wyczerpały się limity połączeń. Szybki rzut okiem na obciążenie serwera – może jakieś ciężkie zapytanie przyblokowało pozostałe? Nie tym razem, serwer okazuje się mieć duży zapas mocy, nie widać żadnego skoku obciążenia czy to na dysku, czy to na CPU. SHOW PROCESSLIST pokazuje faktycznie dużą ilość połączeń od “unauthenticated user” wiszących na poleceniu “Connect” i w stanie “reading from net”. O co chodzi?

Tego typu objawy świadczą najpewniej o jednym. Serwer DNS, z którego korzysta serwer MySQL, uznał, że pora przestać działać. Jak wiemy, MySQL umożliwia nadawanie uprawnień dla poszczególnych użytkowników w zależności od tego, z jakiego hosta nawiązywane jest połączenie. Użytkownik ‘jas@example.com’ może mieć kompletnie inne uprawnienia niż użytkownik ‘jas@test.example.com’. Aby sprawdzić z jakiego hosta łączy się dany użytkownik, konieczny jest dostęp do serwera DNS. Jeśli serwer MySQL nie będzie w stanie uzyskać takiego dostępu, nie jest w stanie wykonać poprawnego procesu autoryzacji. Co prawda połączenie jest nawiązywane i nowy wątek do jego obsługi jest tworzony, to całość zacina się na etapie połączenia z DNS i autoryzacji. Efektem są właśnie wątki utworzone przez “unauthenticated user”.

W jaki sposób można rozwiązać ten problem? Jedyną opcją, która zagwarantuje że do tego typu sytuacji nie dojdzie, jest wyłączenie rozwiązywania nazw przez MySQL. Służy do tego zmienna skip_name_resolve. W efekcie tracimy możliwość wykorzystywania nazw hostów do procesu autoryzacji – po włączeniu tej zmiennej jako host do autoryzacji można stosować tylko i wyłącznie adresy IP. Jest to oczywiście pewne utrudnienie, w niektórych środowiskach tego typu autoryzacja jest bardzo przydatna, ale za to możemy być pewni, że pad DNS nie będzie skutkował przerwą w działaniu MySQL.