{"id":30913,"date":"2025-12-01T20:46:34","date_gmt":"2025-12-02T04:46:34","guid":{"rendered":"https:\/\/preview-en.pingcap.com\/?page_id=29948"},"modified":"2025-12-08T23:46:55","modified_gmt":"2025-12-09T07:46:55","slug":"playbook-noisy-neighbor-multi-tenant-mysql","status":"publish","type":"page","link":"https:\/\/www.pingcap.com\/ko\/playbook-noisy-neighbor-multi-tenant-mysql\/","title":{"rendered":"Silence the Screams: TiDB\u2019s Noisy-Neighbor Playbook"},"content":{"rendered":"","protected":false},"excerpt":{"rendered":"","protected":false},"author":184,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"templates\/page-pillar-page.php","meta":{"ub_ctt_via":""},"class_list":["post-30913","page","type-page","status-publish","hentry"],"acf":[],"featured_image_src":null,"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v26.9 - https:\/\/yoast.com\/product\/yoast-seo-wordpress\/ -->\n<title>Playbook: Stop Noisy Neighbors - Multi-Tenant MySQL at Scale | TiDB<\/title>\n<meta name=\"description\" content=\"End tenant-induced outages. TiDB\u2019s resource groups, Placement Rules &amp; RBAC isolate noisy neighbors on shared MySQL clusters\u2014cut cost, keep SLAs.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.pingcap.com\/ko\/playbook-noisy-neighbor-multi-tenant-mysql\/\" \/>\n<meta property=\"og:locale\" content=\"ko_KR\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Playbook: Stop Noisy Neighbors - Multi-Tenant MySQL at Scale | TiDB\" \/>\n<meta property=\"og:description\" content=\"End tenant-induced outages. TiDB\u2019s resource groups, Placement Rules &amp; RBAC isolate noisy neighbors on shared MySQL clusters\u2014cut cost, keep SLAs.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.pingcap.com\/ko\/playbook-noisy-neighbor-multi-tenant-mysql\/\" \/>\n<meta property=\"og:site_name\" content=\"TiDB\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/facebook.com\/pingcap2015\" \/>\n<meta property=\"article:modified_time\" content=\"2025-12-09T07:46:55+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/static.pingcap.com\/files\/2025\/12\/08234524\/playbook-multi-tenant.png\" \/>\n\t<meta property=\"og:image:width\" content=\"3600\" \/>\n\t<meta property=\"og:image:height\" content=\"1800\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:image\" content=\"https:\/\/static.pingcap.com\/files\/2025\/12\/08234524\/playbook-multi-tenant.png\" \/>\n<meta name=\"twitter:site\" content=\"@PingCAP\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.pingcap.com\/playbook-noisy-neighbor-multi-tenant-mysql\/\",\"url\":\"https:\/\/www.pingcap.com\/playbook-noisy-neighbor-multi-tenant-mysql\/\",\"name\":\"Playbook: Stop Noisy Neighbors - Multi-Tenant MySQL at Scale | TiDB\",\"isPartOf\":{\"@id\":\"https:\/\/www.pingcap.com\/#website\"},\"datePublished\":\"2025-12-02T04:46:34+00:00\",\"dateModified\":\"2025-12-09T07:46:55+00:00\",\"description\":\"End tenant-induced outages. TiDB\u2019s resource groups, Placement Rules & RBAC isolate noisy neighbors on shared MySQL clusters\u2014cut cost, keep SLAs.\",\"breadcrumb\":{\"@id\":\"https:\/\/www.pingcap.com\/playbook-noisy-neighbor-multi-tenant-mysql\/#breadcrumb\"},\"inLanguage\":\"ko-KR\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.pingcap.com\/playbook-noisy-neighbor-multi-tenant-mysql\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.pingcap.com\/playbook-noisy-neighbor-multi-tenant-mysql\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/www.pingcap.com\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Silence the Screams: TiDB\u2019s Noisy-Neighbor Playbook\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/www.pingcap.com\/#website\",\"url\":\"https:\/\/www.pingcap.com\/\",\"name\":\"TiDB\",\"description\":\"TiDB | SQL at Scale\",\"publisher\":{\"@id\":\"https:\/\/www.pingcap.com\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/www.pingcap.com\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"ko-KR\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/www.pingcap.com\/#organization\",\"name\":\"PingCAP\",\"url\":\"https:\/\/www.pingcap.com\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"ko-KR\",\"@id\":\"https:\/\/www.pingcap.com\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/static.pingcap.com\/files\/2021\/11\/pingcap-logo.png\",\"contentUrl\":\"https:\/\/static.pingcap.com\/files\/2021\/11\/pingcap-logo.png\",\"width\":811,\"height\":232,\"caption\":\"PingCAP\"},\"image\":{\"@id\":\"https:\/\/www.pingcap.com\/#\/schema\/logo\/image\/\"},\"sameAs\":[\"https:\/\/facebook.com\/pingcap2015\",\"https:\/\/x.com\/PingCAP\",\"https:\/\/linkedin.com\/company\/pingcap\",\"https:\/\/youtube.com\/channel\/UCuq4puT32DzHKT5rU1IZpIA\"]}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Playbook: Stop Noisy Neighbors - Multi-Tenant MySQL at Scale | TiDB","description":"End tenant-induced outages. TiDB\u2019s resource groups, Placement Rules & RBAC isolate noisy neighbors on shared MySQL clusters\u2014cut cost, keep SLAs.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.pingcap.com\/ko\/playbook-noisy-neighbor-multi-tenant-mysql\/","og_locale":"ko_KR","og_type":"article","og_title":"Playbook: Stop Noisy Neighbors - Multi-Tenant MySQL at Scale | TiDB","og_description":"End tenant-induced outages. TiDB\u2019s resource groups, Placement Rules & RBAC isolate noisy neighbors on shared MySQL clusters\u2014cut cost, keep SLAs.","og_url":"https:\/\/www.pingcap.com\/ko\/playbook-noisy-neighbor-multi-tenant-mysql\/","og_site_name":"TiDB","article_publisher":"https:\/\/facebook.com\/pingcap2015","article_modified_time":"2025-12-09T07:46:55+00:00","og_image":[{"width":3600,"height":1800,"url":"https:\/\/static.pingcap.com\/files\/2025\/12\/08234524\/playbook-multi-tenant.png","type":"image\/png"}],"twitter_card":"summary_large_image","twitter_image":"https:\/\/static.pingcap.com\/files\/2025\/12\/08234524\/playbook-multi-tenant.png","twitter_site":"@PingCAP","schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/www.pingcap.com\/playbook-noisy-neighbor-multi-tenant-mysql\/","url":"https:\/\/www.pingcap.com\/playbook-noisy-neighbor-multi-tenant-mysql\/","name":"Playbook: Stop Noisy Neighbors - Multi-Tenant MySQL at Scale | TiDB","isPartOf":{"@id":"https:\/\/www.pingcap.com\/#website"},"datePublished":"2025-12-02T04:46:34+00:00","dateModified":"2025-12-09T07:46:55+00:00","description":"End tenant-induced outages. TiDB\u2019s resource groups, Placement Rules & RBAC isolate noisy neighbors on shared MySQL clusters\u2014cut cost, keep SLAs.","breadcrumb":{"@id":"https:\/\/www.pingcap.com\/playbook-noisy-neighbor-multi-tenant-mysql\/#breadcrumb"},"inLanguage":"ko-KR","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.pingcap.com\/playbook-noisy-neighbor-multi-tenant-mysql\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/www.pingcap.com\/playbook-noisy-neighbor-multi-tenant-mysql\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.pingcap.com\/"},{"@type":"ListItem","position":2,"name":"Silence the Screams: TiDB\u2019s Noisy-Neighbor Playbook"}]},{"@type":"WebSite","@id":"https:\/\/www.pingcap.com\/#website","url":"https:\/\/www.pingcap.com\/","name":"\ud2f0DB","description":"TiDB | SQL at Scale","publisher":{"@id":"https:\/\/www.pingcap.com\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.pingcap.com\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"ko-KR"},{"@type":"Organization","@id":"https:\/\/www.pingcap.com\/#organization","name":"PingCAP","url":"https:\/\/www.pingcap.com\/","logo":{"@type":"ImageObject","inLanguage":"ko-KR","@id":"https:\/\/www.pingcap.com\/#\/schema\/logo\/image\/","url":"https:\/\/static.pingcap.com\/files\/2021\/11\/pingcap-logo.png","contentUrl":"https:\/\/static.pingcap.com\/files\/2021\/11\/pingcap-logo.png","width":811,"height":232,"caption":"PingCAP"},"image":{"@id":"https:\/\/www.pingcap.com\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/facebook.com\/pingcap2015","https:\/\/x.com\/PingCAP","https:\/\/linkedin.com\/company\/pingcap","https:\/\/youtube.com\/channel\/UCuq4puT32DzHKT5rU1IZpIA"]}]}},"grav_blocks":[{"acf_fc_layout":"columns","format":"","enable_box_container":false,"column_num":"12","columns":[{"type":"wysiwyg","wysiwyg":"<p>You run a multi-tenant SaaS platform. Most days are quiet. But then one tenant surges and everyone else slows down. Latency SLOs slip, dashboards go red, and your team scrambles with throttles and hot fixes. That\u2019s the noisy-neighbor problem in the database tier: a single burst monopolizes CPU and IO, leaders pile onto a few stores, and well-behaved tenants inherit the wait.<\/p>\n<p style=\"font-weight: 400; margin-bottom: 1.6rem;\">There are two common architectures to tackle this:<\/p>\n<ul>\n<li><strong>Shared-Schema:<\/strong> all tenants share the same tables, and their data is isolated by a <code>tenant_id<\/code> column. This approach typically relies on row-level security (RLS). PostgreSQL is usually the first choice for this design.<\/li>\n<li><strong>Schema\/Database-per-Tenant:<\/strong> each tenant gets its own schema or database. Schema and database scalability are critical for this architecture.<\/li>\n<\/ul>\n<p>This playbook focuses on how to stop that spiral using the schema\/database-per-tenant model with <a href=\"https:\/\/www.pingcap.com\/tidb\/\">TiDB<\/a>: how to detect floods quickly, contain impact without downtime, and harden the system so the next surge is a non-event.<\/p>\n<h2>Who\u2019s This Playbook For: Storage Leads &amp; SREs<\/h2>\n<p><strong>Storage leads<\/strong> own the database platform (i.e., capacity planning, cost, replication\/backup strategy, schema governance, and upgrade cadence) and must keep a multi-tenant <a href=\"https:\/\/www.pingcap.com\/solutions\/modernize-mysql-workloads\/\">MySQL estate<\/a> efficient as it grows.<\/p>\n<p>On the other hand, <strong>Site Reliability Engineers (SREs)<\/strong> own reliability and performance in production, including SLOs\/error budgets, observability, incident response, runbooks, and change management.<\/p>\n<p style=\"font-weight: 400; margin-bottom: 1.6rem;\">Top pains include:<\/p>\n<ul>\n<li>Latency SLO misses that appear \u201cout of nowhere\u201d<\/li>\n<li>Over-provisioning just to survive peak bursts<\/li>\n<li>On-call fatigue from throttle scripts and fire drills<\/li>\n<\/ul>\n<p>TiDB\u2019s <a href=\"https:\/\/www.pingcap.com\/blog\/multi-tenant-architecture-enhancing-database-scalability-tidb\/\">multi-tenant controls<\/a> mute noisy neighbors while cutting costs: enforceable per-tenant budgets, data placement by heat, and least-privilege access without rewrites.<\/p>\n<h2>What We\u2019re Solving Today: The Noisy-Neighbor Spiral<\/h2>\n<p>When one tenant surges, shared database resources concentrate on a few hot leaders and stores. Queues form, p95 and p99 climb, and well-behaved neighbors miss their SLOs. Teams often react with emergency throttles or by carving out per-tenant databases, which removes contention but destroys pooled efficiency and inflates cost.<\/p>\n<h3>Tenant A Floods the Cluster \u2014 SLAs Melt<\/h3>\n<p>A burst of small writes or range scans saturates CPU and IO on a narrow set of regions and leaders. Followers then spend extra time catching up, and background compactions contend with foreground work. Neighbor queries now wait on the same thread pools and the same hot ranges.<\/p>\n<h4>Symptoms to Recognize<\/h4>\n<ul>\n<li>Sudden p95 and p99 jumps for unrelated tenants during one tenant\u2019s event.<\/li>\n<li>Spikes in CPU, write amplification, and scheduler wait while other tenants\u2019 QPS stays flat.<\/li>\n<li>Growing DDL or compaction backlogs that delay otherwise routine work.<\/li>\n<\/ul>\n<h4>Typical Pressure Paths<\/h4>\n<ul>\n<li><strong>CPU saturation:<\/strong> Hot leaders spend cycles on transaction scheduling, Raft messaging, and compactions. Neighbor requests queue behind them.<\/li>\n<li><strong>IO starvation:<\/strong> Write bursts trigger flushes and compactions. Background tasks delay reads for other tenants.<\/li>\n<li><strong>Hotspot amplification:<\/strong> Skewed keys or time-aligned workloads push many requests to a small set of regions. Rebalancing lags the surge.<\/li>\n<\/ul>\n<h3>Hard Isolation = Silo Sprawl &amp; $$$<\/h3>\n<h4>Why Costs Explode<\/h4>\n<ul>\n<li><strong>N\u00d7 fixed overhead:<\/strong> Every tenant needs nodes for HA, backups, and observability. Three nodes per tenant yields 300 nodes at 100 tenants before scaling for load.<\/li>\n<li><strong>Low average utilization:<\/strong> Dedicated capacity sits idle. Unused CPU and IO cannot be shared.<\/li>\n<li><strong>Operational sprawl:<\/strong> Patching, upgrades, schema changes, and backups multiply with tenant count. Every automation must target many clusters.<\/li>\n<\/ul>\n<h4>Functional Trade-Offs<\/h4>\n<ul>\n<li>Cross-tenant features become harder. Shared catalogs, analytics, and global search require fan-out across many databases or a new data pipeline.<\/li>\n<li>Capacity planning fragments. You size for individual peaks instead of pooling headroom. The result is more over-provisioning and slower onboarding.<\/li>\n<\/ul>\n<h3>Fire-Drill Ops &amp; On-Call Burnout<\/h3>\n<h4>What It Feels Like in Practice<\/h4>\n<ul>\n<li>SREs are forced into manual throttling, cgroup tweaks, proxy limit changes, and ad-hoc scripts.<\/li>\n<li>Incidents trigger cross-team blame and executive pressure to \u201cfix it now.\u201d<\/li>\n<li>The node count only moves in one direction. Burnout follows.<\/li>\n<\/ul>\n<h2>DIY Isolation (Without TiDB): More Metal, More Headaches<\/h2>\n<p>When teams face noisy neighbors without TiDB, they usually stitch together \u201cDIY isolation.\u201d It works, until it doesn\u2019t: per-tenant silos, OS\/proxy throttles, app-level fan-out for reporting, and expensive over-provisioning just to survive spikes. In this section, we\u2019ll walk through each of these stopgaps so you can clearly see the trade-offs.<\/p>\n<h3>Carve Siloed Databases for Every Tenant<\/h3>\n<p>Spin up siloed MySQL clusters or Kubernetes namespaces per tenant. Isolation rises. Cost and toil rise faster.<\/p>\n<pre><code># Example anti-pattern: per-tenant clusters that do not share headroom\r\nkubectl create ns tenant-a\r\nhelm install mysql-tenant-a bitnami\/mysql -n tenant-a<\/code><\/pre>\n<h3>Hand-Tune OS, VM, and Proxy Limits<\/h3>\n<p>Hand-tune cgroups, proxies, and throttle scripts to chase traffic spikes.<\/p>\n<pre><code># OS-level CPU cap (illustrative)\r\ncgcreate -g cpu:\/tenantA &amp;&amp; echo 40000 &gt; \/sys\/fs\/cgroup\/cpu\/tenantA\/cpu.cfs_quota_us<\/code><\/pre>\n<h3>Rewrite App Logic for Cross-Tenant Joins<\/h3>\n<p>Cross-tenant reporting and shared catalogs become application code problems.<\/p>\n<pre><code>-- Fan-out reporting pattern that grows with tenant count\r\n-- (multiple connections and unions per tenant database)<\/code><\/pre>\n<h3>Over-Provision or Pray During Spikes<\/h3>\n<p>Provision for worst case. Watch utilization stay low off-peak and bills stay high.<\/p>\n<h2>TiDB\u2019s Multi-Tenant Shield (With TiDB)<\/h2>\n<p>TiDB gives you isolation without silos. In this section, we\u2019ll explore how three native controls turn shared hardware into predictable, per-tenant performance.<\/p>\n<h3>Resource Groups: CPU &amp; IO Budgets per Tenant in Seconds<\/h3>\n<p><a href=\"https:\/\/docs.pingcap.com\/tidb\/stable\/information-schema-resource-groups\/\">Resource Groups<\/a> let TiDB enforce per-tenant compute budgets using Request Units (RUs). You define tiers (e.g., bronze\/silver\/gold), and the scheduler throttles or shapes each tenant\u2019s CPU\/IO so a burst from one tenant won\u2019t degrade others. Budgets are soft-capped (with optional bursting) and can be changed instantly\u2014no app changes required.<\/p>\n<pre><code>CREATE RESOURCE GROUP rg_bronze RU_PER_SEC=3000\u00a0 BURSTABLE;\r\nCREATE RESOURCE GROUP rg_silver RU_PER_SEC=8000\u00a0 BURSTABLE;\r\nCREATE RESOURCE GROUP rg_gold \u00a0 RU_PER_SEC=20000 BURSTABLE;\r\nCREATE USER 'tenantA' IDENTIFIED BY '***';\r\nALTER USER 'tenantA' RESOURCE GROUP 'rg_gold';<\/code><\/pre>\n<h3>Placement Rules: Pin Hot Data, Keep Cold Cheap<\/h3>\n<p><a href=\"https:\/\/docs.pingcap.com\/tidb\/stable\/configure-placement-rules\/\">Placement Rules<\/a> control where data lives and replicates. You can pin hot partitions to low-latency nodes (NVMe\/\u201cfast\u201d zones) and park cold\/archival data on cost-optimized storage\u2014while keeping replica counts and resilience policies intact. This improves tail latency and reduces cost without changing application logic.<\/p>\n<pre><code>CREATE PLACEMENT POLICY p_hot\u00a0 CONSTRAINTS='+zone=fast'\u00a0 FOLLOWERS=2;\r\nCREATE PLACEMENT POLICY p_cold CONSTRAINTS='+zone=cheap' FOLLOWERS=2;\r\n-- Apply at table or partition granularity\r\nALTER TABLE orders PARTITION p0 PLACEMENT POLICY = p_hot; \u00a0 -- hot tenant\r\nALTER TABLE orders PARTITION p1 PLACEMENT POLICY = p_cold;\u00a0 -- archive<\/code><\/pre>\n<h3>Fine-Grained Role-Based Access Control (RBAC): Least Privilege, Zero App Changes<\/h3>\n<p><a href=\"https:\/\/docs.pingcap.com\/tidb\/stable\/role-based-access-control\/\">Role-Based Access Control<\/a> in TiDB lets you enforce per-tenant and per-object permissions at the database layer without touching application code.<\/p>\n<pre><code>CREATE ROLE r_tenantA;\r\nGRANT SELECT,INSERT,UPDATE,DELETE ON orders TO r_tenantA;\r\nGRANT r_tenantA TO 'tenantA';\r\nSET DEFAULT ROLE r_tenantA TO 'tenantA';<\/code><\/pre>\n<p>You create roles that encapsulate the minimum privileges needed (least privilege), grant those roles on specific tables\/schemas, then assign the roles to tenant principals (users or service accounts). By setting a default role, every new session inherits the right permissions automatically, so existing connection strings, ORMs, and query paths continue to work.<\/p>\n<h3>Shared Hardware, Isolated Performance<\/h3>\n<p>Budgets cap noisy tenants. Placement keeps hot data close to fast nodes. RBAC limits blast radius. Result: shared hardware with isolated performance and no more screaming neighbors.<\/p>\n","accordion_column_title":"","accordion_sections":false,"video_image":false,"video_url":"","video_content":""}],"block_background":"block-bg-none","block_background_video_type":"url","block_background_video_url":"","block_background_video_file":false,"block_background_image":false,"block_background_overlay":false,"unique_id":"","block_option_custom_class":"","block_option_padding":["block-options-padding-remove-top","block-options-padding-remove-bottom"],"block_option_hide":[],"block_add_top_arc":false,"block_increase_bottom_padding":false},{"acf_fc_layout":"columns","format":"","enable_box_container":false,"column_num":"12","columns":[{"type":"wysiwyg","wysiwyg":"<h2 style=\"margin-top: 16px;\">Implementation Flight Plan<\/h2>\n<p>The following step-by-step plan will allow you to assess hotspots and tenant QoS, configure Resource Groups and placement, and roll out, monitor, and tune in phased cohorts with clear validation gates.<\/p>\n","accordion_column_title":"","accordion_sections":false,"video_image":false,"video_url":"","video_content":""}],"block_background":"block-bg-none","block_background_video_type":"url","block_background_video_url":"","block_background_video_file":false,"block_background_image":false,"block_background_overlay":false,"unique_id":"","block_option_custom_class":"","block_option_padding":["block-options-padding-remove-top","block-options-padding-remove-bottom"],"block_option_hide":[],"block_add_top_arc":false,"block_increase_bottom_padding":false},{"acf_fc_layout":"tabs","format":"","nav_title":"","nav_title_desc":"","nav_block_title":"","nav_content":"","format_title":"image","column_num":"12","sections":[{"title":"Step 1: Assess Hotspots & Tenant QoS","image":false,"title_text":"","title_image":false,"content":"<p>Profile tenants. Identify burst shapes and skew.<\/p>\n<pre><code>-- Store CPU snapshot (highest first)\r\nSELECT address, cpu_usage\r\nFROM information_schema.tikv_store_status\r\nORDER BY cpu_usage DESC;\r\n\r\n-- Leader distribution (higher = more leadership load)\r\nSELECT store_id,\r\n       SUM(CASE WHEN is_leader = 1 THEN 1 ELSE 0 END) AS leaders\r\nFROM information_schema.tikv_region_peers\r\nGROUP BY store_id\r\nORDER BY leaders DESC;<\/code><\/pre>"},{"title":"Step 2: Configure Resource Groups & Placement Labels","image":false,"title_text":"","title_image":false,"content":"<p>Set budgets and data placement via SQL. Label stores by zone or storage class.<\/p>\n<pre><code>-- Budgets\r\nCREATE RESOURCE GROUP rg_silver RU_PER_SEC=8000 BURSTABLE;\r\nALTER USER 'tenantB' RESOURCE GROUP 'rg_silver';\r\n\r\n-- Placement labels and policies\r\n-- (Store labels are configured in cluster; policies used here)\r\nCREATE PLACEMENT POLICY p_fast CONSTRAINTS='+zone=fast' FOLLOWERS=2;<\/code><\/pre>"},{"title":"Step 3: Rollout, Monitor, Optimize","image":false,"title_text":"","title_image":false,"content":"<p>Phase rollout by tenant cohorts. Validate SLOs. Tune limits and placement.<\/p>\n<pre><code>-- Validate normalization after changes\r\nSELECT digest_text, SUM_latency\/1000 AS ms\r\nFROM information_schema.statements_summary\r\nORDER BY ms DESC LIMIT 10;<\/code><\/pre>"}],"block_background":"block-bg-none","block_background_video_type":"url","block_background_video_url":"","block_background_video_file":false,"block_background_image":false,"block_background_overlay":false,"unique_id":"","block_option_custom_class":"tabs-side-left","block_option_padding":["block-options-padding-remove-top","block-options-padding-remove-bottom"],"block_option_hide":[],"block_add_top_arc":false,"block_increase_bottom_padding":false},{"acf_fc_layout":"columns","format":"","enable_box_container":false,"column_num":"12","columns":[{"type":"wysiwyg","wysiwyg":"<h2 style=\"margin-top: 16px;\">Operational Best Practices<\/h2>\n<p>This section turns guardrails into daily habits. Think of these as the routines that keep noisy neighbors quiet long after the initial rollout.<\/p>\n<h3>TiDB Dashboard: Heatmaps, Top SQL, Tenant Lens<\/h3>\n<p>Use heatmaps to spot drift and Top SQL to identify offenders quickly.<\/p>\n<pre><code class=\"language-sql\">-- Quick Top SQL view by total latency\r\nSELECT digest_text, SUM_latency\/1000 AS ms, exec_count\r\nFROM information_schema.statements_summary\r\nORDER BY ms DESC LIMIT 20;<\/code><\/pre>\n<h3>Backups with Resource Throttling<\/h3>\n<p>Throttle BR and restores so maintenance respects tenant budgets.<\/p>\n<pre><code>tiup br backup full \\\r\n  --pd \"http:\/\/pd:2379\" \\\r\n  --storage \"s3:\/\/bucket\/prefix\" \\\r\n  --ratelimit 120<\/code><\/pre>\n<h3>Capacity Forecasts &amp; Cost Guardrails<\/h3>\n<p>Track RU per tier, leader skew, and compaction backlog. Right-size nodes and set guardrails for automatic scale-out.<\/p>\n<pre><code>-- Simple RU consumption by user (illustrative if exposed)\r\n-- SELECT user, SUM(ru_consumed) FROM mysql.resource_usage GROUP BY user;<\/code><\/pre>\n<h3>Proving Noisy-Neighbor Isolation (Tenants A &amp; B)<\/h3>\n<p>We\u2019ll now run two concurrent <code>sysbench<\/code> loads to show how Resource Groups (and optional Placement Policies) keep one tenant\u2019s surge from degrading another.<\/p>\n<h4>1. Minimal Setup<\/h4>\n<pre><code>-- Two tenant DBs and users\r\nCREATE DATABASE tenantA; CREATE DATABASE tenantB;\r\nCREATE USER 'tenantA' IDENTIFIED BY '***';\r\nCREATE USER 'tenantB' IDENTIFIED BY '***';\r\nGRANT ALL ON tenantA.* TO 'tenantA';\r\nGRANT ALL ON tenantB.* TO 'tenantB';\r\n\r\n-- Optional: isolate hot tenant to faster nodes; keep others on standard tier\r\nCREATE PLACEMENT POLICY p_fast  CONSTRAINTS='+zone=fast'  FOLLOWERS=2;\r\nCREATE PLACEMENT POLICY p_std   CONSTRAINTS='+zone=std'   FOLLOWERS=2;\r\nALTER DATABASE tenantA PLACEMENT POLICY = p_fast;   -- premium \/ hot\r\nALTER DATABASE tenantB PLACEMENT POLICY = p_std;    -- standard\r\n<\/code><\/pre>\n<h4>2. Prepare Data with sysbench (Run Once Per Tenant)<\/h4>\n<pre><code># Common vars\r\nHOST=127.0.0.1 PORT=4000 PSWD=***\r\nTABLES=24 SIZE=10000\r\n\r\n# Tenant A (hot, write-heavy)\r\nsysbench oltp_write_only --mysql-host=$HOST --mysql-port=$PORT \\\r\n  --mysql-user=tenantA --mysql-password=$PSWD --tables=$TABLES --table-size=$SIZE prepare\r\n\r\n# Tenant B (steady, read-mostly)\r\nsysbench oltp_read_only --mysql-host=$HOST --mysql-port=$PORT \\\r\n  --mysql-user=tenantB --mysql-password=$PSWD --tables=$TABLES --table-size=$SIZE prepare<\/code><\/pre>\n<h4>Tenant A Baseline: No Isolation (Expect Interference)<\/h4>\n<p>Run both for 5 minutes at the same time:<\/p>\n<pre><code># Terminal 1 \u2013 Tenant A (write-heavy surge)\r\nsysbench oltp_write_only --time=300 --threads=64 \\\r\n  --mysql-host=$HOST --mysql-port=$PORT \\\r\n  --mysql-user=tenantA --mysql-password=$PSWD run\r\n\r\n# Terminal 2 \u2013 Tenant B (read-only, steady)\r\nsysbench oltp_read_only --time=300 --threads=64 \\\r\n  --mysql-host=$HOST --mysql-port=$PORT \\\r\n  --mysql-user=tenantB --mysql-password=$PSWD run<\/code><\/pre>\n<p>Illustrative outcome (no Resource Groups):<\/p>\n<table style=\"border-collapse: collapse; width: 100%; height: 204px;\">\n<tbody>\n<tr style=\"height: 45px;\">\n<td style=\"width: 30.416%; height: 45px;\"><strong>Metric (5m avg)<\/strong><\/td>\n<td style=\"width: 25.3916%; height: 45px;\"><strong>Tenant A (write)<\/strong><\/td>\n<td style=\"width: 44.1923%; height: 45px;\"><strong>Tenant B (read)<\/strong><\/td>\n<\/tr>\n<tr style=\"height: 69px;\">\n<td style=\"width: 30.416%; height: 69px;\">Throughput (tps)<\/td>\n<td style=\"width: 25.3916%; height: 69px;\">18,900<\/td>\n<td style=\"width: 44.1923%; height: 69px;\">22,400 \u2192 <strong>15,300<\/strong> during A\u2019s spikes<\/td>\n<\/tr>\n<tr style=\"height: 45px;\">\n<td style=\"width: 30.416%; height: 45px;\">Avg latency (ms)<\/td>\n<td style=\"width: 25.3916%; height: 45px;\">6.1<\/td>\n<td style=\"width: 44.1923%; height: 45px;\"><strong>3.8<\/strong> \u2192 <strong>8.5<\/strong> during A\u2019s spikes<\/td>\n<\/tr>\n<tr style=\"height: 45px;\">\n<td style=\"width: 30.416%; height: 45px;\">Top SQL share (%)<\/td>\n<td style=\"width: 25.3916%; height: 45px;\">72%<\/td>\n<td style=\"width: 44.1923%; height: 45px;\">28%<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>As you can see in the above table, Tenant A\u2019s write burst monopolizes CPU\/IO. Tenant B\u2019s latency doubles during spikes, which is a classic noisy neighbor.<\/p>\n<h4>Tenant B Baseline: Enable isolation with Resource Groups (seconds)<\/h4>\n<pre><code>-- Tiered RU budgets; allow short bursts\r\nCREATE RESOURCE GROUP rg_premium RU_PER_SEC=20000 BURSTABLE;\r\nCREATE RESOURCE GROUP rg_standard RU_PER_SEC=8000  BURSTABLE;\r\n\r\n-- Attach tenants (no app changes)\r\nALTER USER 'tenantA' RESOURCE GROUP 'rg_premium';\r\nALTER USER 'tenantB' RESOURCE GROUP 'rg_standard';<\/code><\/pre>\n<p>Now re-run the same <code>sysbench<\/code> commands concurrently.<\/p>\n<p>Illustrative outcome (with Resource Groups):<\/p>\n<table style=\"border-collapse: collapse; width: 100%; height: 204px;\">\n<tbody>\n<tr style=\"height: 45px;\">\n<td style=\"width: 30.416%; height: 45px;\"><strong>Metric (5m avg)<\/strong><\/td>\n<td style=\"width: 25.3916%; height: 45px;\"><strong>Tenant A (write)<\/strong><\/td>\n<td style=\"width: 44.1923%; height: 45px;\"><strong>Tenant B (read)<\/strong><\/td>\n<\/tr>\n<tr style=\"height: 69px;\">\n<td style=\"width: 30.416%; height: 69px;\">Throughput (tps)<\/td>\n<td style=\"width: 25.3916%; height: 69px;\">17,600 (shaped)<\/td>\n<td style=\"width: 44.1923%; height: 69px;\"><strong>22,100<\/strong> \u2192 <strong>21,700<\/strong> (stable)<\/td>\n<\/tr>\n<tr style=\"height: 45px;\">\n<td style=\"width: 30.416%; height: 45px;\">Avg latency (ms)<\/td>\n<td style=\"width: 25.3916%; height: 45px;\">6.8 (shaped)<\/td>\n<td style=\"width: 44.1923%; height: 45px;\"><strong>3.9<\/strong> \u2192 <strong>4.2<\/strong> (minor ripple)<\/td>\n<\/tr>\n<tr style=\"height: 45px;\">\n<td style=\"width: 30.416%; height: 45px;\">Top SQL share (%)<\/td>\n<td style=\"width: 25.3916%; height: 45px;\">65%<\/td>\n<td style=\"width: 44.1923%; height: 45px;\">35%<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>As you can see, Tenant A still gets high throughput (within premium budget), but Tenant B\u2019s latency stays stable. The budget prevents A from starving B.<\/p>\n<h4>What to Watch During the Run<\/h4>\n<p>In the TiDB Dashboard, keep an eye on:<\/p>\n<ul>\n<li><strong>Heatmaps:<\/strong> look for flat tail latency under load after enforcing budgets.<\/li>\n<li><strong>Top SQL:<\/strong> confirm heavy digests are attributed to Tenant A during its surge.<\/li>\n<li><strong>KV\/Regions:<\/strong> ensure leader distribution isn\u2019t skewed; rebalancing stable.<\/li>\n<\/ul>\n<p>You can also run a couple quick SQL checks:<\/p>\n<pre><code>-- Tenant-scoped view (replace with your statement fingerprint or user filter)\r\nSELECT user, digest_text,\r\n       SUM(exec_count) AS execs,\r\n       ROUND(SUM(sum_latency)\/1000) AS total_ms\r\nFROM information_schema.statements_summary\r\nGROUP BY user, digest_text\r\nORDER BY total_ms DESC LIMIT 10;\r\n\r\n-- Leader distribution sanity check\r\nSELECT store_id,\r\n       SUM(CASE WHEN is_leader=1 THEN 1 ELSE 0 END) AS leaders\r\nFROM information_schema.tikv_region_peers\r\nGROUP BY store_id\r\nORDER BY leaders DESC;<\/code><\/pre>\n<h4>Backups and Maintenance that Respect Budgets<\/h4>\n<p>Keep \u201cbackground\u201d work quiet so it doesn\u2019t reintroduce noisy-neighbor effects:<\/p>\n<pre><code># Throttled BR full backup (respects rate limit)\r\ntiup br backup full \\\r\n  --pd \"http:\/\/pd:2379\" \\\r\n  --storage \"s3:\/\/bucket\/prefix\" \\\r\n  --ratelimit 120   # MB\/s \u2013 tune per tier<\/code><\/pre>\n<h4>Capacity Forecasts &amp; Guardrails<\/h4>\n<p>Track consumption and set caps before tenants get noisy.<\/p>\n<pre><code>-- (Illustrative) RU by user if exposed in your env\r\n-- SELECT user, SUM(ru_consumed) AS ru_total\r\n-- FROM mysql.resource_usage\r\n-- GROUP BY user ORDER BY ru_total DESC;<\/code><\/pre>\n<p>Policy tips:<\/p>\n<ul>\n<li>Premium tenants \u2192 higher RU, fast tier placement.<\/li>\n<li>Standard tenants \u2192 moderate RU, standard tier.<\/li>\n<li>When a tenant upgrades\/downgrades, it\u2019s a SQL change, not a migration.<\/li>\n<\/ul>\n<p>With Resource Groups (and optional Placement Policies), Tenant B\u2019s experience remains consistent, even while Tenant A surges. That\u2019s the day-two habit that keeps noisy neighbors quiet long after rollout.<\/p>\n<h2>Why TiDB Handles Noisy Neighbors Well<\/h2>\n<p>Noisy-neighbor incidents happen when one tenant\u2019s burst steals CPU and IO from everyone else. TiDB gives you performance isolation on shared hardware, so you keep multi-tenant efficiency without sacrificing SLAs or blowing up costs.<\/p>\n<ul>\n<li><strong>Performance isolation without silos.<\/strong> Use Resource Groups (RU budgets) to give each tenant a guaranteed compute and IO envelope, plus optional bursting. One tenant\u2019s surge is shaped before it harms others.<\/li>\n<li><strong>Lower cost through shared hardware and visible spend.<\/strong> Decoupled compute and object storage let you scale up and down by seconds, not migrations. RU metering shows per-query and per-tenant cost so you can cap noisy workloads and reduce over-provisioning.<\/li>\n<li><strong>Operational simplicity.<\/strong> All controls are SQL-first: create or change budgets, move tenants between tiers, and throttle background jobs without app changes. Online DDL and rolling upgrades keep change inside SLOs, so you do not need maintenance windows.<\/li>\n<li><strong>Hot where it matters, cost-efficient where it doesn\u2019t.<\/strong> Placement Policies pin hot partitions to fast nodes and park cold data on cost-efficient storage while preserving replication and availability.<\/li>\n<li><strong>One platform for mixed workloads.<\/strong> OLTP and analytics run on the same data with TiKV (row storage) and TiFlash (columnar storage). Heavy reads move off the transactional hot path, which protects tail latency during tenant spikes.<\/li>\n<li><strong>Clean multi-tenant patterns.<\/strong> Schema or database per tenant scales to very large counts, keeps blast radius small, and makes auditing, residency, and recovery straightforward.<\/li>\n<\/ul>\n<p>With TiDB, p95 and p99 remain predictable during bursts, tenants stop tripping over each other, and your team manages budgets, placement, and change with a few SQL statements instead of fire drills.<\/p>\n<h2>Proof in Production<\/h2>\n<p>Real systems, real stakes. In this section, you\u2019ll discover how real-world teams tamed noisy neighbors at massive scale, consolidating fleets, enforcing per-tenant budgets, and shipping changes without downtime.<\/p>\n<h3>Atlassian: From Hundreds of Postgres Clusters to 16 TiDB Clusters with 50\u00d7 Efficiency<\/h3>\n<p><a href=\"https:\/\/www.pingcap.com\/blog\/scaling-3-million-tables-how-tidb-powers-atlassian-forge-saas-platform\/\">Atlassian<\/a> needed to run millions of tenant schemas and hundreds of tables per product while supporting per-tenant features (BYOK, data residency, PITR) and a sprawling plugin ecosystem. Traditional siloed Postgres fleets multiplied operational toil and made fleet-wide schema changes painfully slow. After evaluating distributed SQL options, Atlassian moved to TiDB to get deterministic multi-tenant performance, far denser bin-packing, and online evolution at Jira scale without breaking the developer experience.<\/p>\n<h4>Outcomes<\/h4>\n<ul>\n<li>Successfully tested with <strong>4,000+ schemas<\/strong> across <strong>3M+ tables within a single TiDB cluster<\/strong>.<\/li>\n<li><strong>~50\u00d7<\/strong> improvement in bin-packing efficiency (many more tenants per cluster).<\/li>\n<li>Fleet consolidation from <strong>hundreds of Postgres clusters<\/strong> to about <strong>16 TiDB clusters<\/strong> (12 global regions + 4 regulated).<\/li>\n<li>Zero-downtime major-version upgrades.<\/li>\n<li><strong>6\u20137\u00d7 faster<\/strong> DDL pipeline, enabling <strong>24-hour<\/strong> fleet-wide schema evolution.<\/li>\n<li>Stronger multi-tenant controls (resource isolation, placement) while <strong>reducing infra and ops costs<\/strong>.<\/li>\n<\/ul>\n<p><iframe loading=\"lazy\" src=\"\/\/www.youtube.com\/embed\/asnCJI39MpE\" width=\"640\" height=\"359\" allowfullscreen=\"allowfullscreen\"><\/iframe><\/p>\n<h3>Plaid: Faster Upgrades, Higher Uptime, Non-Disruptive Scale<\/h3>\n<p><a href=\"https:\/\/www.pingcap.com\/blog\/accelerating-distributed-sql-adoption-plaid-amazon-aurora-migration\/\">Plaid\u2019s<\/a> high-growth payments and data-network services outgrew Amazon Aurora MySQL operationally: <strong>300+ clusters<\/strong> and <strong>800+ servers<\/strong> made upgrades a months-long project and write scaling difficult. TiDB\u2019s MySQL compatibility, horizontal scale, and online schema changes let Plaid migrate service by service with a blue-green-red cutover pattern and feature-flag rollouts, preserving developer velocity while raising availability.<\/p>\n<h4>Outcomes<\/h4>\n<ul>\n<li><strong>41 services<\/strong> migrated in roughly a year with minimal disruption.<\/li>\n<li><strong>Non-disruptive scaling<\/strong> (reads and writes) and <strong>faster upgrades<\/strong> vs. Amazon Aurora MySQL.<\/li>\n<li><strong>Higher uptime<\/strong> and lower maintenance burden through online DDL and elastic scale-out.<\/li>\n<li><strong>Lower operational complexity<\/strong> by retiring dozens of bespoke Amazon Aurora clusters and procedures.<\/li>\n<\/ul>\n<p><iframe loading=\"lazy\" src=\"\/\/www.youtube.com\/embed\/o6eetnpi-3Q\" width=\"640\" height=\"359\" allowfullscreen=\"allowfullscreen\"><\/iframe><\/p>\n<h2>Next Steps<\/h2>\n<p>Ready to put this playbook into practice? Here are a couple ways you can take the next step with TiDB.<\/p>\n<p>&nbsp;<\/p>\n","accordion_column_title":"","accordion_sections":false,"video_image":false,"video_url":"","video_content":""}],"block_background":"block-bg-none","block_background_video_type":"url","block_background_video_url":"","block_background_video_file":false,"block_background_image":false,"block_background_overlay":false,"unique_id":"","block_option_custom_class":"","block_option_padding":["block-options-padding-remove-top","block-options-padding-remove-bottom"],"block_option_hide":[],"block_add_top_arc":false,"block_increase_bottom_padding":false},{"acf_fc_layout":"columns","format":"","enable_box_container":false,"column_num":"12","columns":[{"type":"wysiwyg","wysiwyg":"<div class=\"bg-red\" style=\"height: 100%;\">\n<table class=\"bg-red\" style=\"width: 100%; height: 200px; border-collapse: collapse; border-style: none;\">\n<tbody>\n<tr>\n<td style=\"width: 100%;\">\n<h3><span style=\"color: #ffffff;\">Launch a Free TiDB Cluster<\/span><\/h3>\n<p><span style=\"color: #ffffff;\">Spin up a free TiDB sandbox and prove that noisy neighbors don\u2019t wreck your SLOs. In minutes, you\u2019ll validate per-tenant budgets, pin hot data to fast nodes, and watch neighbor latency stay flat during a surge.<\/span><\/p>\n<p><span style=\"color: #ffffff;\">Here\u2019s what you\u2019ll get:<\/span><\/p>\n<ol>\n<li style=\"font-weight: 400; color: #ffffff;\" aria-level=\"1\"><span style=\"color: #ffffff;\">Validate Resource Groups and Placement Rules with your traffic shape<\/span><\/li>\n<li style=\"font-weight: 400; color: #ffffff;\" aria-level=\"1\"><span style=\"color: #ffffff;\">See predictable per-tenant p95 without per-tenant silos<\/span><\/li>\n<li style=\"font-weight: 400; color: #ffffff;\" aria-level=\"1\"><span style=\"color: #ffffff;\">Walk away with screenshots you can share with leadership<\/span><\/li>\n<\/ol>\n<p><a class=\"button\" href=\"https:\/\/tidbcloud.com\/free-trial\/\" data-gtag=\"event:go_to_cloud_signup,product_type:starter,button_name:Start for Free,position:cta\" style=\"margin-top: 5px;\">Start for Free<\/a><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n","accordion_column_title":"","accordion_sections":false,"video_image":false,"video_url":"","video_content":""},{"type":"wysiwyg","wysiwyg":"<table class=\"bg-red\" style=\"width: 100%; height: 200px; border-collapse: collapse; border-style: none;\">\n<tbody>\n<tr>\n<td style=\"width: 100%;\">\n<h3><span style=\"color: #ffffff;\">Book a Multi-Tenant Architecture Workshop<\/span><\/h3>\n<p><span style=\"color: #ffffff;\">Turn this playbook into a roadmap. In a 60\u201390 minute working session with TiDB experts, we\u2019ll map your tenant tiers, set RU budgets, and design data placement so you can protect SLOs on shared hardware without exploding fleet size.<\/span><\/p>\n<p><span style=\"color: #ffffff;\">Here\u2019s what you\u2019ll get:<\/span><\/p>\n<ol>\n<li style=\"font-weight: 400; color: #ffffff;\" aria-level=\"1\"><span style=\"color: #ffffff;\">A tailored tenant tiering model<\/span><\/li>\n<li style=\"font-weight: 400; color: #ffffff;\" aria-level=\"1\"><span style=\"color: #ffffff;\">A draft placement plan for hot vs. cold datasets<\/span><\/li>\n<li style=\"font-weight: 400; color: #ffffff;\" aria-level=\"1\"><span style=\"color: #ffffff;\">A phased rollout strategy and concrete runbook updates<\/span><\/li>\n<\/ol>\n<p><a class=\"button\" href=\"\/contact-us\/\">Request a Workshop<\/a><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n","accordion_column_title":"","accordion_sections":false,"video_image":false,"video_url":"","video_content":""}],"block_background":"block-bg-none","block_background_video_type":"url","block_background_video_url":"","block_background_video_file":false,"block_background_image":false,"block_background_overlay":false,"unique_id":"","block_option_custom_class":"","block_option_padding":["block-options-padding-remove-top"],"block_option_hide":[],"block_add_top_arc":false,"block_increase_bottom_padding":false}],"_links":{"self":[{"href":"https:\/\/www.pingcap.com\/ko\/wp-json\/wp\/v2\/pages\/30913","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.pingcap.com\/ko\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/www.pingcap.com\/ko\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/www.pingcap.com\/ko\/wp-json\/wp\/v2\/users\/184"}],"replies":[{"embeddable":true,"href":"https:\/\/www.pingcap.com\/ko\/wp-json\/wp\/v2\/comments?post=30913"}],"version-history":[{"count":3,"href":"https:\/\/www.pingcap.com\/ko\/wp-json\/wp\/v2\/pages\/30913\/revisions"}],"predecessor-version":[{"id":30918,"href":"https:\/\/www.pingcap.com\/ko\/wp-json\/wp\/v2\/pages\/30913\/revisions\/30918"}],"wp:attachment":[{"href":"https:\/\/www.pingcap.com\/ko\/wp-json\/wp\/v2\/media?parent=30913"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}