{"id":13725,"date":"2025-12-20T10:22:01","date_gmt":"2025-12-20T04:52:01","guid":{"rendered":"https:\/\/www.youstable.com\/blog\/?p=13725"},"modified":"2026-09-07T11:08:51","modified_gmt":"2026-09-07T05:38:51","slug":"how-to-optimize-mysql-on-linux-server","status":"publish","type":"post","link":"https:\/\/www.youstable.com\/blog\/how-to-optimize-mysql-on-linux-server\/","title":{"rendered":"How to Optimize MySQL on Linux Server &#8211; Complete Guide"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\"><strong>To optimize MySQL on a Linux server<\/strong>, start by benchmarking your current performance, tune core InnoDB and connection settings in my.cnf based on RAM and workload, enable the slow query log, fix inefficient queries and indexes, and optimize Linux I\/O and kernel parameters. Monitor continuously and iterate safely in a staging environment.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Optimizing MySQL on Linux server environments is a blend of correct configuration, efficient queries, and smart operating system tuning. In this guide, I\u2019ll show you how to optimize MySQL on Linux server step-by-step using practical settings, tooling, and processes we use in production hosting environments. Whether you run WordPress, SaaS, or custom apps, these steps will help you achieve predictable, stable performance.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"understand-your-stack-and-baseline-performance\"><strong>Understand Your Stack and Baseline Performance<\/strong><\/h2>\n\n\n\n<figure class=\"wp-block-image size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"2848\" height=\"1600\" src=\"https:\/\/www.youstable.com\/blog\/wp-content\/uploads\/2025\/12\/image-80.png\" alt=\"Understand Your Stack and Baseline Performance\" class=\"wp-image-13940\" srcset=\"https:\/\/www.youstable.com\/blog\/wp-content\/uploads\/2025\/12\/image-80.png 2848w, https:\/\/www.youstable.com\/blog\/wp-content\/uploads\/2025\/12\/image-80-150x84.png 150w\" sizes=\"auto, (max-width: 2848px) 100vw, 2848px\" \/><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">Before changing settings, inventory your versions, storage, and traffic patterns. Baseline first so you can verify improvements objectively.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>MySQL variant and version (MySQL 8.x vs MariaDB 10.x)<\/li>\n\n\n\n<li>Workload type (OLTP, analytics, WordPress, ecommerce)<\/li>\n\n\n\n<li>Hardware (CPU cores, RAM, SSD\/NVMe vs HDD, RAID)<\/li>\n\n\n\n<li>Traffic profile (spikes, concurrency, average queries per second)<\/li>\n<\/ul>\n\n\n\n<pre class=\"wp-block-code\"><code># Check versions and quick stats\nmysql --version\nmysql -e \"SELECT VERSION();\"\nmysqladmin status\nmysql -e \"SHOW GLOBAL STATUS LIKE 'Threads_connected';\"\nmysql -e \"SHOW VARIABLES LIKE 'innodb_version';\"<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Establish a baseline: time your top endpoints, measure queries per second, average latency, and CPU\/I\/O utilization under realistic load. Tools like sysbench, ApacheBench (ab), or wrk can simulate load. Always repeat the same test after each change.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"tune-core-mysql-configuration-my-cnf\"><strong>Tune Core MySQL Configuration (my.cnf)<\/strong><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Most gains come from right-sizing InnoDB and connection settings. Use formulas as a starting point, then refine by observing performance and memory use.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># \/etc\/mysql\/my.cnf or \/etc\/my.cnf (adjust path by distro)\n&#91;mysqld]\n# GENERAL\nuser = mysql\npid-file = \/var\/run\/mysqld\/mysqld.pid\nsocket   = \/var\/run\/mysqld\/mysqld.sock\ndatadir  = \/var\/lib\/mysql\nskip_name_resolve = 1\nsymbolic-links = 0\n\n# INNODB (primary storage engine)\ninnodb_buffer_pool_size = 70%_OF_RAM      # e.g., 14G on a 20G DB server\ninnodb_buffer_pool_instances = 4          # 1 per 4G pool (cap at CPU cores)\ninnodb_flush_method = O_DIRECT\ninnodb_flush_log_at_trx_commit = 1        # 1=safe, 2=semi, 0=fastest (risk)\ninnodb_log_file_size = 1G                 # 1\u20134G depending on write volume\ninnodb_log_files_in_group = 2\ninnodb_file_per_table = 1\ninnodb_io_capacity = 1000                 # match your SSD\/NVMe capability\ninnodb_io_capacity_max = 2000\n\n# CONNECTIONS &amp; THREADS\nmax_connections = 200                     # size for real concurrency, not peaks\nthread_cache_size = 50\n\n# QUERY TEMP SPACE\ntmp_table_size = 256M\nmax_heap_table_size = 256M\n\n# PER-THREAD BUFFERS (be conservative!)\nsort_buffer_size = 4M\njoin_buffer_size = 4M\nread_buffer_size = 2M\nread_rnd_buffer_size = 4M\n\n# TABLE &amp; OPEN FILES\ntable_open_cache = 4000\nopen_files_limit = 65535\n\n# BINARY LOGGING (for replication\/point-in-time recovery)\n# enable binlog only if you need it; otherwise it adds overhead\nserver_id = 1\nlog_bin = mysql-bin\nbinlog_format = ROW\nsync_binlog = 1\n\n# LOGGING &amp; DIAGNOSTICS\nslow_query_log = 1\nslow_query_log_file = \/var\/log\/mysql\/slow.log\nlong_query_time = 1\nlog_slow_admin_statements = 1\nlog_slow_replica_statements = 1\nperformance_schema = ON<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Notes:<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>innodb_buffer_pool_size: Aim for 60\u201375% of RAM on a dedicated DB server. For shared servers, start lower.<\/li>\n\n\n\n<li>Per-thread buffers multiply by concurrent threads. Don\u2019t oversize them; it risks swapping.<\/li>\n\n\n\n<li>innodb_flush_log_at_trx_commit and sync_binlog control durability vs speed. Use 1\/1 for full safety; 2\/1 or 2\/0 can reduce fsync overhead at some risk.<\/li>\n\n\n\n<li>Query Cache is removed in MySQL 8; don\u2019t try to enable it. On MariaDB, keep it disabled for busy OLTP workloads.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"enable-instrumentation-and-find-slow-queries\"><strong>Enable Instrumentation and Find Slow Queries<\/strong><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Configuration alone won\u2019t fix inefficient SQL. Turn on the slow query log and analyze it regularly.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Enable slow log (if not already)\nSET GLOBAL slow_query_log = ON;\nSET GLOBAL long_query_time = 1;\nSET GLOBAL log_queries_not_using_indexes = OFF;\n\n# Summarize slow log\nmysqldumpslow \/var\/log\/mysql\/slow.log | head\n\n# Deep analysis (Percona toolkit)\napt-get install percona-toolkit -y  # or use your distro method\npt-query-digest \/var\/log\/mysql\/slow.log | less<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Focus on the top 5\u201310 queries by total time. Many systems get dramatic wins by fixing a few N+1 queries or adding the right composite indexes.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"optimize-queries-and-indexes\"><strong>Optimize Queries and Indexes<\/strong><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Use EXPLAIN to understand query plans and enforce index usage through better schema design, not hints.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>EXPLAIN ANALYZE\nSELECT o.id, o.total\nFROM orders o\nJOIN customers c ON c.id = o.customer_id\nWHERE c.country = 'US' AND o.created_at &gt;= '2025-01-01'\nORDER BY o.created_at DESC\nLIMIT 50;<\/code><\/pre>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Create selective indexes used by WHERE, JOIN, and ORDER BY. For the example above: INDEX(customer_id, created_at) or a composite on (country) in the customers table if it filters strongly.<\/li>\n\n\n\n<li>Avoid SELECT *; fetch only fields you need.<\/li>\n\n\n\n<li>Prefer covering indexes for hot queries to reduce random I\/O.<\/li>\n\n\n\n<li>Use appropriate data types (INT vs BIGINT, VARCHARS sized appropriately, TIMESTAMP vs DATETIME).<\/li>\n\n\n\n<li>Eliminate functions on indexed columns in WHERE clauses (e.g., avoid DATE(created_at) = &#8230;; use ranges instead).<\/li>\n\n\n\n<li>Rewrite subqueries to joins and add proper indexes when needed.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"manage-concurrency-and-connections\"><strong>Manage Concurrency and Connections<\/strong><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Setting max_connections too high can trigger memory pressure and stalls. Aim to match real concurrency, not short spikes. Use connection pooling in your app (e.g., ProxySQL, pgbouncer-like behavior for MySQL via pools in ORM\/drivers) to reuse connections efficiently.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Monitor Threads_connected and Threads_running; the latter reflects active work.<\/li>\n\n\n\n<li>Use thread_cache_size to reduce thread creation overhead.<\/li>\n\n\n\n<li>Size per-thread buffers conservatively to prevent swapping under load.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"disk-and-filesystem-tuning-on-linux\"><strong>Disk and Filesystem Tuning on Linux<\/strong><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">MySQL performance is often I\/O-bound. Give InnoDB fast, predictable disk behavior and configure it to avoid double buffering.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use SSD or NVMe for data, logs, and tmpdir wherever possible.<\/li>\n\n\n\n<li>Mount options: noatime,nodiratime; use XFS or ext4 with stable defaults.<\/li>\n\n\n\n<li>Place InnoDB redo logs and data on the same fast volume; avoid slow network storage.<\/li>\n\n\n\n<li>innodb_flush_method=O_DIRECT helps prevent double buffering (cache duplication).<\/li>\n\n\n\n<li>Right-size innodb_log_file_size (1\u20134G) to balance checkpointing and crash recovery time.<\/li>\n<\/ul>\n\n\n\n<pre class=\"wp-block-code\"><code># Check and set I\/O scheduler (prefer 'none' for NVMe, 'mq-deadline' for SATA SSD)\ncat \/sys\/block\/nvme0n1\/queue\/scheduler\necho none &gt; \/sys\/block\/nvme0n1\/queue\/scheduler\n\n# Ensure tmpdir is on fast storage\nmysql -e \"SHOW VARIABLES LIKE 'tmpdir';\"\n# Optionally set in my.cnf:\n# tmpdir = \/mnt\/fast-ssd\/mysqltmp<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"linux-kernel-and-os-level-settings\"><strong>Linux Kernel and OS-Level Settings<\/strong><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Tune the OS to keep memory and I\/O stable for MySQL.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Disable Transparent Huge Pages (THP) to reduce latency spikes.<\/li>\n\n\n\n<li>Set vm.swappiness low (e.g., 1\u201310) to avoid swapping under pressure.<\/li>\n\n\n\n<li><a href=\"https:\/\/www.youstable.com\/blog\/how-to-increase-file-upload-size-in-directadmin-2\/\">Increase file<\/a> descriptors and process limits for the mysql user.<\/li>\n\n\n\n<li>Enable NUMA interleaving if on multi-socket servers, or bind MySQL to a single NUMA node.<\/li>\n<\/ul>\n\n\n\n<pre class=\"wp-block-code\"><code># Disable THP (persist via systemd scripts if needed)\necho never &gt; \/sys\/kernel\/mm\/transparent_hugepage\/enabled\necho never &gt; \/sys\/kernel\/mm\/transparent_hugepage\/defrag\n\n# Tune swappiness\nsysctl -w vm.swappiness=1\necho \"vm.swappiness=1\" &gt;&gt; \/etc\/sysctl.conf\n\n# Raise open files for MySQL\necho \"mysql soft nofile 65535\" &gt;&gt; \/etc\/security\/limits.conf\necho \"mysql hard nofile 65535\" &gt;&gt; \/etc\/security\/limits.conf<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"backup-safety-and-durability-trade-offs\"><strong>Backup, Safety, and Durability Trade-offs<\/strong><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Performance shouldn\u2019t compromise data safety. If you relax durability, ensure you have backups and redundancy.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use 1\/1 for innodb_flush_log_at_trx_commit and sync_binlog in financial\/critical systems.<\/li>\n\n\n\n<li>If using 2 or 0 for speed, implement frequent backups and possibly semi-sync replication to reduce risk.<\/li>\n\n\n\n<li>Test restore time. Use physical backups (Percona XtraBackup) for large datasets; mysqldump for small setups.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"continuous-monitoring-and-health-checks\"><strong>Continuous Monitoring and Health Checks<\/strong><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Optimization is ongoing. Add observability and automate checks to catch regressions early.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Performance Schema and sys schema for built-in metrics.<\/li>\n\n\n\n<li>MySQLTuner for periodic configuration suggestions (treat as hints, not gospel).<\/li>\n\n\n\n<li>Exporters for Prometheus\/Grafana to visualize QPS, latency, buffer pool hit ratio, and I\/O.<\/li>\n\n\n\n<li>Alert on Threads_running spikes, replication lag, disk saturation, and deadlocks.<\/li>\n<\/ul>\n\n\n\n<pre class=\"wp-block-code\"><code># Install MySQLTuner (example)\nwget https:\/\/raw.githubusercontent.com\/major\/MySQLTuner-perl\/master\/mysqltuner.pl -O \/usr\/local\/bin\/mysqltuner\nchmod +x \/usr\/local\/bin\/mysqltuner\nmysqltuner<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"common-pitfalls-to-avoid\"><strong>Common Pitfalls to Avoid<\/strong><\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Oversizing per-thread buffers leading to swap storms.<\/li>\n\n\n\n<li>Setting max_connections in the thousands without pooling.<\/li>\n\n\n\n<li>Ignoring slow log and trying to solve app problems with hardware only.<\/li>\n\n\n\n<li>Leaving binary logging on without need (overhead) or turning it off when you need PITR.<\/li>\n\n\n\n<li>Not testing changes in staging before production rollout.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"when-to-scale-up-or-out\"><strong>When to Scale Up or Out<\/strong><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">If tuning and query optimization are exhausted, consider scaling strategies:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Scale up: More RAM (bigger buffer pool), faster NVMe, and more CPU.<\/li>\n\n\n\n<li>Scale out: Read replicas for read-heavy workloads; sharding or partitioning for large datasets.<\/li>\n\n\n\n<li>Introduce a caching layer (Redis) to offload hot reads.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"real-world-example-wordpress-on-mysql\"><strong>Real-World Example: WordPress on MySQL<\/strong><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">For a busy <a href=\"https:\/\/www.youstable.com\/blog\/convert-a-wordpress-site-to-a-static-html-website\/\">WordPress site:<\/a><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Set innodb_buffer_pool_size to fit the working set (posts, postmeta, options, wp_ tables).<\/li>\n\n\n\n<li>Add the right composite indexes on wp_postmeta (meta_key, post_id) and wp_posts (post_type, post_status, post_date).<\/li>\n\n\n\n<li>Use object caching (Redis) to reduce DB hits.<\/li>\n\n\n\n<li>Enable <a href=\"https:\/\/www.youstable.com\/blog\/fix-slow-wordpress-site\/\">slow query log and fix<\/a> heavy admin and plugin queries first.<\/li>\n\n\n\n<li>Use PHP-FPM pools and connection pooling to keep DB connections sane.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"step-by-step-quick-checklist\"><strong>Step-by-Step Quick Checklist<\/strong><\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Baseline: measure QPS, latency, CPU, I\/O, buffer pool hit ratio.<\/li>\n\n\n\n<li>Right-size InnoDB (buffer pool, log files, flush method).<\/li>\n\n\n\n<li>Control connections and per-thread memory safely.<\/li>\n\n\n\n<li>Enable slow log; analyze with pt-query-digest.<\/li>\n\n\n\n<li>Add\/adjust indexes and rewrite slow queries.<\/li>\n\n\n\n<li>Optimize disk (NVMe, scheduler) and OS (THP off, low swappiness).<\/li>\n\n\n\n<li>Set up backups, replication if needed, and monitoring dashboards.<\/li>\n\n\n\n<li>Iterate changes in staging; deploy gradually.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">By following these steps, measuring, tuning my.cnf thoughtfully, optimizing queries, and aligning Linux with MySQL\u2019s I\/O patterns\u2014you can achieve significant, sustainable gains. If you want done-for-you optimization on reliable infrastructure, YouStable\u2019s managed solutions can help you scale confidently.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"faqs-how-to-optimize-mysql-on-linux-server\"><strong>FAQs: How to Optimize MySQL on Linux Server<\/strong><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Below are the most asked questions about MySQL performance tuning on Linux and concise answers you can apply today.<\/p>\n\n\n<div id=\"rank-math-faq\" class=\"rank-math-block\">\n<div class=\"rank-math-list \">\n<div id=\"faq-question-1765866960146\" class=\"rank-math-list-item\">\n<h3 class=\"rank-math-question \" class=\"rank-math-question \" id=\"u003cstrongu003ewhat-is-the-ideal-innodb_buffer_pool_sizeu003c-strongu003e\">u003cstrongu003eWhat is the ideal innodb_buffer_pool_size?u003c\/strongu003e<\/h3>\n<div class=\"rank-math-answer \">\n\n<p>On a dedicated MySQL server, start with 60\u201375% of RAM. If MySQL shares the host, reduce to leave memory for the OS and other services. Validate by watching the buffer pool hit ratio, page reads, and overall memory pressure; adjust upward only if you\u2019re not swapping.<\/p>\n\n<\/div>\n<\/div>\n<div id=\"faq-question-1765866969406\" class=\"rank-math-list-item\">\n<h3 class=\"rank-math-question \" class=\"rank-math-question \" id=\"u003cstrongu003ehow-do-i-find-and-fix-slow-queriesu003c-strongu003e\">u003cstrongu003eHow do I find and fix slow queries?u003c\/strongu003e<\/h3>\n<div class=\"rank-math-answer \">\n\n<p>Enable the slow query log (long_query_time=1), then use pt-query-digest to identify top offenders. For each query, run EXPLAIN, add appropriate indexes, limit result sets, and avoid functions on indexed columns. Re-test after each change to confirm improvement.<\/p>\n\n<\/div>\n<\/div>\n<div id=\"faq-question-1765866976614\" class=\"rank-math-list-item\">\n<h3 class=\"rank-math-question \" class=\"rank-math-question \" id=\"u003cstrongu003eshould-i-enable-the-mysql-query-cacheu003c-strongu003e\">u003cstrongu003eShould I enable the MySQL Query Cache?u003c\/strongu003e<\/h3>\n<div class=\"rank-math-answer \">\n\n<p>No for MySQL 8\u2014it\u2019s removed. On MariaDB, the Query Cache can harm concurrency in write-heavy workloads. Prefer application or Redis caching for predictable performance across modern hardware and high-concurrency scenarios.<\/p>\n\n<\/div>\n<\/div>\n<div id=\"faq-question-1765866983454\" class=\"rank-math-list-item\">\n<h3 class=\"rank-math-question \" class=\"rank-math-question \" id=\"u003cstrongu003ehow-many-max_connections-should-i-setu003c-strongu003e\">u003cstrongu003eHow many max_connections should I set?u003c\/strongu003e<\/h3>\n<div class=\"rank-math-answer \">\n\n<p>Size for real concurrent work, usually 100\u2013400 for mid-sized apps. Use pooling to reuse connections. Remember each active connection consumes per-thread memory; oversized values can cause swapping and timeouts.<\/p>\n\n<\/div>\n<\/div>\n<div id=\"faq-question-1765866993320\" class=\"rank-math-list-item\">\n<h3 class=\"rank-math-question \" class=\"rank-math-question \" id=\"u003cstrongu003emysql-vs-mariadb-do-tuning-rules-differu003c-strongu003e\">u003cstrongu003eMySQL vs MariaDB: do tuning rules differ?u003c\/strongu003e<\/h3>\n<div class=\"rank-math-answer \">\n\n<p>Core InnoDB concepts apply to both, but defaults vary (e.g., optimizer behavior, features like Aria, thread pool options). Confirm variable names and defaults in your server\u2019s documentation, and test changes per engine\/version.<\/p>\n\n<\/div>\n<\/div>\n<\/div>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>To optimize MySQL on a Linux server, start by benchmarking your current performance, tune core InnoDB and connection settings in [&hellip;]<\/p>\n","protected":false},"author":13,"featured_media":15472,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"iawp_total_views":61,"footnotes":""},"categories":[350,2261],"tags":[],"class_list":["post-13725","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-knowledgebase","category-kb-databases"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.youstable.com\/blog\/wp-json\/wp\/v2\/posts\/13725","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.youstable.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.youstable.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.youstable.com\/blog\/wp-json\/wp\/v2\/users\/13"}],"replies":[{"embeddable":true,"href":"https:\/\/www.youstable.com\/blog\/wp-json\/wp\/v2\/comments?post=13725"}],"version-history":[{"count":1,"href":"https:\/\/www.youstable.com\/blog\/wp-json\/wp\/v2\/posts\/13725\/revisions"}],"predecessor-version":[{"id":23080,"href":"https:\/\/www.youstable.com\/blog\/wp-json\/wp\/v2\/posts\/13725\/revisions\/23080"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.youstable.com\/blog\/wp-json\/wp\/v2\/media\/15472"}],"wp:attachment":[{"href":"https:\/\/www.youstable.com\/blog\/wp-json\/wp\/v2\/media?parent=13725"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.youstable.com\/blog\/wp-json\/wp\/v2\/categories?post=13725"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.youstable.com\/blog\/wp-json\/wp\/v2\/tags?post=13725"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}