Databases en phpMyAdmin

Bijna elke website bewaart zijn inhoud in een database: WordPress, een webshop, een forum. Deze pagina laat zien hoe je er een aanmaakt, wie erbij mag, en hoe je erin kijkt.

Beeld — Paneel → Hosting → Accounts → jouw account → Databases. De pagina heeft drie onderdelen: Databases, Databasegebruikers en Rechten. Schermafdrukken worden gemaakt met openwolf designqc en staan in .wolf/designqc-captures/.

Twee dingen, geen één

Het helpt om ze uit elkaar te houden:

• Een database is de kast waar de gegevens in liggen.
• Een databasegebruiker (of login) is de sleutel van die kast.

Een applicatie heeft altijd allebei nodig, plus de afspraak wie welke kast mag openen. Dat laatste heet rechten.

Beide namen krijgen automatisch je accountnaam ervoor. Vul je shop in bij een account dat web1 heet, dan heet de database web1_shop. Dat is geen opsmuk — het is wat voorkomt dat twee klanten op dezelfde server elkaars databasenaam claimen.

Welke databaseserver draait er

Boven de lijst staat een markering met een icoontje ervoor, bijvoorbeeld MARIADB 10.11. Dat is de motor die je databases bewaart, en de versie ervan — handig als de installatiehandleiding van je applicatie een minimale versie noemt.

MariaDB en MySQL delen één icoontje. Dat is geen slordigheid: ze spreken hetzelfde protocol, ze lezen hetzelfde instellingenbestand, en elke knop op deze pagina werkt op allebei precies hetzelfde. Wat er echt draait, lees je aan de naam en het versienummer in de markering zelf. Het icoontje is onze eigen tekening en niet het logo van de leverancier; zie Het ontwerpsysteem.

Staat er geen markering, dan heeft de server nog niets gemeld — herlaad de pagina, of vraag je hostingpartij ernaar als het zo blijft.

Het blok Databaseserver, onder de lijsten

Onder de twee lijsten staat een klein blok dat de machine zelf benoemt:

• Server — de naam van de machine, bijvoorbeeld db2.corecp.dev, met een kopieerknop. Dit is het eerste wat de helpdesk vraagt, en de naam die je gebruikt als je ooit van buitenaf verbindt.
• Versie — de motor en zijn versie, met een label ernaast:

Eronder staat één zin met de datum: "MariaDB 10.11 LTS is bevroren: beveiligings- en foutherstel tot 2028-02-16, geen nieuwe functies."

Staan je website en je database op twee verschillende machines, dan zegt een tweede regel dat, met de host die je in je instellingenbestand zet. Dat is dan de naam van de server en niet localhost.

Naar een andere versie

Een databaseserver draait één versie, en die wordt nooit onder je databases vandaan gewisseld — dat is niet iets wat de makers van MariaDB ondersteunen. Naar een andere versie betekent: je database verhuist naar een machine die die versie al draait, en dat doet je hostingpartij voor je. Je gegevens worden overgezet, rij voor rij gecontroleerd, en pas daarna gaat de oude kopie weg. Op deze pagina verandert niets; de Server en de Versie in het blok zijn wat je laat zien dat het gebeurd is.

Een database aanmaken

1. Klik Database aanmaken.
2. Vul een naam in: alleen letters, cijfers en onderstrepingstekens. De accountnaam staat er al voor.
3. Klik Aanmaken.

Je krijgt in één keer een database en een login met dezelfde naam. Het wachtwoord wordt door de server gemaakt en één keer getoond, in een kaart met een kopieerknop. CoreCP bewaart het nergens.

corectl db add web1 shop        # maakt web1_shop, met login web1_shop
corectl db list
corectl db passwd web1_shop     # nieuw wachtwoord, ook weer één keer getoond
corectl db remove web1_shop

Dit is precies wat je nodig hebt voor wp-config.php of een .env-bestand:

DB_NAME     web1_shop
DB_USER     web1_shop
DB_PASSWORD (het wachtwoord dat je zojuist zag)
DB_HOST     localhost

localhost is goed: applicaties op dezelfde server praten via een socket met de database, niet over het netwerk.

Zelf een wachtwoord kiezen

Onder de naam staat de vraag Wachtwoord. Standaard maakt CoreCP er een, en dat is de beste keuze: een gegenereerd wachtwoord is sterker dan een bedacht wachtwoord. Kies je Ik vul er zelf een in, dan verschijnt een veld met een generator-knop ernaast. Minimaal tien tekens.

Waarom je dat zou willen: het wachtwoord staat al in een configuratiebestand dat je niet wilt aanpassen, of je zet een site terug van een andere server.

Wat je dan niet krijgt is de kaart met het wachtwoord erop — je hebt het zelf net ingetypt, en CoreCP bewaart het nergens. Ook niet in een logboek, in een takenlijst of in het auditlog: daar staat alleen dát je een database hebt aangemaakt.

Een database bij een login die je al hebt

Heeft dit account al een of meer logins, dan staat er boven het wachtwoord een tweede vraag: Login. Standaard krijgt de nieuwe database een nieuwe login met dezelfde naam. Kies je Een login die al bestaat, dan wordt er niets nieuws gemaakt: de login die je aanwijst krijgt volledige toegang tot de nieuwe database en houdt het wachtwoord dat hij al had.

Dat scheelt: één applicatie met vier databases hoeft dan één wachtwoord te kennen in plaats van vier.

Op de commandoregel is dat --user, met de volledige naam erbij:

corectl db add web1 rapportage --user web1_app

De vraag over het wachtwoord verdwijnt dan uit het formulier, want er wordt niets aangemaakt dat er een nodig heeft.

Als je pakket vol is

Je pakket kan een maximum hebben voor databases en voor databasegebruikers. Is dat bereikt, dan is de knop Database aanmaken grijs en staat de reden ernaast: "Je pakket staat 3 databases toe en die zijn allemaal in gebruik." Je hoeft dus niet eerst een naam te bedenken om te horen dat het niet kan.

De twee tellen apart. Je pakket kan op zijn databases zitten en nog ruimte hebben voor logins, of andersom.

Wat je kunt doen:

• Ruim een database op die je niet meer gebruikt. Zodra hij weg is, kan de knop weer.
• Vraag je hostingprovider om een groter pakket. Verhuizen naar een ander pakket verandert niets aan wat er al staat.

Staat er geen maximum in je pakket, dan is het onbeperkt — daar zie je dan ook niets van.

Zeldzaam: komt de melding "dit pakket kon niet gelezen worden", dan is er iets mis met het pakket zelf en weigert het paneel voor de zekerheid. Het laat je bewust niets aanmaken zolang het je limiet niet kent. Probeer het over een minuutje nog eens en meld het anders bij je provider.

Een tweede login voor dezelfde database

Soms wil je een extra login met minder rechten — een rapportagetool die alleen mag lezen, bijvoorbeeld. Dan maak je een login zónder database en geef je hem daarna toegang.

1. Ga naar Databasegebruikers en klik Login aanmaken.
2. Ga naar Rechten, kies de database en de gebruiker, kies alleen lezen en klik Toepassen.

corectl db user add web1 rapportage                                   # → web1_rapportage
corectl db grant web1_shop web1_rapportage --account web1 --privileges readonly
corectl db grant list web1_shop --account web1
corectl db revoke web1_shop web1_rapportage --account web1
corectl db user remove web1_rapportage --account web1

De drie niveaus in het paneel:

phpMyAdmin openen

Klik bij een database op phpMyAdmin. Er opent een nieuw tabblad waarin je al bent ingelogd — je typt geen wachtwoord. Het ticket daarachter is eenmalig en vervalt binnen anderhalve minuut.

Waarmee je dan bent ingelogd

Niet met de login van je database, en dat scheelt je een risico. Voor die ene klik maakt de server een tijdelijke login aan die alleen bij de database mag die je opende, en die daarna weer wordt opgeruimd. Je ziet hem linksboven in phpMyAdmin staan als ccp_sso_….

Wat dat voor jou betekent:

• Het wachtwoord van je eigen databaselogin komt nergens in je browser terecht en staat dus ook niet in je browsergeschiedenis of in een serverlog.
• Raakt zo'n link toch bij iemand anders, dan is het ergste geval een login die bij één database mag en die er morgen niet meer is.
• Wil je met een ander programma verbinden — je applicatie, een tool op je eigen computer — dan gebruik je gewoon je eigen login en wachtwoord. Die verandert hier niets aan.

"Je bent niet aangemeld", terwijl je net klikte

Een tijd lang eindigde de knop op het inlogscherm van phpMyAdmin. De aanmelding zelf was goed; wat misging was de doorverwijzing erna — een browser geeft een verse sessiecookie niet mee als het bezoek van een ándere website kwam, en het paneel is een andere website dan de server waarop phpMyAdmin draait. De aanmeldpagina verwijst niet meer door en toont phpMyAdmin meteen.

corectl phpmyadmin signon web1        # eenmalige inlog vanaf de opdrachtregel
corectl webapps status                # draait phpMyAdmin op deze server?
corectl webapps set --phpmyadmin on

Zie je de knop niet, dan biedt deze server phpMyAdmin niet aan. Dat is een keuze van je hostingpartij; vraag ernaar. Let op het verschil tussen aan staan en aangeboden worden: een server die van webserver wisselt, houdt de instelling terwijl er niets meer op phpmyadmin.jouwsite.nl staat. Het paneel toont de knop alleen in het tweede geval — anders zou hij op de parkeerpagina uitkomen.

corectl --json webapps status | grep served    # wordt het ook echt aangeboden?
#   "served": false
corectl phpmyadmin signon web1                 # weigert dan eerlijk
#   phpmyadmin_not_served: phpMyAdmin is configured but the litespeed provider
#   does not render its vhost; nothing is served

Je databases zelf werken door: een applicatie op je site verbindt gewoon, en importeren/exporteren kan met de knoppen in het paneel of op de opdrachtregel.

Als je databases op een andere server staan

Staan je databases op een aparte databaseserver, dan draait daar geen webserver en dus ook geen phpMyAdmin. De knop phpMyAdmin werkt toch: je komt in phpMyAdmin op de server waar je website staat, en die maakt verbinding met de databaseserver. De tijdelijke login die daarvoor gemaakt wordt, mag alleen vanaf die webserver verbinden en verdwijnt vanzelf weer.

Krijg je een melding dat je server geen phpMyAdmin kan tonen, vraag dan je beheerder om phpMyAdmin aan te zetten op de server van je website.

Wat er ín een database zit

Klik een database aan en je krijgt de detailpagina: hoe groot hij is, hoeveel tabellen erin zitten, welke tekensortering hij gebruikt, en een lijst met per tabel de opslagmotor, het aantal rijen en de grootte.

Grootte      12,4 MB   (gemeten 3 minuten geleden · Opnieuw meten)
Inhoud       41 tabellen, 1 view, 1 procedure, 1 trigger
Vrije ruimte 1,1 MB    (terug te winnen met Optimaliseren)

Waarom staat er "gemeten 3 minuten geleden"? Omdat de grootte van een database nergens klaarligt: de server moet hem uitrekenen, en op een database met veel tabellen kost dat merkbaar tijd. We rekenen hem daarom één keer uit, onthouden het antwoord, en zeggen er eerlijk bij hoe oud het is. Wil je het getal van dit moment, klik dan Opnieuw meten — dat duurt even, en dat is precies waarom het een knop is en niet iets wat elke keer vanzelf gebeurt.

Na een onderhoudsronde (hieronder) wordt er automatisch opnieuw gemeten, dus het getal dat je daarna ziet klopt.

Op de commandoregel:

corectl db detail web1_shop --account web1
corectl db detail web1_shop --account web1 --refresh      # nu meten

Onderhoud: controleren, optimaliseren, repareren

Op de detailpagina staan onder Databasebewerkingen twee of drie knoppen. Je ziet live per tabel wat er gebeurt — de regels komen binnen terwijl het draait, niet pas aan het eind.

Waarom zie ik "Repareren" niet? Omdat je database dat niet nodig heeft. REPAIR TABLE bestaat alleen voor de oudere opslagmotoren (Aria, MyISAM, CSV). Draait alles op InnoDB — en dat is bij een moderne WordPress- of webshopsite vrijwel altijd zo — dan repareert de database zichzelf en zou de knop alleen maar een foutmelding opleveren. We laten hem dan weg in plaats van hem grijs te maken: een knop die er staat en niets kan, is erger dan geen knop.

Optimaliseren slaat views over (daar zit geen opslag onder) en zegt dat er ook bij, zodat je niet gaat zoeken naar een tabel die "ontbreekt".

corectl db check    web1_shop --account web1
corectl db optimize web1_shop --account web1
corectl db repair   web1_shop --account web1

Alleen bepaalde tabellen

Boven de drie knoppen staat één zin die zegt wat er wordt aangepakt: "Loopt over alle 41 tabellen." Klik op Tabellen kiezen en vink aan wat je wél wilt; de zin verandert mee in "Loopt over 2 van de 41 tabellen." en met Selectie wissen ben je in één klik terug bij de hele database.

Dat is handig als één tabel is opgezwollen — een logtabel waar je net honderden duizenden rijen uit hebt gegooid — en je de rest niet twintig minuten wilt laten herbouwen.

corectl db optimize web1_shop --account web1 --tables wp_options,wp_postmeta

Typ je een tabelnaam die niet bestaat, dan wordt de hele opdracht geweigerd in plaats van half uitgevoerd. Dat is met opzet: anders zou je "0 B teruggegeven" lezen als een antwoord over je tabel, terwijl het een antwoord over je typefout is.

Wat je terugkrijgt

Als de ronde klaar is staat er onder Wat er is gebeurd welke tabellen zijn behandeld en hoeveel ruimte er is teruggegeven. Dat getal staat er ook als het 0 B is: dat is een echt antwoord — er viel niets terug te geven — en het is precies wat je wilde weten toen je op de knop drukte.

Dat getal is een echte meting: de grootte vóór de ronde min de grootte erna. Om die aftrekking te laten kloppen kijkt Optimaliseren eerst even opnieuw naar de tabellen die het gaat opbouwen. De databaseserver bewaart zijn maten namelijk en telt ze niet bij elke vraag opnieuw, en een oude "vóór"-maat naast een verse "erna"-maat gaf 0 B teruggegeven terwijl er wel degelijk ruimte was vrijgekomen. Dat kijkje kost een fractie van een seconde en verandert niets aan wat de ronde doet.

Onderhoud start altijd doordat jij erop drukt. Het paneel plant niets in en begint nergens uit zichzelf aan; een signaal op de detailpagina brengt je hooguit naar het tabblad waar de knop staat.

Op het Databases-overzicht heeft elke rij een menuutje (de drie puntjes) met Onderhoud erin, zodat je er ook heen kunt zonder eerst de database te openen.

Toegang van buitenaf (extra adressen)

Standaard mag een databaselogin alleen verbinden vanaf de server zelf. Dat is wat je website doet, en voor de meeste sites is het het hele verhaal.

Wil je met een databaseprogramma op je eigen computer verbinden, of met een rapportagetool op een andere server, dan zet je dat adres erbij: Databasegebruikers → een login → Toegangsadressen → Adres toevoegen.

corectl db host list   web1_shop --account web1
corectl db host add    web1_shop '203.0.113.%' --account web1
corectl db host remove web1_shop '203.0.113.%' --account web1

Wat je moet weten:

• Het wachtwoord blijft hetzelfde. Een extra adres is dezelfde login, alleen ook bereikbaar vanaf daar. Je hoeft niets opnieuw in te stellen.
• % is een jokerteken. 203.0.113.% betekent elk adres in dat blok; alleen % betekent overal ter wereld. Dat mag, en het scherm zegt er ook bij dat het een jokerteken is — maar zet er liever je eigen vaste IP-adres neer.
• localhost kun je niet weghalen. Dat is het adres waarmee je eigen website verbindt.
• Er passen er dertig. Meer is bijna altijd een lijst die niemand meer opruimt.
• De poort moet ook open staan. Een adres toevoegen geeft de login toestemming; of poort 3306 van buitenaf bereikbaar is, bepaalt de firewall van de server. Vraag je hostingpartij ernaar als de verbinding blijft hangen.

Exporteren (een kopie maken)

In het paneel — open de database en klik Exporteren. Het venster blijft open terwijl de export loopt, en als hij klaar is staat de knop Downloaden erin: één klik en het bestand komt naar je computer. Het bestand blijft daarnaast gewoon in je eigen backups/db/-map staan, dus je kunt het ook laten staan voor je eigen back-ups, of later ophalen via de bestandsbeheerder, FTP of SFTP.

Ben je het venster kwijt — een export van een grote database duurt even — dan staat dezelfde downloadknop bij de taak: Taken in het menu, klik de export aan. Twee keuzes staan bij de export zelf:

• Inpakken (gzip) — standaard aan. Een SQL-bestand krimpt ongeveer tien keer.
• Geschikt maken voor een andere server — standaard aan. Laat dit aan als je het bestand ergens anders gaat terugzetten (zie hieronder).

Heb je een eigen backupbestemming ingesteld (S3, FTP, Dropbox, Google Drive), dan kun je het bestand daar in één moeite door naartoe laten kopiëren.

In de terminal:

corectl db export web1_shop --account web1
corectl db export web1_shop --account web1 --gzip=false     # gewone .sql
corectl db export web1_shop --account web1 --dest offsite   # ook naar je bestemming
ls -lh ~/backups/db/

Met phpMyAdmin — open de database, tabblad Exporteren, methode Snel, formaat SQL, en klik Gaan. Prima voor een kleine database; voor een grote is de knop in het paneel betrouwbaarder, omdat een browser er niet halverwege mee kan stoppen.

"Geschikt maken voor een andere server" — wat gebeurt daar?

Een databasekopie beschrijft niet alleen jouw gegevens, maar ook een beetje de server waar hij vandaan komt. Drie van die dingen zorgen ervoor dat het bestand elders wéigert te laden — bij een andere hostingpartij, op je eigen laptop, of op een server die Oracle MySQL draait in plaats van MariaDB:

1. De eigenaar van views en procedures. In de kopie staat de naam van een login die alleen op déze server bestaat. Elders levert dat ERROR 1227 op.
2. De naam van een sorteervolgorde. MariaDB gebruikt sinds versie 11.4 een naam die MySQL niet kent: ERROR 1273: Unknown collation.
3. Een serverinstelling die MySQL 8 heeft geschrapt. ERROR 1231.

Met deze optie aan worden alle drie vervangen door iets wat beide databases begrijpen, en zie je achteraf precies hoe vaak dat gebeurd is. De kopie bevat verder geen CREATE DATABASE en geen USE, zodat je hem in élke database kunt terugzetten:

zcat ~/backups/db/web1_shop-20260813T104502Z.sql.gz | mysql web1_anders

Zet je hem terug op déze server en wil je hem letterlijk houden, gebruik dan --portable=false.

Importeren (een kopie terugzetten)

Een dump van je oude host, een back-up van een collega, of je eigen export van vorige week: het paneel leest het bestand eerst, vertelt wat het erin ziet, en pas daarna mag je op importeren drukken.

Stap voor stap

1. Open de database waar het in moet: Databases → klik de database aan.
2. Klik op Database importeren. Onder Vanaf deze computer kies je het .sql- of .sql.gz-bestand op je eigen machine. Staat de dump al op de server — omdat je hem via FTP of SFTP hebt geüpload, of omdat het je eigen export is — dan klik je hem aan onder In backups/db staan al of typ je het pad.
3. Klik op Uploaden. Het bestand gaat in stukken naar de map backups/db. Je ziet hoeveel er al is verstuurd, en boven de knop staat hoeveel schijfruimte je nog hebt.
4. Kies wat er met de huidige inhoud gebeurt: Behouden (standaard) of Eerst wissen.
5. Klik op Bestand doorlezen. Nu leest de server je dump van begin tot eind en vertelt wat hij tegenkomt. Er is nog niets geladen.
6. Lees wat er staat, en klik dan op Nu importeren. Je ziet regel voor regel wat er gebeurt.

Als de verbinding wegvalt

Een dump van honderden megabytes over een wifi dat even wegvalt is precies waar dit voor gemaakt is. Het paneel meldt dan "De upload stopte bij 142 MB." en zet er twee knoppen onder:

• Verdergaan — het paneel vraagt de server hoeveel er echt is aangekomen en stuurt de rest. Je hoeft niet opnieuw te beginnen.
• Opnieuw beginnen — voor als je van gedachten bent veranderd of een ander bestand wilt sturen.

Past het bestand niet in je schijfruimte, dan hoor je dat vóór het versturen begint, met de getallen erbij: "De dump is 320 MB en er is nog 41 MB vrij."

Een upload die je halverwege afbreekt laat een bestandje achter dat begint met .corecp-part-, in dezelfde map. Dat is het halve bestand; het telt mee in je schijfruimte en je mag het gewoon weggooien via Bestanden. Stuur je dezelfde dump opnieuw vanaf het begin, dan wordt het vanzelf overschreven.

Wat de waarschuwingen betekenen

Behouden of eerst wissen

• Behouden (standaard): de dump komt bij wat er al staat. Een tabel die in de dump zit én al bestaat, wordt overschreven.
• Eerst wissen: elke tabel, view en procedure gaat weg vóór het laden. Dit is het enige wat op dit scherm gegevens kan wissen, dus je typt de naam van de database over om te bevestigen. Maak eerst een export als je twijfelt.

Je databaselogins en hun wachtwoorden blijven in beide gevallen staan — die horen bij de database, niet bij de inhoud.

Opruimen na afloop

Als de import klaar is vraagt het paneel of de dump weg mag: "backups/db/… staat nog op de server." met een knop Dump verwijderen. Hij gaat dan naar de prullenbak, dus je kunt hem daar nog terughalen.

Het paneel gooit hem nooit uit zichzelf weg. Die dump is namelijk ook de enige kopie van wat je zojuist hebt ingelezen, en of dat een back-up is die je wilt bewaren, weet jij en niet het paneel. Van een bestand dat er al stond voordat je begon wordt niets gevraagd — dat is van jou.

Op de commandoregel

# eerst kijken wat erin zit, zonder iets te laden
corectl db import analyze web1_shop backups/db/shop.sql.gz --account web1

# en dan echt
corectl db import web1_shop backups/db/shop.sql.gz --account web1
corectl db import web1_shop backups/db/shop.sql.gz --account web1 --wipe

Het pad is altijd relatief aan je eigen thuismap: de server leest het bestand als jou, dus iets buiten je eigen mappen bestaat voor deze opdracht simpelweg niet.

En phpMyAdmin dan? Dat kan nog steeds, en voor een klein bestandje is het prima. Voor alles daarboven loopt de browser tegen zijn uploadlimiet aan, en phpMyAdmin leest je dump niet vooraf door.

Waar je applicatie mee verbindt

Op de detailpagina van een database staat het tabblad Verbinden. Daar staan de vier dingen die je in wp-config.php, .env of je databaseprogramma invult, elk met een kopieerknop:

Host           localhost
Poort          3306
Databasenaam   web1_shop
Socket         /run/mysqld/mysqld.sock

Vul in wat er op het tabblad staat. Meestal is dat localhost: je website draait dan op dezelfde machine als de database, en met de servernaam werkt het van nergens. Wil je vanaf je eigen computer verbinden, dan opent dat een toegangsadres (zie hierboven) — localhost blijft wat de site zelf gebruikt.

Staat er een servernaam? Dan draait je database op een andere machine dan je website, en is die naam het juiste antwoord:

Host            stck2.corecp.dev
Poort           3306
Databasenaam    web1_shop

Het scherm zegt dat er dan ook bij: "Je website staat op een andere server dan je database." Je hoeft daar niets voor te regelen — de toegang en de firewall tussen die twee machines zijn al ingesteld toen je account werd aangemaakt.

Het wachtwoord staat er niet bij, en dat is geen omissie: wij bewaren het niet. Kwijt? Maak een nieuw wachtwoord aan bij de login en zet dat in je configuratie.

Een login die alleen mag lezen

Voor een rapportagetool, een dashboard of een collega die even mee wil kijken wil je zelden een login die alles mag. Op het tabblad Verbinden staat de knop Alleen-lezen-login: je geeft hem een naam, en je krijgt een login die alles in déze database mag lezen en er niets in mag veranderen. Het wachtwoord zie je één keer.

corectl db user add web1 rapportage
corectl db grant web1_shop web1_rapportage --account web1 --privileges readonly

Signalen op de detailpagina

Onder Signalen staat wat er opvalt aan je database. Er wordt daar nooit iets automatisch gerepareerd — het zijn observaties, geen taken.

Hoeveel mag je?

Het aantal databases komt uit je hostingpakket; je ziet het op het accountoverzicht. Daarnaast begrenst de server per account het aantal gelijktijdige verbindingen en het aantal query's per uur, zodat één drukke site de rest niet plat legt.

corectl db limits show web1

Zie je "te veel verbindingen", dan is dat bijna nooit de database die vol is, maar een applicatie die verbindingen niet netjes sluit.

Als er iets niet klopt

Als phpMyAdmin niet opengaat

De knop phpMyAdmin openen doet hetzelfde als de webmailknop: hij vraagt de server om een eenmalig toegangsbewijs en opent daarmee een nieuw tabblad. Ook hier werd dat tabblad een fractie te laat aangevraagd, waardoor de browser het weigerde en de knop niets leek te doen. Dat is verholpen.

Krijg je in plaats daarvan binnen een seconde een gele melding — de server is bezig met een andere wijziging, dus aanmelden is niet gestart; er is niets veranderd — dan is er niets kapot: aanmelden is óók een wijziging en staat in dezelfde rij als de rest, en de machine is er zo weer mee klaar. Probeer het even later opnieuw. Tot voor kort keek je in dat geval tot een minuut lang naar "Bezig met aanmelden…" en kreeg je daarna hetzelfde antwoord.

Zie je de knop helemaal niet staan, dan is phpMyAdmin niet geïnstalleerd op de server waar jouw account op staat. Vraag je hostingpartij ernaar; die controleert het zo:

ssh root@stck1.corecp.dev 'corectl db phpmyadmin status'
ssh root@stck1.corecp.dev 'corectl db phpmyadmin install'

Gaat het tabblad nog steeds niet open terwijl de knop er wel staat, dan blokkeert je browser pop-ups voor het paneeladres. Sta ze toe voor dat ene adres.

Zie ook

• De webterminal — waar mysql en mysqldump draaien.
• Je eigen backups — een backup van je account bevat je databases, en de bestemmingen die je daar instelt kun je ook voor een database-export kiezen.
• Bestanden, FTP en SSH — waar je het exportbestand ophaalt (backups/db/).
• WordPress installeren — daar wordt de database automatisch aangemaakt.

Waarom de server soms vanzelf sneller wordt

Op servers waar je provider de database-tuningagent draait, worden de instellingen van de database zelf beoordeeld en — als de provider een advies overneemt — aangepast. Dat is iets op serverniveau: het gaat over hoeveel geheugen de database voor caches bewaart en hoeveel verbindingen hij klaar houdt, niet over jouw databases of hun inhoud.

Twee dingen die goed zijn om te weten:

• Je gegevens kunnen er niet door stukgaan. Een wijziging die de database laat stoppen, wordt automatisch teruggedraaid — de server zet de vorige instellingen terug, herstart en controleert dat de database antwoordt voordat hij de wijziging als geslaagd beschouwt.
• Je eigen trage queries horen er niet bij. De tuner kijkt naar de server als geheel. Wil je zien welke van jouw queries traag waren, open dan het logboek trage databasequeries voor je account in Logboeken bekijken — dat logboek is op jou gescoped en op niemand anders.

Is een query van jou traag, dan lost geen enkele serverafstelling dat op: een index wel.

Wat de databasetuning op je server verandert

Zet je beheerder databasetuning aan, dan schrijft die geen wijzigingen middenin de bestaande configuratie van de databaseserver. Er komt een apart instellingenbestand naast, en de originele configuratie blijft ongemoeid.

Dat is bewust: één bestand terugzetten is een handeling van niets, een teruggedraaide wijziging middenin andermans configuratiebestand is dat nooit.

ssh root@stck1.corecp.dev 'corectl db tuner status'

engine     MariaDB 11.8 (Ubuntu LTS)
applied    9 setting(s), 14 Aug 2026 09:12
file       /etc/mysql/corecp.conf.d/z_aiops_mysql.cnf
previous   kept — corectl db tuner revert puts it back

Wil je terug naar hoe het was, dan is dat één opdracht:

ssh root@stck1.corecp.dev 'corectl db tuner revert'

Het bestand is leesbaar voor de databaseserver zelf, want die moet het inlezen — het staat er niet geheim bij. Je exports liggen er anders bij: die bevatten je eigen gegevens en zijn alleen voor de eigenaar leesbaar.

Waar een export terechtkomt, en wie hem mag lezen

Een export is een kopie van je database, dus die wordt weggeschreven met de smalst mogelijke rechten: alleen de eigenaar leest hem, niemand anders op de server.

ssh root@stck1.corecp.dev 'ls -l /var/backups/corecp/acc-1/'

-rw------- 1 root root 1.2M Aug 14 09:13 acc1_shop.sql.gz

Download je hem via het paneel, dan gaat hij over de beveiligde verbinding en blijft er niets van achter op de server zodra de download klaar is.

Een nieuw wachtwoord: waar het komt te staan

Wachtwoorden die de server voor je maakt zie je één keer. Ze staan daarom altijd op de plek waar je erom vroeg, en niet ergens anders op het scherm:

• Vraag je een nieuw wachtwoord in het venster van een databasegebruiker, dan blijft dat venster open en verschijnt de kaart met het wachtwoord er middenin, boven de knop die je net indrukte.
• Maak je iets nieuws aan, dan sluit dat venster zichzelf zodra het gelukt is en staat de kaart op de pagina eronder — die je op dat moment weer ziet.

Kopieer of noteer het meteen. Ben je het kwijt, dan is er geen manier om het terug te halen; er is alleen een manier om een nieuw wachtwoord te laten maken.

Gaat er iets mis, dan zie je dat op precies dezelfde plek: de melding staat in het venster waarin je de knop indrukte, niet op de pagina erachter.

De databases van de server zelf, en waarom je ze niet ziet

Een server houdt naast jouw databases een paar administraties van zichzelf bij: de maillijst waaruit de mailserver leest, de zonegegevens van de naamserver en de instellingen van de webmail. Die zie je niet in je lijst en ze tellen niet mee voor je pakketlimiet — het zijn geen databases van een klant.

Op servers die de beheerder heeft omgezet staan ze bovendien niet meer in dezelfde database-server als die van jou. Dat heeft één gevolg dat je kunt merken: als de beheerder ooit van database-engine wisselt (van MariaDB naar MySQL of andersom), gaan alleen de databases van klanten mee. De mailbezorging en de naamserver blijven tijdens zo'n wissel gewoon draaien.

Je eigen databases blijven ondertussen precies waar ze waren. Controleer na een onderhoudsmelding gerust of je site nog verbindt:

mysql -h localhost -u jouwgebruiker -p jouwdatabase -e "SELECT 1;"

Krijg je hier 1 terug, dan is er aan jouw kant niets veranderd. Krijg je een foutmelding over toegang, dan is je wachtwoord het eerste om te controleren — dat verandert niet door onderhoud aan de server.

Waar de databasesoftware vandaan komt

MariaDB of MySQL komt op een server van dezelfde pakketbron als CoreCP zelf, zoals de installer die op de server heeft vastgelegd — niet van een vast adres in de software. Een server zonder vastgelegde bron weigert de databasesoftware te installeren of te wisselen en zegt wat er ingesteld moet worden. Voorbeeldnamen in foutmeldingen, zoals db1.example.net, zijn voorbeelden.

Na een update van de database: één stap die erbij hoort

MariaDB bewaart naast je gegevens welke versie die gegevens voor het laatst hebben "meegekregen". Loopt dat achter op de databaseserver die er nu draait, dan hoort er één stap bij: de systeemtabellen worden nagelopen en zo nodig hersteld, en daarna staat de nieuwe versie in dat bestandje. Of het nodig is, bepaalt MariaDB zelf — bij een gewone patch binnen dezelfde reeks niet, bij gegevens die een uitgave achterlopen wel.

Normaal doet het pakket dat zelf. Maar alléén als de databaseserver op dat moment toevallig draait. Stond hij stil tijdens de update, dan komt hij terug met nieuwe programmatuur boven een ouder schema. De database blijft gewoon werken, zegt er iets over in haar eigen logboek, en verder merkt niemand het.

Sinds deze uitgave doet CoreCP die stap zelf, tijdens de nachtelijke onderhoudsronde, meteen na de pakketten. Je hoeft er niets voor te doen.

Staat het nog open — bijvoorbeeld omdat de onderhoudsronde uitstaat op die server — dan zie je dat op Servers → de server → Controlelijst staan als Database-upgradestap, met de opdracht erbij. Wil je niet wachten tot de nacht:

corectl maintenance run --now

Kan de vraag niet gesteld worden (de databaseserver draait niet, of hij antwoordt niet), dan zegt die regel dát, en niet "in orde". Een controle die niet kon kijken is geen controle die slaagde.

Dit geldt voor MariaDB. MySQL doet dit werk zelf bij de eerste start na een update en heeft geen aparte stap.

Waar phpMyAdmin zelf vandaan komt

Sinds deze uitgave uit de eigen applicatiespiegel van CoreCP, en niet meer rechtstreeks van files.phpmyadmin.net terwijl je server hem klaarzet. phpMyAdmin draait met een databaselogin in zijn sessie, dus het maakt uit wat er binnenkomt: van elke uitgave ligt de vingerafdruk vast in de eigen bron van CoreCP, gecontroleerd tegen zowel het checksumbestand van de makers als hun OpenPGP-handtekening, en een bestand dat niet aan die vingerafdruk voldoet wordt geweigerd in plaats van geïnstalleerd.

Aan het gebruik verandert niets — dezelfde knop, dezelfde eenmalige aanmelding die hierboven beschreven staat. Applicaties installeren legt de spiegel zelf uit.