{"id":53966,"date":"2019-12-14T00:00:00","date_gmt":"2019-12-13T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/ispolzovanie-partitsionirovaniya-v-mysql-dlya-zabbix-s-bolshim-kolichestvom-obektov-monitoringa"},"modified":"2020-02-18T14:01:55","modified_gmt":"2020-02-18T11:01:55","slug":"ispolzovanie-partitsionirovaniya-v-mysql-dlya-zabbix-s-bolshim-kolichestvom-obektov-monitoringa","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/ispolzovanie-partitsionirovaniya-v-mysql-dlya-zabbix-s-bolshim-kolichestvom-obektov-monitoringa","title":{"rendered":"Gebruik van partitionering in MySQL voor Zabbix met een groot aantal monitorobjecten","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Voor het monitoren van servers en diensten maken we al lange tijd gebruik van een gecombineerde oplossing op basis van Nagios en Munin, en dat nog steeds met succes. Echter, deze combinatie kent een aantal tekortkomingen, daarom maken wij, net als velen anderen, actief gebruik van Zabbix<\/a><\/noindex>. In dit artikel zullen we uitleggen hoe je met minimale inspanning de prestatieproblemen kunt oplossen die ontstaan bij het toenemen van de gemeten metrics en de groei van MySQL-databasevolumes.
\n<\/a><\/noindex><\/p>\n

Problemen met het gebruik van MySQL-databases in combinatie met Zabbix<\/h3>\n

\nZolang de database klein was en het aantal opgeslagen metrics beperkt, was alles geweldig. Het standaard proces housekeeper, dat op Zabbix Server draait, verwijderde succesvol verouderde records uit de database, waardoor deze niet bleef groeien. Maar zodra het aantal gemeten metrics toenam en het volume van de database een bepaalde grootte bereikte, ging het mis. De housekeeper had niet genoeg tijd om data te verwijderen binnen de toegewezen tijdsinterval, waardoor oude gegevens in de database bleven. Tijdens het functioneren van de housekeeper was er een verhoogde belasting op de Zabbix Server die langdurig aanhield. Het was duidelijk dat we op een of andere manier de ontstane situatie moesten oplossen.<\/p>\n

Dit is een bekend probleem; vrijwel iedereen die met grote hoeveelheden monitoring op Zabbix heeft gewerkt, heeft ditzelfde ervaren. Er zijn ook verschillende oplossingen voorgesteld: bijvoorbeeld de vervanging van MySQL door PostgreSQL of zelfs Elasticsearch, maar de meest eenvoudige en beproefde oplossing was de overgang naar partitionering van de tabellen die de metricgegevens in de MySQL-database opslaan. We besloten precies deze weg in te slaan.<\/p>\n

De overstap van gewone MySQL-tabellen naar partitionering<\/h3>\n

\nZabbix is goed gedocumenteerd en de tabellen waarin het metrics opslaat zijn bekend. Dit zijn de tabellen: history<\/code>, waarin float-waarden worden opgeslagen, history_str<\/code>, waarin korte stringwaarden worden opgeslagen, history_text<\/code>, waarin lange tekstwaarden worden opgeslagen en history_uint<\/code>, waarin gehele getallen worden opgeslagen. Er is ook een tabel trends<\/code>, die veranderingen in dynamiek opslaat, maar deze hebben we niet aangeraakt omdat de grootte ervan klein is en we er later op terug zullen komen.<\/p>\n

In het algemeen was het duidelijk welke tabellen verwerkt moesten worden. We hebben besloten om partities te maken voor elke week, met uitzondering van de laatste, op basis van de dagen van de maand, dat wil zeggen, vier partities per maand: van de 1e tot de 7e, van de 8e tot de 14e, van de 15e tot de 21e en van de 22e tot de 1e (van de volgende maand). De moeilijkheid zat hem erin dat we de tabellen die we nodig hadden, 'on-the-fly' moesten omzetten naar gepartitioneerde tabellen, zonder de werking van de Zabbix Server en het verzamelen van metrics te onderbreken.<\/p>\n

Vreemd genoeg kwam de structuur van de tabellen ons hierbij te hulp. Bijvoorbeeld, de tabel history <\/code>heeft de volgende structuur:<\/p>\n

`itemid` bigint(20) unsigned NOT NULL,\n`clock` int(11) NOT NULL DEFAULT '0',\n`value` double(16,4) NOT NULL DEFAULT '0.0000',\n`ns` int(11) NOT NULL DEFAULT '0',<\/code><\/pre>\n
\nbij deze<\/p>\n
KEY `history_1` (`itemid`,`clock`)<\/code><\/pre>\n
\nZoals we zien, wordt elke metric uiteindelijk in de tabel ingevoerd met twee zeer belangrijke en handige velden voor ons, itemid<\/b> en clock<\/b>. Op deze manier kunnen we gemakkelijk een tijdelijke tabel cre\u00ebren, bijvoorbeeld met de naam history_tmp<\/code>, deze partitioneren en vervolgens al de gegevens uit de tabel history<\/code>, en daarna de tabel hernoemen naar history<\/code> in history_old<\/code>, en de tabel history_tmp<\/code> in history<\/code>, waarna we de gegevens die nog niet zijn ingevoerd vanuit history_old<\/code> in history <\/code>kunnen toevoegen en history_old<\/code>verwijderen. Dit kan absoluut veilig worden gedaan, we verliezen niets, want de hierboven genoemde velden itemid <\/b>en clock <\/b>garanderen de koppeling van een specifieke metric aan een bepaald tijdstip, en niet aan een willekeurig volgnummer.<\/p>\n
De procedure voor de overgang<\/h3>\n
<\/p>\n
Let op! Het is zeer wenselijk om, voordat je met enige actie begint, een volledige back-up van de database te maken. We zijn allemaal mensen en kunnen fouten maken bij het invoeren van commando's, wat kan leiden tot gegevensverlies. Ja, een back-up biedt misschien niet de meest actuele informatie, maar het is beter om er een te hebben dan helemaal geen.<\/p><\/blockquote>\n
 Dus, we schakelen niets uit en stoppen niets. Het belangrijkste is dat er op de MySQL-server voldoende vrije schijfruimte beschikbaar is, dat wil zeggen dat er voor elke van de hierboven genoemde tabellen history<\/code>, history_text<\/code>, history_str<\/code>, history_uint<\/code>, minstens voldoende ruimte is voor het aanmaken van de tabel met de suffix '_tmp', rekening houdend met het feit dat deze dezelfde grootte zal hebben als de oorspronkelijke tabel.<\/p>\n
We zullen niet alles meerdere keren voor elke van de bovengenoemde tabellen beschrijven en bekijken alles aan de hand van slechts \u00e9\u00e9n van hen \u2014 de tabel history<\/code>.<\/p>\n
Dus, we cre\u00ebren een lege tabel history_tmp <\/code>op basis van de structuur van de tabel history<\/code>.<\/p>\n
CREATE TABLE `history_tmp` LIKE `history`;<\/code><\/pre>\n
\nWe create the necessary partitions. For example, we will do this for a month. Each partition is created based on a partitioning rule derived from the value of the field clock<\/b>, which we compare with a timestamp:<\/p>\n
ALTER TABLE `history_tmp` PARTITION BY RANGE( clock ) (\nPARTITION p20190201 VALUES LESS THAN (UNIX_TIMESTAMP(\"2019-02-01 00:00:00\")),\nPARTITION p20190207 VALUES LESS THAN (UNIX_TIMESTAMP(\"2019-02-07 00:00:00\")),\nPARTITION p20190214 VALUES LESS THAN (UNIX_TIMESTAMP(\"2019-02-14 00:00:00\")),\nPARTITION p20190221 VALUES LESS THAN (UNIX_TIMESTAMP(\"2019-02-21 00:00:00\")),\nPARTITION p20190301 VALUES LESS THAN (UNIX_TIMESTAMP(\"2019-03-01 00:00:00\"))\n);<\/code><\/pre>\n
\nThis operator adds partitioning to the table we created history_tmp<\/code>. It's important to note that data with the field value clock <\/b>less than \"2019-02-01 00:00:00\" will go into partition p20190201<\/i>, then data with the field value clock<\/b> greater than \"2019-02-01 00:00:00\" but less than \"2019-02-07 00:00:00\" will go into partition p20190207 <\/i>en zo verder.<\/p>\n
Important note:<\/b> What happens if we have data in the partitioned table where the clock field value is greater than or equal to \"2019-03-01 00:00:00\"? Since there is no suitable partition for this data, it will not enter the table and will be lost. Therefore, you need to remember to timely create additional partitions to avoid such data loss (as mentioned below).<\/p><\/blockquote>\n
 So, the temporary table is ready. Let's load the data. This process may take quite a while, but fortunately, it doesn't block any other queries, so you just need to be patient:<\/p>\n
INSERT IGNORE INTO `history_tmp` SELECT * FROM history;<\/code><\/pre>\n
\nThe IGNORE keyword during the initial load is not mandatory, as there is still no data in the table, but you will need it when reloading data. Additionally, it can be useful if you had to interrupt the loading process and start over.<\/p>\n
So, after some time (possibly even several hours), the first data load was completed. As you can understand, now the table history_tmp <\/code>contains not all the data from the table history<\/code>, but only those that were in it at the moment the query started executing. Here you actually have a choice: either we make another pass (if the loading process took a long time), or we immediately proceed to renaming the tables, as mentioned above. Let's first talk about the second pass. For starters, we need to understand the time of the last inserted record in history_tmp<\/code>:<\/p>\n
SELECT max(clock) FROM history_tmp;<\/code><\/pre>\n
\nSuppose you received: 1551045645<\/b>Laten we nu de verkregen waarde gebruiken tijdens de tweede gegevensinvoerpoging:<\/p>\n
INSERT IGNORE INTO `history_tmp` SELECT * FROM history WHERE clock>=1551045645;<\/code><\/pre>\n
\nDeze poging zou aanzienlijk sneller moeten eindigen. Maar als de eerste poging uren duurde en de tweede ook enige tijd kostte, kan het verstandig zijn om een derde poging te doen die volledig vergelijkbaar is met de tweede.<\/p>\n
Aan het einde voeren we opnieuw de operatie uit om de tijd van de laatste invoer van een record in history_tmp<\/code>, door:<\/p>\n
SELECT max(clock) FROM history_tmp;<\/code><\/pre>\n
\nStel dat u heeft verkregen 1551085645<\/b>. Bewaar deze waarde \u2014 we hebben deze nodig voor de vervolginvoeren.<\/p>\n
En nu, wanneer de initi\u00eble gegevensinvoer in history_tmp <\/code>is voltooid, gaan we de tabellen hernoemen:<\/p>\n
BEGIN;\nRENAME TABLE history TO history_old;\nRENAME TABLE history_tmp TO history;\nCOMMIT;<\/code><\/pre>\n
\nWe hebben dit blok als \u00e9\u00e9n transactie ingericht om te voorkomen dat er gegevens in een niet-bestaande tabel worden ingevoegd, aangezien na de eerste RENAME, tot het moment van de tweede RENAME, de tabel history <\/code>niet zal bestaan. Maar zelfs als er tussen de RENAME-operaties enkele gegevens in de tabel komen, en de tabel zelf nog niet bestaat (door de hernoeming), zullen we een klein aantal invoerfouten krijgen die we kunnen negeren (het is een monitoring en geen bank). history <\/code>Nu hebben we een nieuwe tabel<\/p>\n
met partitionering, maar deze heeft niet de gegevens die zijn verkregen tijdens de laatste invoer in de tabel history<\/code> . Maar deze gegevens hebben we in de tabel history_tmp<\/code>en we zullen ze daar nu vanuit aanvullen. Hiervoor hebben we de eerder opgeslagen waarde 1551085645 nodig. Waarom hebben we deze waarde opgeslagen en niet de maximale invoertijd uit de huidige tabel gebruikt? history_old <\/code>INSERT IGNORE INTO `history` SELECT * FROM history_old WHERE clock>=1551045645; history<\/code>? \u041f\u043e\u0442\u043e\u043c\u0443 \u0447\u0442\u043e \u043d\u043e\u0432\u044b\u0435 \u0434\u0430\u043d\u043d\u044b\u0435 \u0443\u0436\u0435 \u0432 \u043d\u0435\u0451 \u043f\u043e\u0441\u0442\u0443\u043f\u0430\u044e\u0442 \u0438 \u043c\u044b \u043f\u043e\u043b\u0443\u0447\u0438\u043c \u043d\u0435\u0432\u0435\u0440\u043d\u043e\u0435 \u0432\u0440\u0435\u043c\u044f. \u0418\u0442\u0430\u043a, \u0434\u043e\u0437\u0430\u043b\u0438\u0432\u0430\u0435\u043c \u0434\u0430\u043d\u043d\u044b\u0435:<\/p>\n
Na het voltooien van deze operatie hebben we in de nieuwe, gepartitioneerde tabel<\/code><\/pre>\n
\nalle gegevens die in de oude waren, plus die welke zijn binnengekomen na de hernoeming van de tabel. De tabel history <\/code>is niet meer nodig. We kunnen deze meteen verwijderen, of v\u00f3\u00f3r verwijdering een back-up maken (mocht je paranoia hebben). history_old <\/code>Het bovenstaande proces moet worden herhaald voor de tabellen<\/p>\n
Wat moet er aangepast worden in de instellingen van de Zabbix Server history_str<\/code>, history_text <\/code>en history_uint<\/code>.<\/p>\n
Wat moet er worden aangepast in de instellingen van Zabbix Server<\/h3>\n
\nNu valt het onderhoud van de database met betrekking tot de gegevensgeschiedenis op onze schouders. Dit betekent dat Zabbix geen oude gegevens meer hoeft te verwijderen - dat doen wij zelf. Om ervoor te zorgen dat de Zabbix Server de gegevens niet zelf probeert schoon te maken, moet je in de webinterface van Zabbix naar het menu 'Administratie' gaan, vervolgens naar het submenu 'Algemeen', en daarna in de dropdown rechts 'Geschiedenis opschonen' kiezen. Op de pagina die verschijnt, moet je alle vakjes voor de groep 'Geschiedenis' uitschakelen en op de knop 'Bijwerken' klikken. Dit voorkomt onnodige opschoning van tabellen. geschiedenis*<\/code> via housekeeper.<\/p>\n
Let op de groep 'Veranderdynamiek' op dezelfde pagina. Dit is de tabel waar we eerder op terugkwamen. trends<\/code>Als deze ook te groot is geworden en partitionering nodig heeft, haal dan ook hier de vinkjes weg en behandel deze tabel op dezelfde manier als de tabellen. geschiedenis*<\/code>.<\/p>\n
Voortdurend onderhoud van de database<\/h3>\n
\nZoals eerder vermeld, is het voor een goede werking met gepartitioneerde tabellen noodzakelijk om op tijd partities te maken. Dit kan als volgt:<\/p>\n
ALTER TABLE `geschiedenis` ADD PARTITION (PARTITION p20190307 VALUES LESS THAN (UNIX_TIMESTAMP(\"2019-03-07 00:00:00\")));<\/code><\/pre>\n
\nBovendien, aangezien we gepartitioneerde tabellen hebben gemaakt en Zabbix Server verboden hebben ze op te schonen, is het verwijderen van oude gegevens nu onze verantwoordelijkheid. Gelukkig zijn er hier helemaal geen problemen. Dit gebeurt eenvoudigweg door de partitie te verwijderen waarvan de gegevens niet meer nodig zijn. <\/p>\n
Bijvoorbeeld:<\/p>\n
ALTER TABLE geschiedenis DROP PARTITION p20190201;<\/code><\/pre>\n
\nIn tegenstelling tot de DELETE FROM-operators met een datumbereik, wordt DROP PARTITION binnen enkele seconden uitgevoerd, zonder enige belasting. server<\/a> En werkt even probleemloos bij gebruik in MySQL-replicatie.<\/p>\n
Conclusie<\/h3>\n
\nDe beschreven oplossing heeft de tand des tijds doorstaan. Het volume van de gegevens groeit, maar er wordt geen merkbare vertraging in de prestaties opgemerkt.
\n
Bron: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
\u0414\u043b\u044f \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432 \u0438 \u0441\u043b\u0443\u0436\u0431 \u0443 \u043d\u0430\u0441 \u0434\u0430\u0432\u043d\u043e, \u0438 \u0432\u0441\u0435 \u0435\u0449\u0435 \u0443\u0441\u043f\u0435\u0448\u043d\u043e, \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u0442\u0441\u044f \u043a\u043e\u043c\u0431\u0438\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u043e\u0435 \u0440\u0435\u0448\u0435\u043d\u0438\u0435 \u043d\u0430 \u0431\u0430\u0437\u0435 Nagios \u0438 Munin. \u041e\u0434\u043d\u0430\u043a\u043e \u044d\u0442\u0430 \u0441\u0432\u044f\u0437\u043a\u0430 \u0438\u043c\u0435\u0435\u0442 \u0440\u044f\u0434 \u043d\u0435\u0434\u043e\u0441\u0442\u0430\u0442\u043a\u043e\u0432, \u043f\u043e\u044d\u0442\u043e\u043c\u0443 \u043c\u044b, \u043a\u0430\u043a \u0438 \u043c\u043d\u043e\u0433\u0438\u0435, \u0430\u043a\u0442\u0438\u0432\u043d\u043e \u044d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0438\u0440\u0443\u0435\u043c Zabbix. \u0412 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u043c\u044b \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0435\u043c \u043e \u0442\u043e\u043c, \u043a\u0430\u043a \u043c\u0438\u043d\u0438\u043c\u0430\u043b\u044c\u043d\u044b\u043c\u0438 \u0443\u0441\u0438\u043b\u0438\u044f\u043c\u0438 \u043c\u043e\u0436\u043d\u043e \u0440\u0435\u0448\u0438\u0442\u044c \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0443 \u0441 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c\u044e \u043f\u0440\u0438 \u0443\u0432\u0435\u043b\u0438\u0447\u0435\u043d\u0438\u0438 \u0447\u0438\u0441\u043b\u0430 \u0441\u043d\u0438\u043c\u0430\u0435\u043c\u044b\u0445 \u043c\u0435\u0442\u0440\u0438\u043a \u0438 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-53966","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47 Gebruik van partitionering in MySQL voor Zabbix met een groot aantal te monitoren objecten | ProHoster","description":"Voor het monitoren van servers en diensten maken we al lange tijd, en nog steeds met succes, gebruik van een gecombineerde oplossing gebaseerd op Nagios en Munin.","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/ispolzovanie-partitsionirovaniya-v-mysql-dlya-zabbix-s-bolshim-kolichestvom-obektov-monitoringa","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nl_NL","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0418\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u0435 \u043f\u0430\u0440\u0442\u0438\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0432 MySQL \u0434\u043b\u044f Zabbix \u0441 \u0431\u043e\u043b\u044c\u0448\u0438\u043c \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u043e\u043c \u043e\u0431\u044a\u0435\u043a\u0442\u043e\u0432 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430 | ProHoster","og:description":"\u0414\u043b\u044f \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432 \u0438 \u0441\u043b\u0443\u0436\u0431 \u0443 \u043d\u0430\u0441 \u0434\u0430\u0432\u043d\u043e, \u0438 \u0432\u0441\u0435 \u0435\u0449\u0435 \u0443\u0441\u043f\u0435\u0448\u043d\u043e, \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u0442\u0441\u044f \u043a\u043e\u043c\u0431\u0438\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u043e\u0435 \u0440\u0435\u0448\u0435\u043d\u0438\u0435 \u043d\u0430 \u0431\u0430\u0437\u0435 Nagios \u0438 Munin.","og:url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/ispolzovanie-partitsionirovaniya-v-mysql-dlya-zabbix-s-bolshim-kolichestvom-obektov-monitoringa","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-12-13T21:00:00+00:00","article:modified_time":"2020-02-18T11:01:55+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"53966","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-24 09:31:21","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 20:14:29","updated":"2026-01-24 09:31:21","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/53966","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=53966"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/53966\/revisions"}],"predecessor-version":[{"id":172868,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/53966\/revisions\/172868"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=53966"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=53966"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=53966"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}