PmaControl logo PmaControl
  • Strona główna
  • Strona główna
    • PmaControl PmaControl
    • PmaControl PmaControl
    • PmaControl PmaControl
    • PmaControl PmaControl
    • Agenci AI Agenci AI
    Klienci
    • MariaDB 30 artykułów
    • MySQL 10 artykułów
    • Galera Cluster 6 artykułów
    • MaxScale 3 artykuły
    • ProxySQL 2 artykuły
    • Amazon Aurora MySQL 0 artykuły
    • Azure Database 0 artykuły
    • ClickHouse 0 artykuły
    • GCP CloudSQL 0 artykuły
    • Percona Server 0 artykuły
    • SingleStore 0 artykuły
    • TiDB 0 artykuły
    • Vitess 0 artykuły
    Bazy danych
    • Rozwiązania Rozwiązania
    • Observabilité SQL Rozwiązania
    • Haute disponibilité Rozwiązania
    • Disaster Recovery Rozwiązania
    • Sécurité & conformité Wsparcie 24×7
    • Migration & upgrade Wsparcie 24×7
  • PmaControl
  • Cennik
    • PmaControl Zasoby
    • Agenci AI Zasoby
    • Zasoby Zasoby
    • Zasoby Zasoby
    • Dokumentacja Dokumentacja
    Blog
    • Observabilité SQL Obszary ekspertyzy
    • Haute disponibilité Rozwiązania
    • Sécurité & conformité Obszary ekspertyzy
    • Disaster Recovery Rozwiązania
    • Performance & optimisation Obserwowalność SQL
    • Migration & upgrade Obserwowalność SQL
    Wydajność i optymalizacja
    • Szybkie linki Szybkie linki
    • Szybkie linki Szybkie linki
    • Rozwiązania Rozwiązania
    • Szybkie linki Szybkie linki
  • Rozwiązania
  • Szybkie linki
Szybkie linki
🇫🇷 FR Français 🇬🇧 EN English 🇵🇱 PL Polski 🇷🇺 RU Русский 🇨🇳 ZH 中文
← Powrót do bloga

SQLSTATE [HY000] [2006] Galera has gone away

Powrót do bloga February 27, 2026 Powrót do bloga Sylvain ARBAUDIE
galera mariadb open-source licensing
Powrót do bloga X LinkedIn Facebook Email PDF
SQLSTATE [HY000] [2006] Galera has gone away

Komunikat o błędzie, który stał się rzeczywistością

SQLSTATE [HY000] [2006] MySQL server has gone away to jeden z najbardziej znanych komunikatów o błędach w ekosystemie MariaDB / MySQL. Każdy DBA napotkał go przynajmniej raz. Ale w 2026 to sama Galera zdaje się "gone away" — nie z powodu timeoutu sieciowego, lecz strategicznej decyzji MariaDB plc.

Wraz z wydaniem MariaDB 12.3 LTS synchroniczna replikacja Galera nie jest już uwzględniona w edycji społecznościowej. Komponent został przeniesiony pod licencję komercyjną, jako bezpośrednia konsekwencja przejęcia Codership, fińskiej firmy, która rozwija i utrzymuje bibliotekę Galera od 2007 roku.

Chronologia zapowiedzianego zniknięcia

Historia rozgrywa się w kilku aktach:

Czerwiec 2025 — MariaDB plc ogłasza przejęcie Codership. Na tym etapie oficjalny przekaz kładzie nacisk na ciągłość: Galera pozostaje GPLv2 dla społeczności, przejęcie ma na celu przyspieszenie rozwoju i integracji z MaxScale.

Koniec 2025 — Pierwsze gałęzie rozwojowe MariaDB 12.x pojawiają się bez pluginu wsrep. Kontrybutorzy społecznościowi sygnalizują zmianę na listach dyskusyjnych.

Luty 2026 — Wersja 12.3 LTS zostaje opublikowana. Galera Cluster jest oficjalnie nieobecna w edycji społecznościowej. Komunikat wyjaśnia, że komponent jest odtąd zarezerwowany dla MariaDB Enterprise Server, na licencji komercyjnej.

Dlaczego ta decyzja?

Z punktu widzenia MariaDB plc logika jest zrozumiała. Galera jest kluczowym wyróżnikiem w porównaniu z Oracle MySQL i PostgreSQL. Jest to jedna z nielicznych technologii synchronicznej replikacji multi-master dostępnych dla relacyjnych baz danych. I jest potężnym argumentem sprzedażowym dla oferty Enterprise.

Problem polega na tym, że Galera była również głównym argumentem za wyborem społecznościowej wersji MariaDB zamiast MySQL czy PostgreSQL. Tysiące architektur produkcyjnych opiera się na Galerze w wersji open-source. Narzędzia takie jak PmaControl, Percona XtraDB Cluster (który używa tej samej biblioteki Galera) i dziesiątki społecznościowych playbooków Ansible są zbudowane wokół tej funkcjonalności.

Reakcja społeczności

Społeczność zareagowała mieszanką gniewu i rezygnacji. Odezwało się kilka głosów:

Pragmatycy przypominają, że ostatnia wersja społecznościowa z Galerą (MariaDB 11.4) będzie wspierana do 2029 roku. Jest czas, by zaplanować migrację.

Zaniepokojeni wskazują na wzorzec: MaxScale przeszedł z GPLv2 na BSL w 2016, a następnie na czystą licencję komercyjną w 2025. Galera podąża tą samą drogą. Który komponent będzie następny?

Optymiści stawiają na MariaDB Foundation w kwestii utrzymania alternatywy. Fundacja, zatrudniająca około dwudziestu osób i skupiająca się na serwerze społecznościowym, mogłaby teoretycznie sforkować kod Galera w wersji, jaka istniała pod GPLv2.

Realiści zauważają, że utrzymanie tak złożonego systemu synchronicznej replikacji jak Galera wymaga bardzo specjalistycznej wiedzy i znacznych zasobów. Fork społecznościowy bez finansowania byłby trudny do utrzymania na dłuższą metę.

Alternatywy na stole

W obliczu tej sytuacji użytkownicy mają do dyspozycji kilka ścieżek:

1. Pozostać na MariaDB 11.4 z Galerą społecznościową

To rozwiązanie krótkoterminowe. MariaDB 11.4 LTS będzie utrzymywany do 2029 roku. To daje trzy lata na zaplanowanie dalszych kroków.

2. Migracja do replikacji asynchronicznej

Replikacja semi-synchroniczna MariaDB / MySQL oferuje akceptowalny kompromis dla wielu przypadków użycia. W połączeniu z proxy takim jak MaxScale lub ProxySQL umożliwia automatyczny failover. Nie gwarantuje jednak spójności wielowęzłowej, jaką oferowała Galera.

3. Eksploracja Percona XtraDB Cluster

Percona nadal oferuje rozwiązanie Galera na licencji open-source dla MySQL. Pojawia się jednak pytanie: bez Codership do utrzymywania bazowej biblioteki, jak długo Percona będzie w stanie utrzymywać własną integrację?

4. Przejście na edycję Enterprise MariaDB

To oczywiście opcja, na przyjęcie której MariaDB plc liczy. Koszt licencji należy zważyć wobec kosztu pełnej migracji architektury.

5. Rozważenie PostgreSQL

Dla nowych architektur PostgreSQL z rozwiązaniami klastrowania (Patroni, Citus lub natywna replikacja logiczna) stanowi wiarygodną alternatywę, choć odmienną w swojej filozofii.

Prawdziwa debata: zrównoważoność open-source

Poza przypadkiem Galera ta decyzja wznawia fundamentalną debatę. Jak finansować rozwój złożonego oprogramowania open-source w dłuższym okresie?

Model Open Core — wolne jądro otoczone komercyjnymi funkcjami — jest modelem dominującym. Redis, MongoDB, Elasticsearch — wszyscy go przyjęli w różnych formach. MariaDB po prostu podąża za tym trendem.

Ale jest kluczowa różnica: Redis zmienił zasady gry od początku, wprowadzając nowe funkcje. MariaDB zabiera funkcję, która była wolna od ponad piętnastu lat. To różnica między nigdy nie dawaniem czegoś a zabieraniem tego, co zostało dane.

Zaufanie jest sercem ekosystemu open-source. Gdy firma zabiera funkcję z edycji społecznościowej, wysyła sygnał do wszystkich użytkowników: "to, czego używacie dziś za darmo, może jutro stać się płatne". Ten sygnał skłania architektów do preferowania alternatyw zarządzanych przez fundacje (jak PostgreSQL przez PGDG) zamiast przez firmy komercyjne.

Co to oznacza dla DBA

Jeśli jesteś DBA i zarządzasz klastrami Galera w produkcji, oto moja rada:

  1. Nie panikuj. Twoje klastry MariaDB 11.4 działają i będą nadal działać.
  2. Dokumentuj swoją zależność od Galera. Które przypadki użycia naprawdę wymagają synchronicznej replikacji multi-master?
  3. Oceń alternatywy. Czy w każdym przypadku użycia replikacja semi-synchroniczna z automatycznym failoverem mogłaby wystarczyć?
  4. Planuj. Trzy lata to dużo, ale migracja bazy danych wymaga czasu. Zacznij ocenę teraz.

Podsumowanie

Galera has gone away to nie komunikat o błędzie. To zmiana epoki. Koniec modelu, w którym najbardziej zaawansowana technologia klastrowania ekosystemu MariaDB / MySQL była dostępna dla wszystkich.

To nie koniec MariaDB ani koniec Galera. To koniec pewnej idei tego, co "open-source" oznacza w kontekście korporacyjnych baz danych. I lekcja dla całej społeczności: w kwestii open-source jedyną gwarancją jest licencja. Przeczytaj ją, zrozum i planuj odpowiednio.


Ten artykuł został pierwotnie opublikowany na Medium.

Powrót do bloga X LinkedIn Facebook Email PDF
← Powrót do bloga

Opublikowano (0)

Nieprawidłowy adres e-mail.

Autor

PmaControl
+33 6 63 28 27 47 contact@pmacontrol.com
Platforma eksploatacji SQL GitHub Platforma eksploatacji SQL
Platforma eksploatacji SQL © 2014-2026 PmaControl — 68Koncept