{"id":21183,"date":"2026-08-30T18:17:32","date_gmt":"2026-08-30T16:17:32","guid":{"rendered":"https:\/\/webhosting.de\/mariadb-buffer-pool-instances-mehrkernsysteme-performance-tuning-datenbank\/"},"modified":"2026-08-30T18:17:32","modified_gmt":"2026-08-30T16:17:32","slug":"mariadb-bufferpool-instanties-systemen-met-meerdere-processorkernen-prestatieoptimalisatie-database","status":"publish","type":"post","link":"https:\/\/webhosting.de\/nl\/mariadb-buffer-pool-instances-mehrkernsysteme-performance-tuning-datenbank\/","title":{"rendered":"MariaDB-bufferpoolinstanties voor maximale prestaties op systemen met meerdere kernen"},"content":{"rendered":"<p>Ik laat je zien hoe ik werk met <strong>Buffer-instanties<\/strong> de InnoDB-cache op systemen met meerdere processorkernen schaalbaar te maken en lock-conflicten merkbaar te verminderen. De nadruk ligt op de <strong>MariaDB-buffer<\/strong> en de parameter `innodb_buffer_pool_instances`, zodat threads effici\u00ebnt toegang krijgen, de latentie gelijkmatiger wordt en de doorvoer toeneemt.<\/p>\n\n<h2>Centrale punten<\/h2>\n<ul>\n  <li><strong>Mutex-conflict<\/strong> minimaliseren en gelijktijdige toegangen ontkoppelen<\/li>\n  <li><strong>Cache-locatie<\/strong> verhogen en beter gebruikmaken van CPU-caches<\/li>\n  <li><strong>Versie<\/strong> controleren, aangezien de parameter deels geen effect heeft<\/li>\n  <li><strong>verhoudingsgetal<\/strong> per instantie in acht nemen (\u2265 1 GB)<\/li>\n  <li><strong>Controle<\/strong> toepassen en stapsgewijs bijstellen<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/mariadb-serverraum-4728.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>InnoDB-bufferpool in het kort uitgelegd<\/h2>\n\n<p>Ik beschouw de InnoDB-bufferpool als <strong>Knooppunt<\/strong> voor gegevens- en indexpagina\u2019s in het RAM, want dit bepaalt hoe vaak MariaDB trage I\/O-toegangen kan vermijden. Hoe meer actieve gegevens erin passen, hoe minder vaak de engine van de schijf hoeft te lezen, wat de responstijden verkort en de doorvoer verhoogt. Op servers die bijna uitsluitend MariaDB draaien, reserveer ik meestal 60\u201380 % van het RAM, op gemengde hosts eerder 40\u201360 %, zodat er genoeg geheugen overblijft voor het systeem. Het is belangrijk dat de \u201ehot data\u201c ruimte krijgen, zodat query\u2019s herhaaldelijk uit de cache kunnen worden gelezen. Hiervoor houd ik de hit-rate in de gaten, pas ik de grootte aan en houd ik de <strong>Pieken in belasting<\/strong> in \u00e9\u00e9n oogopslag.<\/p>\n\n<h2>Waarom meerdere bufferpool-instanties op systemen met meerdere processorkernen?<\/h2>\n\n<p>Meerdere instanties verminderen <strong>Wachttijden vergrendelen<\/strong>, omdat threads niet allemaal op dezelfde interne structuren terugvallen. Bij \u00e9\u00e9n grote pool neemt de concurrentie om mutexen toe, wat bij hoge parallelliteit voor vertraging zorgt. Ik splits de pool op, zodat workloads over verschillende instanties worden verdeeld, wat de kans op hotspots verkleint. Bovendien verbeter ik zo de cache-localiteit, omdat terugkerende toegangen vaker in dezelfde instantie terechtkomen en CPU-caches effectiever worden benut. Het resultaat is een gelijkmatiger latentie en een betrouwbaar hogere <strong>Doorvoer<\/strong> bij een hoge mate van parallellisatie.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/mariadb_bufferpool_3892.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Versie-realiteit: wanneer heeft `innodb_buffer_pool_instances` effect?<\/h2>\n\n<p>Voordat ik het aantal instanties vaststel, controleer ik de <strong>Versie<\/strong> van mijn MariaDB, want vanaf bepaalde releases (bijv. 10.5.1) werkt de parameter soms niet meer. Nieuwere versies hebben de bufferpool-locking intern verbeterd, waardoor minder instanties volstaan of er zelfs geen effect meer optreedt. In oudere versies levert de verdeling echter vaak duidelijke voordelen op, vooral bij grote pools en hoge parallelliteit. Ik plan daarom pas na een versiecontrole of ik de instanties optimaliseer of in plaats daarvan andere instellingen prioriteit geef. Hiertoe behoren de grootte van de bufferpool, redo-log-parameters en de systeembrede <strong>Thread-besturing<\/strong>.<\/p>\n\n<h2>De grootte van de bufferpool bepalen<\/h2>\n\n<p>Ik bepaal eerst de grootte van de pool, zodat de instanties later een redelijke omvang hebben en niet te klein worden. Op dedicated databaseservers reserveer ik 60\u201380 % van het RAM-geheugen en op gedeelde hosts eerder 40\u201360 %, zodat het besturingssysteem en de diensten voldoende bufferruimte overhouden. Het doel: zoveel mogelijk 80\u201390 % van de actieve gegevens in de pool houden, zodat de hit-rate dicht bij 99 % blijft. Wie zich hier verder in wil verdiepen, vindt in het beknopte <a href=\"https:\/\/webhosting.de\/nl\/mariadb-bufferpool-dimensionering-prestatiegidsgeheugen\/\">Bepaling van de omvang van de bufferpool<\/a> praktische aanwijzingen. Ik beschouw de grootte als iets veranderlijks <strong>Budget<\/strong> en pas deze aan wanneer de werklast toeneemt of er nieuwe applicaties bijkomen.<\/p>\n\n<h2>Aantal instanties kiezen: vuistregels met gezond verstand<\/h2>\n\n<p>Bij grotere pools begin ik graag met \u201e\u00e9\u00e9n instantie per GB\u201c, maar ik beperk het meestal tot 8\u201316 instanties, zodat het beheer niet te veel tijd gaat kosten. Bij een poolgrootte van minder dan ongeveer 1 GB zie ik af van instanties, omdat het nut daarvan gering is. Daarnaast zorg ik ervoor dat elke instantie minimaal 1 GB heeft, anders wordt de fragmentatie te groot in verhouding tot het voordeel. Ik houd bovendien rekening met het aantal CPU-kernen en de verwachte parallelliteit, zodat de instanties op een zinvolle manier worden toegewezen. Op een server met 8 kernen en een pool van 16 GB draai ik bijvoorbeeld 8 instanties van elk ongeveer 2 GB, wat de <strong>Bronnen<\/strong> goed verdeeld en conflicten verminderd.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/mariadb-buffer-pool-performance-1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Hoe InnoDB pagina\u2019s over instanties verdeelt<\/h2>\n\n<p>Als ik het over instanties heb, denk ik niet aan \u201eafzonderlijke caches per tabel\u201c, maar aan een interne, <strong>deterministische verdeling<\/strong> afzonderlijke pagina\u2019s (gegevens- en indexpagina\u2019s) over meerdere deelpools. De toewijzing is gebaseerd op interne ID\u2019s en hashes; daardoor komen dezelfde gebieden consequent in dezelfde instantie terecht. Dat is goed voor de lokaliteit, maar heeft een belangrijk gevolg: een <em>enige<\/em> De hotspot (bijvoorbeeld de \u201elaatste\u201c Leaf-pagina bij monotoon toenemende primaire sleutels) blijft een hotspot <em>binnen<\/em> \u00e9\u00e9n instantie. Meer instanties lossen dergelijke ontwerp-knelpunten niet op, maar ze ontkoppelen verschillende hotsets van elkaar en verminderen de globale mutex-contention. Daarom controleer ik bovendien de sleutelopbouw en het queryprofiel om <strong>Populaire pagina's<\/strong> te voorkomen dat ze \u00fcberhaupt ontstaan.<\/p>\n\n<h2>NUMA en cache-localiteit op de juiste manier gebruiken<\/h2>\n\n<p>Op systemen met een NUMA-architectuur controleer ik de geheugenplaatsing, zodat threads zo dicht mogelijk bij hun gegevens rekenen. Een goede strategie vermindert het aantal externe toegangen, wat de latentie verlaagt en de variantie beperkt. Ik stem het aantal instances, CPU-pinning en het geheugenbeleid op elkaar af om de cache-lokaliteit te versterken. Wie hierover meer details wil, kan een kijkje nemen bij de beknopte <a href=\"https:\/\/webhosting.de\/nl\/numa-geheugenbeleid-databankserver-optimalisatie-server\/\">NUMA-beleidsregels<\/a> voor databaseservers. Zo houd ik de datapaden kort en zorg ik voor een consistente <strong>Prestaties<\/strong> ook onder druk.<\/p>\n\n<h2>Flush-strategie, Page Cleaner en I\/O-capaciteit<\/h2>\n\n<p>Een goed ingedeelde bufferpool laat pas echt zien wat hij in huis heeft als de <strong>Achtergrondverversing<\/strong> loopt soepel. Ik houd de lengte van de flush- en LRU-lijsten in de gaten en pas de I\/O-capaciteiten aan, zodat de Page Cleaner pieken verwerkt zonder bursts te veroorzaken. Typische instellingsparameters zijn innodb_io_capacity en innodb_io_capacity_max, die ik afstem op het onderliggende opslagsubsysteem (SSD aanzienlijk hoger dan HDD). Op flashmedia schakel ik graag het \u201eneighbors\u201c-flushen uit, zodat ik niet onnodig pagina\u2019s wegspoel die toch binnenkort worden vervangen. Gelijkmatige checkpoints en korte flush-wachtrijen houden de latentie stabiel \u2013 dit heeft direct een positief effect op de prestaties van meerdere instanties, omdat er minder threads hoeven te wachten op schrijfbewerkingen op de achtergrond.<\/p>\n\n<h2>LRU-beleid, read-ahead en \u201ekoud\u201c verkeer<\/h2>\n\n<p>Ik bekijk hoe workloads pagina\u2019s door de LRU verplaatsen. Bij sterk sequenti\u00eble scans voorkom ik met een passende \u201eOld-Blocks\u201c-tijd dat koude toegangen het jonge gedeelte verdringen. Read-Ahead helpt bij echte sequenties, maar belast de pool bij willekeurige patronen. Hier geldt: eerst meetbaar maken, daarna nauwkeurig doseren. Het doel van de oefening is om de <strong>jonge LRU-afdeling<\/strong> voor te behouden voor de actuele gegevens, zodat zoekopdrachten herhaaldelijk uit <em>dezelfde<\/em> Instance en of CPU-caches de moeite waard zijn. Juist bij meerdere instances valt onjuiste read-ahead meer op, omdat deze op verrassend gelijkmatige wijze \u201eruis\u201c over de deelpools verspreidt.<\/p>\n\n<h2>Adaptieve hash-index en wijzigingsbuffer<\/h2>\n\n<p>Ik controleer of de <strong>Adaptieve hash-index (AHI)<\/strong> voor mijn patroon helpt of juist in de weg zit. Bij zeer hoge parallelliteit kan de AHI zelf een knelpunt worden. Dan is het de moeite waard om deze bij wijze van proef te vertragen of uit te schakelen en het effect op de latenties te observeren. Voor schrijfintensieve workloads met veel invoegingen in secundaire indexen heeft de <strong>Buffer wijzigen<\/strong> Invloed op I\/O en paginarotatie. Een grotere bufferpool vermindert de druk hierop, omdat meer indexpagina\u2019s \u2018warm\u2019 blijven en invoegingen minder vaak in \u2018koude\u2019 structuren terechtkomen. Ik breng deze observaties in verband met het aantal instanties: als ik door meer instanties de globale locks ontkoppel, wordt duidelijker of AHI of Change Buffer de daadwerkelijke bottleneck is.<\/p>\n\n<h2>Warmstarts: bufferpool-dumps laden<\/h2>\n\n<p>Na het opnieuw opstarten wil ik geen minutenlange \u201ekoude\u201c vertragingen zien. Daarom schakel ik de <strong>Leegmaken en vullen<\/strong> \u2018hete\u2019 pagina\u2019s bij het afsluiten\/opstarten. Zo start de dienst met een reeds gevulde pool, ligt het hitpercentage sneller weer dicht bij 99 %, en zie ik de prestatie-effecten van mijn instantiekeuze, zonder dat een koude cache het beeld vertekent. Dit versnelt met name roll-outs en kernel-updates en is mijn standaard in productieomgevingen, waar ik stabiliteit boven pure piekwaarden stel.<\/p>\n\n<h2>Configuratie in my.cnf en opnieuw opstarten<\/h2>\n\n<p>Ik voer de instellingen gestructureerd in het my.cnf-bestand in en documenteer elke wijziging zorgvuldig. Belangrijk: definieer eerst de doelgrootte van de pool, stel vervolgens het aantal instanties in en voer daarna een herstart uit. Na de herstart controleer ik in SHOW VARIABLES of de waarden van kracht zijn en verifieer ik de verdeling in SHOW ENGINE INNODB STATUS. Zo zorg ik ervoor dat de machine daadwerkelijk met de gekozen verdeling werkt. Bij aanpassingen ga ik in kleine stapjes te werk, zodat ik de effecten duidelijk kan toewijzen en de <strong>Stabiliteit<\/strong> van de bedrijfsvoering niet in gevaar brengt.<\/p>\n<pre><code># Voorbeeld\ninnodb_buffer_pool_size = 12G\ninnodb_buffer_pool_instances = 8\ninnodb_log_file_size = 2G\ninnodb_flush_log_at_trx_commit = 1\n<\/code><\/pre>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/mariadb_buffer_performance_1742.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Monitoring: kengetallen die er echt toe doen<\/h2>\n\n<p>Ik meet eerst de hit-rate van de pool, daarna de latentie, de I\/O-belasting en de wachttijden voor locks. Voor het dagelijks gebruik volstaan enkele, maar veelzeggende kengetallen, die ik regelmatig controleer en in tijdreeksen opsla. Als de hit-rate onder 99 % daalt, overweeg ik een grotere poolgrootte voordat ik het aantal instanties verhoog. Als de wachttijden voor mutexen toenemen terwijl de hit-rate eigenlijk goed is, test ik meer instanties, maar alleen stapsgewijs. Zo blijf ik flexibel, herken ik trends vroegtijdig en concentreer ik me op de echte <strong>Knelpunten<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Sleutelfiguur<\/th>\n      <th>Doelwaarde<\/th>\n      <th>Vraag<\/th>\n      <th>Tip<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Hitpercentage van de bufferpool<\/td>\n      <td>\u2265 99 %<\/td>\n      <td><code>SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_%';<\/code><\/td>\n      <td>Bij lage waarden: vergroot de pool of <strong>Werkbelasting<\/strong> optimaliseren van<\/td>\n    <\/tr>\n    <tr>\n      <td>Lees-\/schrijfbewerkingen per seconde<\/td>\n      <td>constant<\/td>\n      <td><code>SHOW GLOBAL STATUS LIKE 'Innodb_data_reads';<\/code><\/td>\n      <td>Sprongen duiden op I\/O-bottlenecks en onjuiste <strong>Maten<\/strong> daarheen<\/td>\n    <\/tr>\n    <tr>\n      <td>Wachttijden voor mutexen\/locks<\/td>\n      <td>laag<\/td>\n      <td><code>SHOW ENGINE INNODB STATUS;<\/code><\/td>\n      <td>Verhoog indien nodig het aantal instanties bij wachttijden<\/td>\n    <\/tr>\n    <tr>\n      <td>Gedrag bij controleposten<\/td>\n      <td>gelijkmatig<\/td>\n      <td><code>SHOW GLOBAL STATUS LIKE 'Innodb_checkpoint_%';<\/code><\/td>\n      <td>De grootte van het redo-log en de flush-strategie aanpassen<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Ik koppel de meetpunten aan implementaties, wijzigingen in het schema en pieken, zodat ik oorzaak en gevolg aan elkaar kan koppelen. Met duidelijke aantekeningen bespaar ik tijd en verklein ik het risico dat ik dezelfde fouten herhaal. Zo groeit er stap voor stap een robuuste <strong>Praktijkgericht<\/strong> voor mijn bedrijf.<\/p>\n\n<h2>Fijnafstemming: stapsgewijs aanpassen in plaats van grote sprongen<\/h2>\n\n<p>Ik pas nooit meerdere parameters tegelijk aan, maar evalueer ze \u00e9\u00e9n voor \u00e9\u00e9n en in kleine stapjes. Eerst de poolgrootte, dan de instanties, daarna de redo-log- en flush-strategie\u00ebn, en tot slot de thread-parameters. Na elke wijziging wacht ik lang genoeg totdat het effect zichtbaar wordt en leg ik de statistieken vast. Juist bij workloads met wisselend verkeer loont het de moeite om gedurende meerdere dagen te observeren. Zo voorkom ik dat ik in het duister tast en houd ik de <strong>Vermogenscurve<\/strong> duidelijk te interpreteren.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/MariaDB_Performance_Desk_6932.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Benchmarkprocedure: betrouwbaar testen<\/h2>\n\n<p>Ik maak een duidelijk onderscheid tussen laboratorium en productie. In het laboratorium verwarm ik de pool, doorloop ik verschillende belastingniveaus (bijv. 4\/8\/16\/32 threads) en varieer ik de verhouding tussen lees- en schrijfbewerkingen. Ik meet P95\/P99-latenties, doorvoer en wachttijden op mutexen. Doorslaggevend is de <strong>Reproduceerbaarheid<\/strong>: dezelfde hoeveelheid gegevens, dezelfde gegevensverdeling, dezelfde testperiode. Pas als een configuratie in twee tot drie onafhankelijke testruns consistent beter presteert, neem ik deze in productie. Daar implementeer ik deze <em>canary<\/em>-achtig en vergelijk tijdreeksen v\u00f3\u00f3r en na de wijziging. Deze werkwijze voorkomt dat toevallige schommelingen als \u201eoptimalisatie\u201c worden beschouwd.<\/p>\n\n<h2>Typische valkuilen en antipatronen<\/h2>\n\n<ul>\n  <li><strong>Te veel instanties:<\/strong> De beheerkosten stijgen, LRU-\/flush-lijsten worden te fragmentarisch en achtergrondthreads werken ineffici\u00ebnt. Ik blijf conservatief (2\u20138) en verhoog de waarde alleen als dat op basis van metingen nodig is.<\/li>\n  <li><strong>Te kleine instanties:<\/strong> Bij minder dan 1 GB per instantie slaat de balans snel om. Het is beter om minder, maar grotere instanties te gebruiken.<\/li>\n  <li><strong>Koude cache in analyses:<\/strong> Uitspraken over de invloed van de instantie hebben geen betekenis als de pool koud is. Maak gebruik van warmstarts of lange testvensters.<\/li>\n  <li><strong>Ontwerpfouten op de startpagina:<\/strong> Monotone sleutels zonder spreiding, brede secundaire indexen of ontbrekende dekkingsindexen veroorzaken hotspots die door geen enkel aantal instanties kunnen worden verholpen.<\/li>\n  <li><strong>Onjuiste I\/O-instellingen:<\/strong> SSD\u2019s met flush-parameters die typisch zijn voor HDD\u2019s laten potentieel onbenut en veroorzaken pieken die ten onrechte aan de instances worden toegeschreven.<\/li>\n<\/ul>\n\n<h2>Hosting en VPS in de praktijk: RAM, cores, workload<\/h2>\n\n<p>In gedeelde omgevingen stel ik de pool conservatiever in, zodat webservers, caches en het besturingssysteem voldoende ruimte overhouden. Op VPS\u2019en of dedicated servers wijs ik meer RAM toe aan de pool, zodat de hit-rate hoog blijft. Ik verdeel de instances zo dat ze goed aansluiten bij de vCPU's en minimaal 1 GB per instance behouden. Wie krachtige hosting- of serveroplossingen nodig heeft, kiest voor de aanbiedingen van webhoster.de, omdat hier de processorkernen, het RAM-geheugen en de I\/O-prestaties zijn afgestemd op intensieve parallelliteit. Met deze basis houd ik de latenties laag en benut ik de <strong>Meerdere kernen<\/strong> beter.<\/p>\n\n<h2>Threadpool en parallelle toegang<\/h2>\n\n<p>Zelfs een goed verdeelde bufferpool heeft weinig nut als er te veel verbindingen tegelijkertijd om toegang strijden. Daarom pas ik de limieten voor verbindingen en threads aan en controleer ik of de <a href=\"https:\/\/webhosting.de\/nl\/mariadb-threadpool-serverprestaties-tempel\/\">Threadpool<\/a> voordelen oplevert voor mijn systeem. Het doel is om actieve workers constant te benutten zonder dat er opstoppingen ontstaan. Ik zorg ervoor dat korte, frequente verzoeken niet vastlopen achter zware transacties. Met een strakke aansturing verhoog ik de effici\u00ebntie per kern en verzeker ik mezelf van betrouwbare <strong>Reactietijden<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/serverraum-mariadb-performance-2145.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Korte samenvatting: instellingen die voor mij werken<\/h2>\n\n<p>Ik controleer eerst de <strong>Versie<\/strong> en beslis ik of `innodb_buffer_pool_instances` effectief is, of dat ik me concentreer op de grootte van de pool, de redo-logs en de threads. Vervolgens dimensioner ik de pool zo dat de actieve gegevens erin passen, en stel ik het aantal instanties zo in dat elke instantie minimaal 1 GB krijgt. Op systemen met meerdere kernen streef ik naar 2\u20138 instanties en verhoog ik het aantal alleen bij aantoonbare mutex-contention. Ik houd mijn monitoring eenvoudig maar consequent en pas parameters in kleine stapjes aan met duidelijke meetpunten. Zo bereik ik constante latenties, een betere benutting en een merkbaar effici\u00ebntere <strong>Doorvoer<\/strong> voor mijn MariaDB-workloads.<\/p>","protected":false},"excerpt":{"rendered":"<p>Ontdek hoe je met MariaDB-bufferpool-instanties op systemen met meerdere processorkernen gerichte MariaDB-tuning en effectieve database-optimalisatie kunt realiseren.<\/p>","protected":false},"author":1,"featured_media":21176,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-21183","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-datenbanken-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"148","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"MariaDB Buffer","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"21176","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/21183","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/comments?post=21183"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/21183\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media\/21176"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media?parent=21183"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/categories?post=21183"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/tags?post=21183"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}