ColdFusion po aktualizacji MariaDB: „Attempted reconnect 3 times. Giving up.” z Connector/J 5.1 i przejście na MariaDB Connector/J

Po przejściu MariaDB z gałęzi 10.11 na nowszą ColdFusion z ręcznie dodanym MySQL Connector/J 5.1.44 przestał łączyć się z bazą: każde zapytanie kończyło się po 4 s błędem „Could not create connection to database server”. Winny był nowy nagłówek wersji serwera, przez który sterownik sam włączał TLS w wersji blokowanej przez Javę 21. Źródła danych przepiął jeden skrypt na MariaDB Connector/J.

Umów rozmowę wstępną ColdFusion i Lucee w Prownex

Connector/J 5.1.38 do 5.1.45: 0 połączeń z MariaDB od 11.0, 4 s do błędu
Aktualizacja 10.11.3 na 10.11.19 w Debianie 12: zero różnic dla sterownika
Po restarcie bazy 8 z 12 żądań z błędem, z walidacją połączeń 0 z 12

Aplikacja webowa na Adobe ColdFusion 2025 (Java 21) z MariaDB na tym samym serwerze z Debianem 12 i sterownikiem MySQL Connector/J 5.1

Wyzwanie

Aplikacja na Adobe ColdFusion 2025 łączyła się z MariaDB na tym samym serwerze przez kilka źródeł danych typu „Other”. Sterownik MySQL Connector/J 5.1.44 z 2017 roku ktoś kiedyś dodał ręcznie do cfusion/lib, tak jak opisuje to baza wiedzy Adobe. Przez lata nikt nie musiał o nim pamiętać.

Po przejściu MariaDB z gałęzi 10.11 na nowszą każda strona, która czytała dane, czekała 4 sekundy i kończyła się błędem „Could not create connection to database server. Attempted reconnect 3 times. Giving up.” Sama baza działała, administrator logował się bez problemu. Słowa „NonTransient” i „reconnect” kierowały w stronę sieci, ale błąd powtarzał się przy każdej próbie.

Ograniczenia: nazwy źródeł danych zostają, bo używa ich kod CFML, dane mają wyglądać jak przed zmianą, a aplikacja działa produkcyjnie, więc każdą zmianę sprawdzamy przed przełączeniem.

Rozwiązanie

Przyczyna siedziała w nagłówku wersji serwera. MariaDB 10.x przedstawia się z prefiksem zgodności 5.5.5-, od 11.0.1 już bez niego. Connector/J 5.1 uznał więc serwer za MySQL od 5.7, sam włączył TLS i zaproponował tylko TLSv1.1 i TLSv1, które Java 21 w ColdFusion 2025 ma wyłączone. Połączenie kończyło się po stronie aplikacji, zanim cokolwiek trafiło do bazy.

Stary sterownik zastąpił MariaDB Connector/J 3.5.11 w cfusion/lib (stan na 2026-11). Jeden skrypt Admin API przepiął wszystkie źródła danych: typ „Other”, adres jdbc:mariadb://…?tinyInt1isBit=false, klasa org.mariadb.jdbc.Driver, te same nazwy, użytkownicy i hasła, po każdym źródle weryfikacja. Doszła walidacja połączeń zapytaniem SELECT 1. Przed oddaniem sprawdziliśmy zapytania, transakcje, procedury składowane, kolumny TINYINT(1) i daty zerowe.

Wyniki

Connector/J 5.1.44 po zmianie gałęzi MariaDB: 100 % zapytań z błędem, 4,03 s do błędu
Po przejściu na MariaDB Connector/J 3.5: 7 z 7 źródeł z verifyDsn = YES, zapytania i transakcje bez błędów
Wersje Connector/J 5.1 na MariaDB 11.8 i 13.0: 8 z 15 bez połączenia, 4 po TLS bez weryfikacji, 3 bez zmian
Aktualizacja 10.11.3 na 10.11.19 w Debianie 12: 0 różnic w działaniu sterownika
Błędy po restarcie bazy, 8 połączeń w puli: 8 z 12 bez walidacji, 0 z 12 z „Validate connection”
TINYINT(1) po przepięciu: 0, 1, 2 jak przed zmianą (bez tinyInt1isBit=false: NO, YES, YES)

Jak pracowaliśmy

Logi ColdFusion

application.log, exception.log z pełnym stacktrace i coldfusion-error.log z komunikatami sterownika. Ostatnie ogniwo łańcucha wyjątków wskazało TLS.
Sonda JDBC poza ColdFusion

Mały program w Javie, ta sama Java 21.0.10: łączy się podanym sterownikiem, wypisuje wersję serwera i wykonuje zapytania typowe dla aplikacji, od odczytu z polskimi znakami po procedurę składowaną.
Najpierw najprostsza hipoteza

Aktualizacja w ramach Debiana 12: wersja z wydania bookworm 1:10.11.3-1, bieżąca 1:10.11.19-0+deb12u1 i serwer zaktualizowany na miejscu przy podłączonym ColdFusion, z restartem usługi jak przy apt upgrade.
Nowsze gałęzie MariaDB

11.4.13, 11.8.8, 12.3.3 i 13.0.2 z kompilacji producenta oraz 11.8.6 z pakietu Debiana 13.
Macierz sterowników

MySQL Connector/J 5.0.8, 5.1.17, 5.1.27 i 15 wydań od 5.1.34 do 5.1.49, MariaDB Connector/J 2.7.15, 3.5.10, 3.5.11 i 4.0.0.
Kod sterownika

Bajtkod klas MysqlIO i ExportControlled z wersji 5.1.45, 5.1.46 i 5.1.49 (javap -c), żeby potwierdzić, skąd bierze się TLS i lista protokołów.
Migracja i różnice w danych

Te same zapytania i typy danych, TINYINT(1), BIT i daty zerowe, przez stary i nowy sterownik, w ColdFusion i poza nim.

Który sterownik łączy się z którą MariaDB (Java 21, stan na 2026-11)

Sterownik	MariaDB 10.11 z Debiana 12, bez TLS	MariaDB 11.4 do 13.0
MySQL Connector/J 5.0.8, 5.1.17, 5.1.34 do 5.1.37	Działa	Działa, bez TLS
MySQL Connector/J 5.1.38 do 5.1.45	Działa	Brak połączenia: Communications link failure, przyczyna SSLHandshakeException: No appropriate protocol
MySQL Connector/J 5.1.46 do 5.1.49	Działa	Działa po TLS bez weryfikacji certyfikatu, ostrzeżenie w logu przy każdym połączeniu
MariaDB Connector/J 3.5.11, jdbc:mariadb://	Działa	Działa
MariaDB Connector/J 3.5.11, stary adres jdbc:mysql://	No suitable driver found for jdbc:mysql://… (działa dopiero z permitMysqlScheme)	Tak samo
MariaDB Connector/J 4.0.0, jdbc:mariadb://	Trying to connect with ssl, but ssl not enabled in the server	Działa
MariaDB Connector/J 4.0.0 z sslMode=disable	Działa	Działa

Wyzwania, które pokonaliśmy

Komunikat w application.log opisywał ostatni objaw, nie przyczynę. Poniżej wpisy z logów tak, jak je zapisał ColdFusion; uogólnione są tylko ścieżka pliku CFML i nazwa wątku.

Dokładne wpisy z logów

application.log, przy każdym żądaniu:

"Error","...-exec-6","11/02/26","17:40:29","","Error Executing Database Query.Could not create connection to database server. Attempted reconnect 3 times. Giving up. The specific sequence of files included or processed is: /app/wwwroot/katalog.cfm, line: 15 Could not create connection to database server. Attempted reconnect 3 times. Giving up."

exception.log, pełny łańcuch wyjątków (ramki JDK, Tomcata i filtrów ColdFusion pominięte i oznaczone ...):

coldfusion.tagext.sql.QueryTag$DatabaseQueryException: Error Executing Database Query.
    at coldfusion.tagext.sql.QueryTag.startQueryExecution(QueryTag.java:853)
    at coldfusion.tagext.sql.QueryTag.doEndTag(QueryTag.java:750)
    ...
Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: Could not create connection to database server. Attempted reconnect 3 times. Giving up.
    ...
    at com.mysql.jdbc.Util.handleNewInstance(Util.java:425)
    at com.mysql.jdbc.Util.getInstance(Util.java:408)
    at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:918)
    at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:897)
    at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:886)
    at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:860)
    at com.mysql.jdbc.ConnectionImpl.connectWithRetries(ConnectionImpl.java:2097)
    at com.mysql.jdbc.ConnectionImpl.createNewIO(ConnectionImpl.java:2022)
    at com.mysql.jdbc.ConnectionImpl.<init>(ConnectionImpl.java:779)
    at com.mysql.jdbc.JDBC4Connection.<init>(JDBC4Connection.java:47)
    ...
    at com.mysql.jdbc.Util.handleNewInstance(Util.java:425)
    at com.mysql.jdbc.ConnectionImpl.getInstance(ConnectionImpl.java:389)
    at com.mysql.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:330)
    at coldfusion.server.j2ee.sql.pool.JDBCPool.createPhysicalConnection(JDBCPool.java:614)
    at coldfusion.server.j2ee.sql.pool.ConnectionRunner$RunnableConnection.run(ConnectionRunner.java:59)
    ... 1 more
Caused by: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure

The last packet successfully received from the server was 1 milliseconds ago.  The last packet sent successfully to the server was 1 milliseconds ago.
    ...
    at com.mysql.jdbc.Util.handleNewInstance(Util.java:425)
    at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:989)
    at com.mysql.jdbc.ExportControlled.transformSocketToSSLSocket(ExportControlled.java:203)
    at com.mysql.jdbc.MysqlIO.negotiateSSLConnection(MysqlIO.java:4901)
    at com.mysql.jdbc.MysqlIO.proceedHandshakeWithPluggableAuthentication(MysqlIO.java:1659)
    at com.mysql.jdbc.MysqlIO.doHandshake(MysqlIO.java:1226)
    at com.mysql.jdbc.ConnectionImpl.coreConnect(ConnectionImpl.java:2191)
    at com.mysql.jdbc.ConnectionImpl.connectWithRetries(ConnectionImpl.java:2038)
    ... 12 more
Caused by: javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)
    ...
    at com.mysql.jdbc.ExportControlled.transformSocketToSSLSocket(ExportControlled.java:188)
    ... 17 more

coldfusion-error.log, komunikaty sterownika:

Mon Nov 02 17:40:25 CET 2026 WARN: Establishing SSL connection without server's identity verification is not recommended. According to MySQL 5.5.45+, 5.6.26+ and 5.7.6+ requirements SSL connection must be established by default if explicit option isn't set. For compliance with existing applications not using SSL the verifyServerCertificate property is set to 'false'. You need either to explicitly disable SSL by setting useSSL=false, or set useSSL=true and provide truststore for server certificate verification.
SQLException while attempting to connect: com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: Could not create connection to database server. Attempted reconnect 3 times. Giving up..

Nie aktualizacja w Debianie 12, tylko granica 11.0

Między pakietami 1:10.11.3-1 i 1:10.11.19-0+deb12u1 nie ma różnicy dla Connector/J 5.1: każda sprawdzona wersja sterownika zachowywała się identycznie, także po aktualizacji na miejscu. Sterownik widzi oba serwery jako MySQL 5.5.5-10.11…, a mariadb-upgrade po aktualizacji w obrębie gałęzi nic nie robi. Decyduje prefiks 5.5.5-, którego od MariaDB 11.0.1 nie ma (MDEV-28910). Serwery od 11.4 ogłaszają przy tym TLS bez żadnej konfiguracji, z certyfikatem generowanym przy starcie.

Ten sam „Connector/J 5” zachowuje się na trzy sposoby

Na MariaDB od 11.0 wydania do 5.1.37 łączą się bez TLS, od 5.1.38 do 5.1.45 nie łączą się wcale, a od 5.1.46 do 5.1.49 łączą się po TLS bez weryfikacji certyfikatu i przy każdym nowym połączeniu dopisują do coldfusion-error.log kilkuzdaniowe ostrzeżenie. Dwa serwery z „tym samym” sterownikiem mogą się więc różnić. Wersję sprawdzamy w manifeście jara (Implementation-Version: 5.1.44), nie w nazwie katalogu.

Lista protokołów TLS siedzi w sterowniku

W wydaniach od 5.1.38 do 5.1.45 klasa ExportControlled proponuje TLSv1.2 tylko serwerom MySQL od 5.6 w edycji Enterprise. Każdy inny serwer dostaje TLSv1.1,TLSv1. Java 21 ma oba protokoły w jdk.tls.disabledAlgorithms (w Oracle JDK od 11.0.11), więc uzgadnianie kończy się błędem „No appropriate protocol”, zanim cokolwiek trafi do serwera. Od 5.1.46 TLSv1.2 dostają także serwery od 8.0.4.

„NonTransient” i „reconnect” kierują w stronę sieci

ColdFusion otwiera fizyczne połączenie przez connectWithRetries, nawet bez autoReconnect=true w adresie. Sterownik próbuje trzy razy, każde żądanie czeka 4,03 s na błąd, a przy ruchu wątki ColdFusion zajmują się głównie czekaniem. Prawdziwa przyczyna to trzecie Caused by w exception.log. Sprawdzanie zapory czy limitu połączeń w bazie to tu strata czasu.

Typ „MySQL” w ColdFusion 2025 to ślepa uliczka

Typ „MySQL” oczekuje klasy com.mysql.cj.jdbc.Driver, czyli Connector/J 8 lub nowszego, którego Adobe nie dostarcza. Bez tego jara źródło zwraca „No suitable driver available for … The mysql package is not installed.”, a cfpm.sh install mysql odpowiada „mysql(2025.0.08.331874) package is already installed.”, bo pakiet mysql to sterownik DataDirect. Właściwa droga to typ „Other”, jak w bazie wiedzy Adobe.

Podmiana jara nie wystarcza, a najnowszy sterownik ma inne domyślne TLS

MariaDB Connector/J 3.x i 4.x rejestruje się tylko dla jdbc:mariadb:; stary adres jdbc:mysql:// kończy się „No suitable driver found”, dlatego każde źródło danych trzeba zmienić. Wersja 4.0.0 z października 2026 wymaga Javy 17 i domyślnie ma sslMode=verify-full. Z bazą Debiana 12 bez TLS kończy się błędem:

java.sql.SQLNonTransientConnectionException: (conn=52) Trying to connect with ssl, but ssl not enabled in the server. TLS is enabled by default, set sslMode=disable to permit unencrypted connection

„Other” zmienia typy danych

Typ „MySQL” dokleja do adresu tinyInt1isBit=false, „Other” nie. Bez tego obie rodziny sterowników zwracają TINYINT(1) jako Boolean, a ColdFusion pokazuje wartości 0, 1, 2 jako NO, YES, YES. Daty 0000-00-00 00:00:00 Connector/J 5.1 zgłaszał błędem „Value '0000-00-00 00:00:00' can not be represented as java.sql.Timestamp”, MariaDB Connector/J zwraca pustą wartość. Kod, który polegał na jednym albo drugim, zachowa się inaczej.

Każdy restart bazy zostawia w puli martwe połączenia

Aktualizacja pakietu restartuje MariaDB, a ColdFusion trzyma połączenia otwarte. Każde z nich daje jeden błąd przy pierwszym użyciu: przy 8 połączeniach w puli 8 z 12 kolejnych żądań skończyło się błędem, w obu rundach. Ten sam objaw po zwykłej aktualizacji w obrębie 10.11 łatwo wziąć za awarię sterownika:

"Error","...-exec-5","11/02/26","17:34:39","","Datasource shop verification failed.The root cause was that: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure

The last packet successfully received from the server was 31,181 milliseconds ago.  The last packet sent successfully to the server was 0 milliseconds ago. ..."
"Error","...-exec-1","11/02/26","17:34:39","","Error Executing Database Query.(conn=13) Socket error The specific sequence of files included or processed is: /app/wwwroot/katalog.cfm, line: 15 (conn=13) Socket error"

Pierwszy wpis pochodzi z Connector/J 5.1, drugi z MariaDB Connector/J; jego przyczyna w exception.log to java.io.EOFException: unexpected end of stream, read 0 bytes from 4 (socket was closed by server). „Validate connection” z zapytaniem SELECT 1 usunęło te błędy całkowicie, 0 z 12.

Dwa rzędy po piętnaście kwadratów dla wydań Connector/J od 5.1.34 do 5.1.49. Rząd MariaDB 10.11: wszystkie kwadraty czarne. Rząd MariaDB 11.8: trzy czarne, osiem pomarańczowych obrysów z krzyżykiem, cztery kwadraty z kłódką pod nawiasem TLS

Przejście na MariaDB Connector/J krok po kroku

Sterownik

MariaDB Connector/J 3.5.11 trafia do cfusion/lib, a stary jar znika: dwa sterowniki obsługujące jdbc:mysql: w jednym katalogu to proszenie się o kłopoty. Potem restart ColdFusion.

unzip -p cfusion/lib/mysql-connector-java-*.jar META-INF/MANIFEST.MF | grep Implementation-Version
cp mariadb-java-client-3.5.11.jar /opt/ColdFusion2025/cfusion/lib/
rm /opt/ColdFusion2025/cfusion/lib/mysql-connector-java-5.1.44.jar
systemctl restart <usługa ColdFusion>

Gałąź 3.5 wybraliśmy świadomie: działa na każdej Javie od 8, nie wymaga TLS od bazy na localhost i jest utrzymywana równolegle z 4.0 (stan na 2026-11). Na ColdFusion z Javą 17 lub 21 można użyć 4.0, ale wtedy trzeba skonfigurować TLS na serwerze bazy albo jawnie dopisać sslMode=disable dla połączenia lokalnego.

Źródło danych w ColdFusion Administrator

Data & Services, Data Sources, sterownik „Other”, adres JDBC:

jdbc:mariadb://127.0.0.1:3306/<baza>?tinyInt1isBit=false

Pozostałe pola:

Pole	Wartość
CF Data Source Name	bez zmian (używa jej kod)
JDBC URL	adres powyżej
Driver Class	`org.mariadb.jdbc.Driver`
Driver Name	MariaDB Connector/J
User name, Password	bez zmian
Maintain connections	włączone
Validate connection, Validation Query	włączone, `SELECT 1`

Wszystkie źródła jednym skryptem

Skrypt Admin API uruchamiamy raz z localhost, najpierw z run=0 do podglądu, potem z run=1. ColdFusion przed zapisem robi kopię neo-datasource.bak, własna kopia neo-datasource.xml też nie zaszkodzi.

<cfset createObject("component","CFIDE.adminapi.administrator").login(adminPassword="...", adminUserId="admin")>
<cfset dsApi = createObject("component","CFIDE.adminapi.datasource")>
<cfset all = dsApi.getDatasources()>
<cfloop collection="#all#" item="name">
  <cfset d = all[name]>
  <cfif NOT listFindNoCase("com.mysql.jdbc.Driver,com.mysql.cj.jdbc.Driver", d.class) AND d.driver NEQ "MySQL5">
    <cfcontinue>
  </cfif>
  <cfset newUrl = reReplace(reReplaceNoCase(d.url, "^jdbc:mysql:", "jdbc:mariadb:"), "[&?]$", "")>
  <cfif NOT findNoCase("tinyInt1isBit", newUrl)>
    <cfset newUrl &= (find("?", newUrl) ? "&" : "?") & "tinyInt1isBit=false">
  </cfif>
  <cfoutput>#name#: #d.url# -> #newUrl##chr(10)#</cfoutput>
  <cfif url.run EQ 1>
    <cfset dsApi.setOther(name=name, url=newUrl, class="org.mariadb.jdbc.Driver", driver="Other",
      username=d.username, password=d.password, encryptpassword=false,
      description=d.description, pooling=d.pooling, timeout=d.timeout, interval=d.interval,
      login_timeout=d.login_timeout, buffer=d.buffer, blob_buffer=d.blob_buffer,
      disable_clob=d.disable_clob, disable_blob=d.disable_blob, validationQuery=d.validationQuery,
      select=d.select, create=d.create, grant=d.grant, insert=d.insert, drop=d.drop, revoke=d.revoke,
      update=d.update, alter=d.alter, storedproc=d.storedproc, delete=d.delete)>
    <cfoutput>  verify: #dsApi.verifyDsn(dsn=name, returnMsgOnError=true)##chr(10)#</cfoutput>
  </cfif>
</cfloop>

Klucz to encryptpassword=false: getDatasources() zwraca hasło już zaszyfrowane, więc skrypt przenosi je bez znajomości haseł do baz, razem z uprawnieniami SQL źródła i ustawieniami CLOB i BLOB. Wynik: 7 źródeł przepiętych, verify: YES przy każdym. Walidację połączeń włącza Administrator albo to samo wywołanie setOther z validateConnection=true, validationQuery="SELECT 1". Plik ze skryptem usuwamy z serwera zaraz po użyciu, bo zawiera hasło administratora.

Weryfikacja przed oddaniem

Zapytania odczytu, cftransaction z UPDATE, procedury składowane, kolumny TINYINT(1) z wartościami 0, 1, 2 jak przed zmianą i miejsca, w których kod sprawdza daty zerowe. Przy procedurach różnica wyszła na plus: Connector/J 5.1 przy procedurze założonej przez innego użytkownika zgłaszał „User does not have access to metadata required to determine stored procedure parameter types”, MariaDB Connector/J nie potrzebuje dostępu do jej treści.

Obejście na czas przygotowania migracji

Gdy przepięcie musi poczekać, a baza jest na tym samym serwerze, Connector/J od 5.1.38 do 5.1.45 łączy się z MariaDB od 11.0 po dopisaniu useSSL=false do adresu; enabledTLSProtocols=TLSv1.2 działa dopiero od 5.1.44. To obejście, nie rozwiązanie: sterownik jest poza rozwojem od 2021 roku.

Przed kolejną aktualizacją bazy

mariadb -e "SELECT VERSION()"                      # 10.x czy 11.x i nowsze
apt-cache policy mariadb-server                    # skąd pakiet i na jaką wersję się zmieni
grep -cE "Attempted reconnect|Communications link failure|NonTransientConnection" /opt/ColdFusion2025/cfusion/logs/exception.log
grep -c "Establishing SSL connection without" /opt/ColdFusion2025/cfusion/logs/coldfusion-error.log

Arkusz z podpisem Admin API, od którego pomarańczowa szyna prowadzi siedmioma równymi torami do siedmiu małych baz danych, nad torami napis jdbc:mariadb, przy każdej bazie haczyk

Co z tego wynika

Ręcznie dodany sterownik JDBC to zależność, o której nikt nie pamięta, dopóki baza nie zmieni gałęzi. Connector/J 5.1 jest poza rozwojem od 2021 roku i czekał tylko na pierwszą zmianę, której nie przetrwa. Takie znaleziska są typowe przy przejęciu i utrzymaniu systemu.
Komunikat ColdFusion opisuje ostatni objaw, nie przyczynę. Tu przyczyna była trzecim Caused by, a słowa „NonTransient” i „reconnect” prowadziły w stronę sieci.
Przejście na MariaDB Connector/J to więcej niż podmiana pliku. Inny schemat adresu, inna klasa, inne domyślne TLS w 4.0 i inne mapowanie typów niż w typie „MySQL”. Skrypt Admin API robi to powtarzalnie i od razu weryfikuje.
Walidacja połączeń w puli kosztuje jedno lekkie zapytanie i usuwa błędy po każdym restarcie bazy, także po zwykłej aktualizacji bezpieczeństwa.
Aktualizację bazy planujemy razem z aplikacją. Wersja bazy przed i po, wersja sterownika z manifestu jara i trzy frazy w logach ColdFusion, nie tylko w logu bazy.

Ta sama para ColdFusion i MariaDB Connector/J pod dużym obciążeniem to projekt JVM heap space; instalację ColdFusion 2025 Update 8 za Apache opisuje projekt ColdFusion 2025, a pracę na samej bazie MariaDB projekt indeksów SQL.

Po aktualizacji bazy aplikacja ColdFusion przestała łączyć się z MariaDB albo w logach pojawia się „Attempted reconnect 3 times. Giving up.”? Ustalimy przyczynę na podstawie logów, przepniemy źródła danych na aktualny sterownik bez zmian w kodzie i sprawdzimy dane przed i po. Pierwszy krok to rozmowa wstępna.

Źródła

Informacje o wersjach i wartościach domyślnych pochodzą z publikacji producentów (stan: 2026-11):

Dwa rzędy po dwanaście kwadratów żądań po restarcie bazy. Górny rząd bez bramki: pierwsze osiem kwadratów to pomarańczowe obrysy z krzyżykiem, cztery czarne. Dolny rząd przechodzi przez bramkę z napisem SELECT 1: wszystkie dwanaście kwadratów czarne

Powiązane sytuacje

ColdFusion: koniec wsparcia i dostępne opcje

Firma Adobe wystosowała oficjalny komunikat: od 10 listopada 2025 r. ColdFusion 2021 nie otrzymuje poprawek bezpieczeństwa. Porównujemy cztery rozwiązania z terminami i ryzykiem (stan: 2026-10): zostać i zabezpieczyć instalację, zaktualizować do wspieranej wersji, przejść na rozwiązanie open source Lucee albo stopniowo zastąpić cały system.
Przejęcie systemu bez dokumentacji

Państwa system działa, ale nikt nie zna go dokładnie. Spisujemy aplikację, bazę danych, serwer i pocztę, oceniamy ryzyka, na piśmie rekomendujemy dalszą drogę, a na życzenie przejmujemy utrzymanie systemu.
Aktualizacja Debiana i migracja z CentOS

Wsparcie Debiana 11 zakończyło się 31.08.2026, a CentOS 7 już 30.06.2024 (stan: 2026-10). Zaktualizujemy Państwa serwer albo zaplanujemy i wykonamy przejście na Debiana. Pracujemy również z Proxmox VE 8 i z serwerami fizycznymi, które przenosimy na Proxmox.

Inne projekty

Kopia bazy MySQL miała 751 bajtów: uszkodzona tabela MyISAM i test przywracania

Skrypt z crona przez 7 nocy zapisywał zamiast ok. 280 MB plik 751 B: jedna tabela MyISAM była oznaczona jako uszkodzona, mysqldump przerywał na LOCK TABLES, skrypt kończył się kodem 0, a cron wyrzucał komunikat. Odtworzyliśmy awarię, naprawiliśmy tabelę, przenieśliśmy bazy na InnoDB i wdrożyliśmy kopię, która co noc próbnie się przywraca i alarmuje.
Filtr antyspamowy, który działał, ale nie chronił

Usługi uruchomione, konfiguracja poprawna, w statusie systemu żadnych błędów. A mimo to phishing lądował w skrzynkach odbiorczych, a newslettery partnerów w folderze spam. Nasi inżynierowie zmierzyli, które mechanizmy wykrywania naprawdę działają, usunęli przyczyny, a trzy miesiące później znaleźli i naprawili regresję, którą było widać dopiero w ujęciu godzinowym.

W 20 minut ustalimy, jaki pierwszy krok pasuje do Państwa systemu

Państwo opisują cel i obecny stan, my mówimy otwarcie, czy i jak możemy pomóc. Odpowiedź w ciągu jednego dnia roboczego, bez zobowiązań.

Umów rozmowę wstępną Jak pracujemy

Telefon (niemiecki, polski, angielski) +48 501 250 220

E-mail E-mail

Dostępni: poniedziałek–piątek, 9:00–17:00 (czas środkowoeuropejski); wsparcie i awarie całą dobę (24/7)

Wyzwanie

Rozwiązanie

Wyniki

Jak pracowaliśmy

Logi ColdFusion

Sonda JDBC poza ColdFusion

Najpierw najprostsza hipoteza

Nowsze gałęzie MariaDB

Macierz sterowników

Kod sterownika

Migracja i różnice w danych