{"id":21119,"date":"2026-08-28T18:18:54","date_gmt":"2026-08-28T16:18:54","guid":{"rendered":"https:\/\/webhosting.de\/mariadb-undo-logs-administrator-guide-technik\/"},"modified":"2026-08-28T18:18:54","modified_gmt":"2026-08-28T16:18:54","slug":"mariadb-log-di-undo-guida-per-lamministratore-tecnica","status":"publish","type":"post","link":"https:\/\/webhosting.de\/it\/mariadb-undo-logs-administrator-guide-technik\/","title":{"rendered":"Log di annullamento di MariaDB: nozioni di base per gli amministratori"},"content":{"rendered":"<p><strong>MariaDB Undo<\/strong> controlla il modo in cui InnoDB memorizza le vecchie versioni delle righe, esegue i rollback in modo sicuro e garantisce viste di lettura coerenti mentre sono in corso le operazioni di scrittura. Mostrer\u00f2 come gli Undo Log interagiscono con la History List e il Purge, perch\u00e9 le transazioni lunghe occupano memoria e come gestisco la crescita della <strong>Annulla<\/strong>- Controllo delle aree.<\/p>\n\n<h2>Punti centrali<\/h2>\n\n<ul>\n  <li><strong>MVCC<\/strong> e letture coerenti: Undo salva le versioni precedenti, senza bloccare i lettori.<\/li>\n  <li><strong>Elenco cronologico<\/strong>: I commit aggiungono elementi alla cronologia, mentre \"Purge\" li rimuove.<\/li>\n  <li><strong>Transazioni lunghe<\/strong>: Mantengono le vecchie versioni, aumentano l'utilizzo della memoria e le latenze.<\/li>\n  <li><strong>Configurazione<\/strong>: Gli spazi tabella \"Undo\", i thread \"Purge\" e il comando \"Truncate\" controllano la crescita.<\/li>\n  <li><strong>Monitoraggio<\/strong>: Verificare tempestivamente la lunghezza dello storico, l'et\u00e0 delle transazioni e le dimensioni delle operazioni di annullamento.<\/li>\n<\/ul>\n\n<h2>In che modo gli Undo Logs rendono possibile l'MVCC<\/h2>\n\n<p>Comincio dall'essenziale: ogni modifica salva la versione precedente della riga nel <strong>Annulla<\/strong>-Log, affinch\u00e9 uno snapshot coerente continui a essere valido. I lettori accedono alla versione precedente appropriata, mentre chi scrive archivia i nuovi dati e aggiorna gli indici; in questo modo <strong>Parallelismo<\/strong> alto. Le righe si concatenano alle precedenti fino a quando Purge non pu\u00f2 cancellarle. Senza questa catena, i rollback andrebbero persi e le viste di lettura verrebbero compromesse. \u00c8 proprio qui che Undo funge da ponte tra sicurezza delle transazioni, isolamento e accessi in lettura affidabili.<\/p>\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-admin-5847.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Struttura interna dei log di annullamento<\/h2>\n\n<p>A livello tecnico, distinguo principalmente due tipi di Undo: <em>Annulla inserimento<\/em> e <em>Annulla aggiornamento<\/em>. Insert-Undo consente di annullare gli inserimenti non ancora confermati. L\u2019Undo dell\u2019aggiornamento conserva le versioni precedenti in caso di modifiche o contrassegni di cancellazione, in modo che gli snapshot continuino a funzionare. InnoDB contrassegna inizialmente le righe cancellate solo come rimosse (Delete-Mark) e ritarda l\u2019effettiva eliminazione fino a quando nessuno snapshot pu\u00f2 pi\u00f9 rilevarle. Questa separazione \u00e8 fondamentale: i rollback richiedono stati precedenti precisi, mentre i lettori coerenti devono trovare una versione che corrisponda logicamente al loro momento di inizio. Per questo motivo, le righe fanno riferimento internamente alla versione precedente e gli indici contengono informazioni aggiuntive, in modo che la funzione \u00abPurge\u00bb possa successivamente aggiornare correttamente le voci dell\u2019indice.<\/p>\n\n<h2>Elenco cronologico, eliminazione e memoria<\/h2>\n\n<p>Dopo ogni commit, le modifiche storiche vengono salvate nel file globale <strong>Storia<\/strong> Lista che il thread di purga smantella in modo asincrono. Se la purga non riesce a stare al passo, questa lista cresce e mantiene artificialmente attive le vecchie versioni delle righe. Ci\u00f2 comporta un maggior numero di operazioni di lettura, un aumento dell\u2019I\/O e table space di undo pi\u00f9 grandi. In tali situazioni controllo sempre i livelli di isolamento e gli snapshot aperti, poich\u00e9 una configurazione sfavorevole <a href=\"https:\/\/webhosting.de\/it\/mysql-livello-di-isolamento-hosting-server-coerenza-transazioni\/\">Scelta dell'isolamento<\/a> aumenta la durata di vita delle versioni precedenti. Chi considera nel loro insieme la velocit\u00e0 di purga, la lunghezza della cronologia e le transazioni attive, individua tempestivamente i colli di bottiglia e frena la deriva della memoria prima che diventi critica.<\/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_undo_logs_meeting_2387.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Meccanismo di spurgo e opzioni di messa a punto<\/h2>\n\n<p>Purge \u00e8 in esecuzione <em>al meglio delle possibilit\u00e0<\/em>: Raccoglie le voci eliminabili dalla History List, rimuove definitivamente i contrassegni di cancellazione, aggiorna gli indici secondari e libera le aree di annullamento. Nei sistemi con un\u2019elevata frequenza di modifiche, scalare la <strong>Parallelismo<\/strong> (ad esempio tramite pi\u00f9 worker di purge) e regola la strategia di elaborazione in batch in modo che Purge funzioni in modo costante, ma non troppo intensivo. Regole generali:<\/p>\n<ul>\n  <li>Lotti brevi e costanti anzich\u00e9 cicli sporadici di grandi dimensioni: ci\u00f2 ottimizza le operazioni di I\/O e i checkpoint.<\/li>\n  <li>Non contrapporre la funzione \"Purge\" alla memoria o allo svuotamento dei log: entrambi i metodi devono essere all'altezza.<\/li>\n  <li>Risolvo prima gli snapshot lunghi, prima di aumentare ulteriormente le dimensioni dei batch \u2013 altrimenti l\u2019effetto va perso.<\/li>\n<\/ul>\n<p>Importante: Purge non sostituisce una buona disciplina transazionale. Anche con un elevato livello di parallelismo, Undo rimane vincolato fintanto che esistono snapshot precedenti. Pertanto, monitoro contemporaneamente lo stato di avanzamento di Purge e l\u2019et\u00e0 delle transazioni e correggo il carico di lavoro qualora Purge rimanga costantemente in ritardo.<\/p>\n\n<h2>Configurazione degli tablespace Undo<\/h2>\n\n<p>A seconda della configurazione, le informazioni di \"Undo\" possono essere memorizzate nel tablespace di sistema o in file separati <strong>Annulla<\/strong>-tablespace. Preferisco isolare l\u2019Undo per controllare meglio la crescita e l\u2019I\/O. Molte installazioni consentono una crescita dinamica, in alcuni casi includendo il recupero di spazio tramite Truncate. Sembra una soluzione comoda, ma aumenta la necessit\u00e0 di monitoraggio, poich\u00e9 gli snapshot di lunga durata impediscono una rapida riduzione delle dimensioni. Scelgo la posizione di archiviazione, la dimensione e la parallelit\u00e0 della purga in modo tale che i tassi di modifica e le finestre temporali nell\u2019attivit\u00e0 quotidiana vengano gestiti in modo ottimale e <strong>Restauro<\/strong> non soffra.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Impostazione<\/th>\n      <th>Effetto<\/th>\n      <th>Suggerimento<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>innodb_undo_directory<\/td>\n      <td>Percorso di salvataggio per <strong>Annulla<\/strong>-file<\/td>\n      <td>I supporti dati separati disaccoppiano le operazioni di I\/O<\/td>\n    <\/tr>\n    <tr>\n      <td>innodb_purge_threads<\/td>\n      <td>Altro <strong>Epurazione<\/strong>-Operai nel settore minerario<\/td>\n      <td>Aumentare in caso di elevato tasso di variazione<\/td>\n    <\/tr>\n    <tr>\n      <td>innodb_undo_log_truncate<\/td>\n      <td>Recupera lo spazio inutilizzato<\/td>\n      <td>\u00c8 efficace solo se la cronologia \u00e8 libera<\/td>\n    <\/tr>\n    <tr>\n      <td>innodb_max_undo_log_size<\/td>\n      <td>Limite massimo di crescita<\/td>\n      <td>Disponibilit\u00e0 a seconda della versione<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Struttura della memoria e aspetti relativi al file system<\/h2>\n\n<p>Preferisco collocare gli spazi tabella Undo separati su SSD veloci, distinti dagli I\/O dei dati e dei log. Se il filesystem supporta TRIM\/Discard, un comando Truncate pu\u00f2 restituire fisicamente lo spazio di memoria al sistema operativo. Prevedo comunque limiti massimi prudenziali, poich\u00e9 la liberazione dello spazio non \u00e8 garantita fintanto che gli snapshot vincolano l\u2019Undo. Anche la compressione a livello di filesystem \u00e8 utile solo se c\u2019\u00e8 margine di CPU disponibile e i modelli di scrittura non causano frammentazione. Rimane importante monitorare i picchi di latenza: se l\u2019Undo cresce su un disco a pieno carico, l\u2019amplificazione di scrittura e la pressione dei checkpoint si aggravano progressivamente.<\/p>\n\n<h2>Monitoraggio e diagnosi<\/h2>\n\n<p>Controllo regolarmente le dimensioni del <strong>Annulla<\/strong>-I tablespace, la lunghezza della lista della cronologia e l'et\u00e0 delle transazioni aperte. I comandi SHOW ENGINE InnoDB STATUS, Performance Schema e Information Schema forniscono indicazioni chiare. Se le aree Undo crescono mentre l'operazione di purge ha scarso effetto, per prima cosa chiudo le sessioni pi\u00f9 vecchie. Inoltre, controllo i blocchi, poich\u00e9 quelli non necessari <a href=\"https:\/\/webhosting.de\/it\/blocco-delle-righe-del-database-mysql-concorrenza-ottimizzazione-prestazioni-blocchi\/\">Blocchi per remi<\/a> prolungano le transazioni e gli snapshot. Chi controlla quotidianamente questi indicatori previene picchi improvvisi di I\/O e riduce i percorsi nel <strong>Memoria<\/strong>.<\/p>\n\n<h2>Conseguenze sulle prestazioni delle transazioni di lunga durata<\/h2>\n\n<p>Transazioni di lettura o scrittura di lunga durata <strong>Versioni<\/strong> fissati, anche se logicamente obsoleti. Questo appesantisce la funzione Undo, allunga le scansioni e aumenta la pressione sulla cache. Riduco tali effetti utilizzando batch pi\u00f9 brevi, eseguendo COMMIT in modo sistematico e impostando timeout per le sessioni. I report che richiedono ore di lettura funzionano meglio in finestre pi\u00f9 piccole o su repliche. Chi disattiva l\u2019autocommit, ottimizza i piani di query e chiude le transazioni inattive, alleggerisce il carico su Purge e sgrava il <strong>Istanza<\/strong>.<\/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-undo-logs-insight-4723.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Segmenti di rollback e parallelismo<\/h2>\n\n<p>Le voci \"Annulla\" si trovano in <em>Segmenti di rollback<\/em>, che fungono, per cos\u00ec dire, da slot per le modifiche attive contemporaneamente. Molti writer simultanei traggono vantaggio da un numero sufficiente di segmenti di rollback, poich\u00e9 in tal modo gli inserimenti e gli aggiornamenti devono condividere meno spesso le loro catene di annullamento. Osservo i modelli di attesa sulle risorse di rollback e ne aumento il numero laddove la versione e la distribuzione lo consentono. I sintomi di una mancanza di parallelismo sono tempi di attesa inaspettati in fasi di aggiornamento altrimenti brevi o latenze di scrittura fortemente variabili sotto carico. Un numero maggiore di segmenti distribuisce la pressione, ma non annulla la regola fondamentale: gli snapshot lunghi sono pi\u00f9 efficaci di qualsiasi ottimizzazione.<\/p>\n\n<h2>I livelli di isolamento in dettaglio<\/h2>\n\n<p>Il sito <a href=\"https:\/\/webhosting.de\/it\/mysql-livello-di-isolamento-hosting-server-coerenza-transazioni\/\">Livello di isolamento<\/a> determina per quanto tempo le versioni \"Undo\" siano rilevanti. In modalit\u00e0 REPEATABLE READ, una transazione mantiene il proprio snapshot iniziale per tutta la sua durata; l\u2019Undo rimane quindi potenzialmente vincolato per un periodo molto lungo. In modalit\u00e0 READ COMMITTED, vengono create finestre di visualizzazione per ogni istruzione; ci\u00f2 riduce notevolmente la durata delle vecchie versioni in molti carichi di lavoro. SELECT \u2026 FOR UPDATE e LOCK IN SHARE MODE applicano blocchi e modificano il profilo di concorrenza \u2013 utili contro i Lost Updates, ma critici per l\u2019Undo se i lettori rimangono aperti troppo a lungo. Utilizzo quindi READ COMMITTED in modo mirato laddove i report o le letture API richiedono viste coerenti ma non a livello di transazione, e mantengo REPEATABLE READ quando la logica di business lo richiede.<\/p>\n\n<h2>Scenari di ripristino e avvio<\/h2>\n\n<p>All'avvio, InnoDB utilizza il <strong>Annulla<\/strong>-Informazioni necessarie per ripristinare correttamente le transazioni incomplete. Ci\u00f2 garantisce la coerenza delle viste prima che i nuovi client entrino in funzione. In casi particolari esistono modalit\u00e0 di avvio che abbreviano i controlli, ma le utilizzo solo in caso di emergenza. La pura accelerazione senza diagnosi si ritorce contro, perch\u00e9 l\u2019integrit\u00e0 ha la priorit\u00e0. Chi tiene d\u2019occhio i tempi di ripristino e le dimensioni degli undo, prende decisioni migliori riguardo alle finestre di manutenzione e <strong>Il rischio<\/strong>.<\/p>\n\n<h2>Linee guida pratiche per l'amministrazione<\/h2>\n\n<p>Cerco di mantenere brevi le transazioni, eseguo il commit frequentemente ed evito sessioni di lettura infinite, in modo che <strong>Epurazione<\/strong> ha via libera. Suddivido le modifiche di grandi dimensioni in batch ben dosati, in modo che la History List non aumenti. Adatto i thread di purge in base al tasso di modifica e adeguo il layout di Undo all\u2019hardware di memoria. Inoltre, documento i processi aziendali che richiedono snapshot di lunga durata e pianifico consapevolmente le finestre temporali. In questo modo, l\u2019utilizzo dell\u2019Undo rimane prevedibile e la <strong>Latenza<\/strong> basso.<\/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\/mdb_undologs_tech_office_3821.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Modelli di carico di lavoro e ottimizzazione<\/h2>\n\n<p>L'e-commerce, i sistemi di reporting e quelli di gestione dei contenuti comportano numerosi cambiamenti e richiedono un approccio disciplinato <strong>Transazioni<\/strong>. Impostiamo timeout prudenziali per i lettori, ottimizziamo gli indici per aggiornamenti precisi e limitiamo le dimensioni dei batch. In caso di elevato carico di scrittura, aumentiamo il parallelismo della purga e regoliamo la frequenza dei checkpoint. Inoltre, verifichiamo la velocit\u00e0 di scrittura in relazione a <a href=\"https:\/\/webhosting.de\/it\/registri-delle-transazioni-del-database-processi-di-recupero-protezione-del-database-sicuro\/\">Log delle transazioni e ripristino<\/a>, affinch\u00e9 il ripristino in caso di crash rimanga prevedibile. Questa interazione rende pianificabile il volume delle operazioni di annullamento e protegge il <strong>Coerenza<\/strong>.<\/p>\n\n<h2>Backup e replica<\/h2>\n\n<p>I backup logici con snapshot coerente prolungano inevitabilmente la durata delle vecchie versioni: l\u2019Undo cresce fino al completamento del backup. Pianifico tali operazioni al di fuori delle finestre di picco, limito il numero di writer simultanei e metto a disposizione una capacit\u00e0 di purge sufficiente. I backup fisici possono ridurre il carico dell\u2019Undo, ma non esonerano dall\u2019attenzione necessaria nelle operazioni di snapshot. Sulle repliche, preferisco mantenere i report in modalit\u00e0 READ COMMITTED e chiudo le transazioni inattive di lunga durata, in modo che SQL-Apply non rimanga indietro. Se una replica rimane in ritardo, anche l\u00ec aumenta il carico di undo, poich\u00e9 il recupero di numerose operazioni di cancellazione\/aggiornamento produce un\u2019ondata di cronologia che la funzione di purge deve prima elaborare.<\/p>\n\n<h2>Runbook: Fermare rapidamente la crescita di Undo<\/h2>\n\n<ul>\n  <li>Identificare gli utenti attivi: verificare la durata delle transazioni aperte e le sessioni con insiemi di risultati di grandi dimensioni.<\/li>\n  <li>Terminare in modo sistematico le transazioni inattive: verificare l\u2019autocommit, chiudere i cursori dimenticati.<\/li>\n  <li>Aumentare la capacit\u00e0 di purge: attivare worker aggiuntivi e aumentare moderatamente le dimensioni dei batch.<\/li>\n  <li>Ottimizzazione di Writer: limitare le dimensioni dei batch, introdurre i micro-commit.<\/li>\n  <li>Sfruttare le finestre di manutenzione: spostare le grandi ondate di cancellazioni\/aggiornamenti in fasce orarie pianificabili.<\/li>\n  <li>Dopo la stabilizzazione: consentire l'uso di \"Undo-Truncate\" fino a quando la dimensione del filesystem non sar\u00e0 nuovamente adeguata alle esigenze.<\/li>\n<\/ul>\n\n<h2>Pianificazione della capacit\u00e0 per Undo<\/h2>\n\n<p>Calcolo l'Undo in modo conservativo sulla base del tasso di modifica, della dimensione media delle righe e della finestra massima dello snapshot. Una semplice approssimazione: eventi di modifica al secondo \u00d7 payload medio \u00d7 finestra prevista in secondi. Includere un margine di sicurezza per indici e metadati. Questa regola empirica permette di farsi un\u2019idea delle esigenze nel caso peggiore e protegge da sorprese in caso di operazioni di reporting, backup o migrazioni <em>allo stesso tempo<\/em> Integrare gli snapshot. Nei sistemi in espansione, verifico ogni trimestre se i cambiamenti nel carico di lavoro (nuove funzionalit\u00e0, un numero maggiore di client mobili, picchi pi\u00f9 intensi) modificano le esigenze.<\/p>\n\n<h2>Casi particolari: tabelle temporanee e DDL<\/h2>\n\n<p>Le tabelle InnoDB temporanee utilizzano aree dedicate; le modifiche apportate a queste tabelle gravano meno sull\u2019Undo regolare, ma possono comunque generare un elevato carico di I\/O in caso di ordinamenti o join di grandi dimensioni. Le operazioni DDL come ALTER TABLE generano spesso ondate massicce di modifiche: se necessario, le suddivido in passaggi incrementali e le pianifico in fasi di traffico ridotto. Anche in questo caso vale la regola: transazioni brevi e pulite sono preferibili a scorciatoie rischiose. Se un'esecuzione DDL viene interrotta, l'Undo aiuta a tornare a uno stato coerente; ci\u00f2 richiede tuttavia memoria e tempo sufficienti, che pianifico in anticipo.<\/p>\n\n<h2>Esempio: misurare gli effetti<\/h2>\n\n<p>Comincio con un\u2019istantanea di riferimento della dimensione dell\u2019Undo, che <strong>Storia<\/strong>-lunghezza e durata media delle transazioni. Successivamente apporto modifiche mirate, come ad esempio aumentare il numero di thread di purge o ridurre le dimensioni dei batch. Successivamente, confronto i parametri chiave fino a quando la crescita degli Undo e le latenze non raggiungono un rapporto equilibrato. Se riscontro valori anomali, esamino i piani di query e gli elenchi delle sessioni per identificare i lettori in stallo. Questo processo ciclico garantisce risultati rapidi senza compromettere la <strong>Disponibilit\u00e0<\/strong> mettere a repentaglio.<\/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_undo_logs_9876.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Idee sbagliate comuni<\/h2>\n\n<p>Un commit non cancella immediatamente le versioni precedenti; <strong>Epurazione<\/strong> decider\u00e0 solo in un secondo momento. Le opzioni TRUNCATE non risolvono un problema di progettazione di fondo quando le transazioni durano troppo a lungo. File \u00abUndo\u00bb di grandi dimensioni non implicano necessariamente un danneggiamento dei dati; spesso \u00e8 una singola sessione a causare il blocco. Sebbene i lettori blocchino raramente gli scrittori, le query inadeguate prolungano indirettamente la durata degli snapshot. Chi elimina questi errori prende decisioni migliori e riduce <strong>Tempi di inattivit\u00e0<\/strong>.<\/p>\n\n<h2>Riassunto per chi ha fretta<\/h2>\n\n<p>Mantenere i registri di annullamento <strong>Passato<\/strong> tangibile, affinch\u00e9 InnoDB annulli le transazioni in modo sicuro e i lettori vedano viste costanti. Controllo la crescita ottimizzando le transazioni, impostando correttamente i thread di purga e posizionando in modo oculato gli spazi tabella Undo. Il monitoraggio della lunghezza della cronologia, delle dimensioni degli undo e dell\u2019et\u00e0 delle transazioni evidenzia tempestivamente le tendenze. In caso di anomalie, verifico il carico di lavoro, i blocchi e le sessioni, anzich\u00e9 intervenire solo sui sintomi. Chi segue questa routine mantiene prestazioni, coerenza e <strong>riavvio<\/strong> sotto controllo in modo affidabile.<\/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-undo-logs-4982.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>","protected":false},"excerpt":{"rendered":"<p>Spiegazione dei log di undo di MariaDB: meccanismi interni di InnoDB, rollback, MVCC e consigli amministrativi per migliorare le prestazioni e la stabilit\u00e0.<\/p>","protected":false},"author":1,"featured_media":21112,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-21119","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":"143","_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 Undo","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":"21112","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/21119","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/comments?post=21119"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/21119\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media\/21112"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media?parent=21119"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/categories?post=21119"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/tags?post=21119"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}