MariaDB 10.11 upgrade

Voordelen van de MariaDB 10.11 upgrade

Het upgraden van MariaDB van versie 10.5 of 10.6 naar MariaDB 10.11 LTS is een verstandige en toekomstbestendige keuze, omdat 10.11 een Long Term Support-release is met langdurige beveiligingsupdates en onderhoud, terwijl 10.5 en 10.6 het einde van hun ondersteuning naderen of al hebben bereikt. MariaDB 10.11 biedt betere prestaties en stabiliteit, vooral bij hoge gelijktijdige belasting, dankzij verbeterde query optimalisatie, een betrouwbaardere InnoDB engine en talrijke bugfixes die in meerdere eerdere versies zijn verzameld.

Daarnaast introduceert deze versie sterkere beveiligingsstandaarden, verbeterde encryptie en authenticatiemechanismen en robuustere replicatie, wat haar geschikter maakt voor productieomgevingen en compliance eisen. Door te upgraden naar 10.11 LTS wordt het operationele risico verminderd en krijgt men een stabiele, goed ondersteunde databasebasis voor de lange termijn.

Hoewel de upgrade van MariaDB naar 10.11 vanaf 10.5/6 veel voordelen biedt, zijn er ook enkele uitdagingen verbonden aan de upgrade. In dit artikel leest u hierover:

Welke problemen per platform kunnen optreden
Hoe je deze problemen herkent en diagnosticeert
Wat de aanbevolen oplossingen zijn

Dit overzicht helpt je om snel inzicht te krijgen in mogelijke compatibiliteitsissues en om tijdig de juiste stappen te nemen om je website of applicatie probleemloos te laten werken met MariaDB 10.11.

WordPress & WooCommerce
Magento2
Shopware 5 & 6
Joomla

WordPress & WooCommerce

Na de upgrade naar MariaDB 10.11 kunnen sommige WordPress en WooCommerce sites problemen krijgen door verouderde plugins, thema’s of maatwerkcode. Hieronder lees je welke problemen kunnen ontstaan en hoe je ze herkent en oplost.

Verouderde plugins of thema’s (SQL-syntax niet compatibel)
Oudere plugins en thema’s gebruiken soms SQL-queries die in MariaDB 10.5/10.6 nog “door de vingers” werden gezien, maar in 10.11 fouten geven.
Denk aan:
- GROUP BY zonder alle geselecteerde kolommen
- ongeldige JOIN constructies
- gebruik van verouderde functies of foutieve ORDER BY /HAVING combinaties

WooCommerce kan trager aanvoelen
- Door wijzigingen in de query optimizer kan WooCommerce zwaarder worden, vooral bij:
- grote aantallen producten/variaties
- drukke categoriepagina’s en zoekresultaten
- winkelwagen en checkout (complexe queries op orders, meta en sessions)

Postmeta tabellen lopen vast (wp_postmeta / wp_woocommerce_*_meta)
- Grote postmeta tabellen (honderdduizenden/miljoenen regels) i.c.m. geen of slechte indexes kunnen:
- veel tijdelijke tabellen (tmp tables) veroorzaken
- full table scans doen bij zoekopdrachten op meta velden
- leiden tot hoge CPU load in MySQL

Hoe herken je het?

Foutmeldingen in de WordPress logbestanden
In wp-content/debug.log zie je bijvoorbeeld:
- “SQLSTATE[42000]: Syntax error or access violation ”
- meldingen over GROUP BY , ORDER BY of ontbrekende kolommen

Traagheid of fouten in de frontend
- WooCommerce pagina’s (categorie, product, winkelwagen, afrekenen) laden aanzienlijk trager dan vóór de upgrade
- 500 errors of timeouts bij het afrekenen of in de winkelwagen
- hogere TTFB (Time To First Byte) bij productoverzichten

Traagheid in wp-admin
- langzaam laden van order overzichten, productlijsten of plugins pagina
- AJAX acties die ineens veel langer duren (bijv. bulk acties, statusupdates)

Oplossingen

Alles updaten vóór én na de upgrade
- Update WordPress core, alle plugins en thema’s naar de laatste versie
- Besteed extra aandacht aan WooCommerce en alle WooCommerce plugins en extensies

Grote tabellen en indexes controleren
- Controleer met de developer of belangrijke tabellen (zoals wp_postmeta , wp_woocommerce_order_items , custom meta tabellen) de juiste indexes hebben
- Voorkom LIKE zoekopdrachten zonder index op meta_key /meta_value

Custom SQL-queries nalopen
- Laat custom code (in mu plugins, thema’s of maatwerkplugins) nakijken op:
  - GROUP BY die niet voldoet aan ONLY_FULL_GROUP_BY
  - onlogische JOINs of subqueries
- Pas waar nodig de queries aan zodat ze ook onder MariaDB 10.11 geldig én efficiënt zijn

Tijdelijk extra logging inschakelen voor analyse
- In WordPress: WP_DEBUG en WP_DEBUG_LOG tijdelijk inschakelen om PHP/SQL fouten te loggen
- De verzamelde queries kunnen daarna door een developer worden geoptimaliseerd (indexes, herstructurering, caching)

Magento 2

Na de upgrade naar MariaDB 10.11 kunnen sommige Magento 2 installaties te maken krijgen met fouten of vertragingen. Dit gebeurt vooral wanneer modules, extensies of maatwerkcode verouderde SQL constructies gebruiken die niet meer worden ondersteund in de nieuwe versie. Hieronder lees je welke problemen kunnen ontstaan en hoe je ze kunt herkennen en oplossen.

1. Strengere SQL modes breken modules of custom code

MariaDB 10.11 activeert standaard strengere SQL-modes zoals:

ONLY_FULL_GROUP_BY
STRICT_TRANS_TABLES
NO_ZERO_DATE

Veel oudere Magento modules (en maatwerk) gebruiken SQL die hier niet mee overweg kan.

Veelvoorkomende incompatibiliteiten:

GROUP BY zonder alle geselecteerde kolommen
JOIN opdrachten waarbij kolommen ontbreken
Query’s die rekenen op soepelere type conversies
Verkeerde datumformaten of lege datumwaarden

Dit leidt direct tot SQL errors of vastlopende functionaliteit.

2. Catalogus en zoekfunctionaliteit wordt trager

Magento maakt intensief gebruik van grote en complexe queries voor:

Productlijsten
Layered navigation (filters)
Catalogus zoekopdrachten
Elasticsearch fallback queries

Door wijzigingen in de query optimizer kan 10.11:

andere query plannen kiezen
meer full table scans uitvoeren
vaker tijdelijke tabellen op disk gebruiken

Bij grote catalogi ga je dit direct merken in performance.

3. Indexers kunnen vastlopen of extreem traag worden

Indexers zijn gevoelig voor SQL changes, vooral:

catalog_product_attribute
catalog_product_price
catalogsearch_fulltext

Strengere SQL regels kunnen indexers laten falen of uren langer laten draaien.

4. Checkout en API integraties geven errors of timeouts

Doordat verschillende modules achter de schermen database queries uitvoeren, kunnen:

checkoutprocessen vastlopen (vooral op configurable products)
API calls (REST / GraphQL) timeouts geven
payment modules foutmeldingen tonen

Dit is een van de meest zichtbare risico’s voor eindgebruikers.

Hoe herken je problemen?

1. Magento logt duidelijke SQL-errors

Kijk in:

var/log/exception.log
var/log/system.log

Veelvoorkomende foutmeldingen:

SQLSTATE[42000]: Syntax error or access violation
Cannot group by position ...
Invalid datetime format
Column not in GROUP BY clause

2. Trage frontend-acties

Vooral merkbaar bij:

Productcategorieën met veel filters
Zoeken binnen grote catalogi
Configurable / bundled products
Checkout (customer → shipping → payment steps)

TTFB kan oplopen van 0.2s naar 2-5s of meer.

3. Vastlopende of incomplete indexers

Symptomen:

Indexers blijven op processing staan
Cronjobs lopen vast
Admin toont: “One or more indexers are invalid”

4. API prestatiedalingen

GraphQL en REST zijn zwaar afhankelijk van complexe queries:

response tijden lopen op
API geeft 500 / timeout errors
Eventueel zelfs rate limiting of CPU-pieken

Oplossingen

1. Update alle modules vóór de MariaDB upgrade

Third party modules zijn de grootste oorzaak van SQL problemen
Controleer changelogs van modules op "MariaDB 10.11 compatibility"
Update Magento core naar laatste 2.4.x versie

2. Controleer en verbeter database indexen

Vooral belangrijk voor:

catalog_product_entity_* tabellen
catalogsearch_fulltext
eav_attribute en eav_attribute_option
custom module tabellen

Ontbrekende indexes kunnen na de upgrade exponentieel trager worden.

3. Herschrijf of corrigeer custom SQL

Check vooral:

GROUP BY
JOINs op EAV tabellen
datetime velden
gebruik van ISNULL() of casting

Strikte SQL modes vereisen veel nettere query’s.

4. Indexers opnieuw draaien na de upgrade

Altijd uit te voeren:

bin/magento indexer:reindex bin/magento cache:flush

Als indexers blijven hangen:

bin/magento indexer:reset

5. Monitor MySQL tijdens en na de upgrade

Gebruik:

PMM (Percona)
Magento profiler (bin/magento dev:profiler:enable )

Hiermee zie je welke queries plotseling traag worden.

6. Test checkout en API’s op een staging-omgeving

Vooral belangrijk vanwege:

payment providers
shipping modules
ERP koppelingen
PIM / voorraad updates

Shopware (5 & 6)

Na de upgrade naar MariaDB 10.11 kunnen sommige Shopware 5 en 6 installaties fouten of prestatieproblemen ervaren. Dit komt vooral doordat veel Shopware functionaliteit afhankelijk is van Doctrine query’s en plugins die mogelijk nog oude of niet compatibele SQL gebruiken.

Hieronder vind je een overzicht van de meest voorkomende problemen, hoe je ze herkent en welke oplossingen beschikbaar zijn.

1. Doctrine ORM query’s worden incompatibel met MariaDB 10.11

Shopware maakt intensief gebruik van Doctrine ORM. Doctrine genereert SQL op basis van entity definities, en kleine veranderingen in MariaDB’s SQL strictness kunnen leiden tot:

foutmeldingen bij GROUP BY
JOINs die niet langer valide zijn
type conversies die in 10.11 niet meer automatisch worden uitgevoerd
queries die afhankelijk waren van losse toleranties in oudere MariaDB versies

Veelvoorkomende pijnpunten:

prijsberekeningen
productvarianten
vertalingen
klant en orderoverzichten
API-endpoints

Dit is bij Shopware een zeer veelvoorkomend probleem na grote database updates.

2. Plugins breken omdat ze afhangen van oude SQL functionaliteit

Shopware heeft een enorm plugin ecosysteem. Veel plugins gebruiken raw SQL of uitbreidingen op Doctrine die:

nieuwer strict GROUP BY niet ondersteunen
verouderde CAST/CONVERT syntax gebruiken
queries genereren met ongeldige aliasing
fallback logica gebruiken die in 10.11 niet meer werkt

Gevolg:

Backend secties openen niet, modules springen op fouten of API verzoeken falen.

3. Backend- of API-features worden trager

Doordat MariaDB 10.11 een nieuwe query optimizer heeft, worden sommige complexe Shopware query’s trager:

productlisting met filters
zoekfunctie (Shopware Search / Elasticsearch fallback)
exports in backend
orderoverzichten
statistieken dashboards

Shopware 6 maakt veel gebruik van JOIN heavy queries, deze zijn gevoelig voor optimizer wijzigingen.

4. Caching en indexing kunnen onvoorspelbaar gedrag vertonen

Shopware heeft meerdere caches en index processen.

Na een database upgrade kan voorkomen:

URL index rebuilding mislukt
product export indexingen vastlopen
search index niet volledig opbouwt
cache wordt niet correct geregenereerd

Dit resulteert in inconsistenties in storefront en backend.

Hoe herken je problemen?

1. Doctrine SQL errors in logs

In zowel Shopware 5 als 6 vind je relevante logs hier:

var/log/
var/log/dev-*.log (Shopware 6 developer mode)

Veelvoorkomende foutmeldingen:

"SQLSTATE[42000]: Syntax error or access violation"
"Column 'x' is not in GROUP BY clause"
"General error: 3065 Expression in GROUP BY"
"Unknown column"
"Invalid JSON text" (bij Shopware 6 documentdata)

2. Backend-secties openen langzaam of helemaal niet

Bijvoorbeeld:

Productoverzicht toont niets
Variantenoverzicht blijft laden
Orderdetails laden niet
Configuratiepagina's geven Error 500

3. Storefront problemen

Productlijsten laden extreem traag
Filters werken niet meer
Navigatie elementen zijn leeg
Zoeken geeft geen of foutieve resultaten
Foutmeldingen in checkout of winkelwagen

4. API (Shopware 6) vertraagt of faalt

/api/search/product requests duren vele seconden
API timeouts in PIM, ERP, WMS integraties
ElasticSearch fallback triggert ineens vaker → extra load

Oplossingen

1. Update Shopware volledig vóór de MariaDB upgrade

Voor zowel Shopware 5 als 6:

Update naar de laatste patchversie
Update alle plugins/extensions
Controleer changelogs specifiek op “MariaDB compatibility”
Verwijder ongebruikte plugins die queries registreren

Shopware 6 heeft regelmatig fixes voor Doctrine compatibiliteit.

2. Leeg de caches en compileer opnieuw

Shopware 5:

php bin/console sw:cache:clear php bin/console sw:theme:cache:generate

Shopware 6:

bin/console cache:clear bin/console theme:compile

Dit lost 20–30% van post upgrade problemen op.

3. Doctrine debug mode tijdelijk inschakelen (Shopware 6)

Hiermee kun je exact zien welke query’s falen of afwijkend gedrag vertonen.

Developer mode activeren:

export APP_ENV=dev

Je krijgt nu gedetailleerde stack traces.

4. SQL aanpassen voor FULL_GROUP_BY

Vaak moet code worden aangepast om te voldoen aan MariaDB 10.11’s strikte regels:

alle kolommen in SELECT moeten in GROUP BY zitten
subqueries moeten explicieter worden
join voorwaarden moeten kloppen

Shopware’s eigen code is meestal compliant → plugins zijn de grootste oorzaak.

5. Database en zoekindexen opnieuw opbouwen

Shopware 6:

bin/console dal:refresh:index

Shopware 5:

php bin/console sw:rebuild:seo:index

Dit herstelt productlijsten, SEO url’s en zoekindexen.

6. Monitor MySQL na de upgrade

Gebruik PMM of MySQL slow query logs om te detecteren:

queries die veel duurder zijn geworden
plugins die temp tables veroorzaken
Doctrine queries die full table scans uitvoeren

Vaak ziet men direct dat één of twee plugins verantwoordelijk zijn voor 80–90% van de problemen.

Joomla

Na de upgrade naar MariaDB 10.11 kunnen Joomla sites fouten of onverwacht gedrag vertonen. Dit gebeurt vooral wanneer extensies, templates of maatwerkcomponenten gebruikmaken van verouderde SQL-syntax die in oudere MariaDB-versies nog werkte, maar in 10.11 niet meer wordt geaccepteerd. Hieronder lees je welke problemen kunnen ontstaan en hoe je ze kunt herkennen en oplossen.

1. Extensies en templates gebruiken oude of incompatibele SQL-syntax

Joomla (vooral Joomla 3) heeft een groot ecosysteem van extensies, templates en componenten.

Veel daarvan gebruiken SQL die in MariaDB 10.5/10.6 werd “geaccepteerd”, maar in 10.11 foutmeldingen geeft.

Voorbeelden van kwetsbare SQL-patterns:

GROUP BY zonder alle kolommen
Foute JOIN-constructies (ambigue kolommen)
Verouderde LIMIT-syntax
Gebruik van implicit type conversions die nu strikter zijn
!= "" in plaats van != '' (lege string problemen)
Foute datumformaten, zoals 0000-00-00 (verboden onder strict mode)

Dit kan ervoor zorgen dat:

modules niet meer laden
frontend componenten 500 errors genereren
templates “wit scherm” tonen

Vooral oudere extensies lopen risico.

2. Legacy componenten (vooral Joomla 3) worden instabiel

Joomla 3 heeft veel legacy code die:

afhankelijk is van oude database standaarden
implicit casting gebruikt (bijv. strings → int)
oude query builders gebruikt die niet FULL_GROUP_BY compliant zijn

Na de upgrade zie je daardoor regelmatig:

volledig witte pagina’s
admin die niet meer inlogt
ongeldige SQL calls vanuit modules

3. Performanceproblemen door gewijzigde optimizer

Joomla gebruikt veel databasecalls voor:

artikelen
menu’s
modules
user sessions

Wanneer extensies inefficiënte query’s gebruiken, kan MariaDB 10.11:

full table scans uitvoeren
tmp tables aanmaken (ook op disk)
queries veel trager maken

Met name grote Joomla sites of oudere componenten worden hierdoor merkbaar trager.

4. Problemen met caching, session en index tabellen

De MySQL optimizer kan bestaande tabellen anders interpreteren:

sessiontabellen locken sneller
caching tabellen groeien harder of raken corrupt
extensies die tabellen verkeerd indexeren veroorzaken DB errors

Dit resulteert soms in:

uitgelogde gebruikers
foutmeldingen bij componenten
prestaties die plotseling verslechteren

Hoe herken je problemen?

1. Joomla debug log toont SQL errors

Veelvoorkomende foutmeldingen:

"Unknown column"
"You have an error in your SQL syntax"
"Column not in GROUP BY"
"Invalid default datetime"

Je vindt logs in:

/administrator/error_log
Joomla debug console (indien ingeschakeld)

2. Backend-secties laden niet of crashen

Mogelijke symptomen:

Admin dashboard blijft wit
Componenten zoals “Artikelen”, “Menu’s”, “Gebruikersbeheer” geven foutmeldingen
Extensies weigeren te openen

3. Frontend problemen

Categoriepagina’s laden niet
Modules tonen niet of genereren fouten
Menu’s laden traag of incorrect
Witte schermen door server errors

4. Databasefouten in extensies

Extensies zijn vaak de boosdoener.

Voorbeelden:

Formulieren die niet opslaan
Zoekmodules die 500 errors geven
Slider/extensions die geen content meer tonen
Contactformulieren die falen

Oplossingen

1. Update Joomla + alle extensies vóór de MariaDB upgrade

Dit is cruciaal:

Update Joomla core (Joomla 3 → laatste patch, Joomla 4 volledig up-to-date)
Update ALLE extensies, modules en templates
Verwijder extensies die niet langer onderhouden worden

Veel extensieontwikkelaars hebben specifiek updates uitgebracht voor MariaDB 10.11 compatibiliteit.

2. Controleer custom componenten en templates

Met name:

queries in .php bestanden (componenten)
query builders in models
database oproepen in templates of overrides

Aanpassen kan nodig zijn om compliant te zijn met:

ONLY_FULL_GROUP_BY
STRICT_TRANS_TABLES
nieuwe optimizerlogica

3. Debug mode gebruiken voor foutanalyse

In Joomla:

Ga naar Systeem → Configuratie → Debug System
Zet aan: Debug System
Aanzetten: Debug Language (optioneel)

Je ziet nu:

exacte query’s die falen
call stacks
templates of extensies die foutcodes genereren

4. Herindexeren en cache wisselen

Joomla’s interne caching en indexering moet na grote databasewijzigingen vaak vernieuwd worden.

Acties:

Opschonen cache (Systeem → Opschonen Cache)
Expired cache verwijderen
Rebuild menu’s (in menubeheer)
Rebuild content (indien extensie dit ondersteunt)

5. Optimaliseer database tabellen

Gebruik bijv. phpMyAdmin of CLI:

Repareer tabellen met fouten
Optimaliseer tabellen met hoge overhead
Controleer op ontbrekende of dubbele indexes

Belangrijke tabellen:

#__content
#__categories
#__menu
#__extensions
#__session

6. Schakel problematische extensies tijdelijk uit

Als de site direct breekt:

schakel extensies één voor één uit via #__extensions tabel (indien admin niet werkt)
of rename extensiemap via FTP
daarna debugging → update → fix → opnieuw activeren