PingCAP
  • Cloud
  • TiDB Academy
  • Docs
  • Success Stories
  • Blog
  • Free Download
PingCAP
  • Cloud
  • TiDB Academy
  • Docs
  • Success Stories
  • Blog
  • Free Download

Contact

中文
  • TiDB Academy
  • avatar
  • Academy Profile
  • Sign Out
  • Introduction:
    • Course Overview
    • Format and Housekeeping
    • Setting up Google Cloud Platform
    • Introduction to Distributed Databases
  • TiDB Overview:
    • TiDB Platform
    • Optional Components: TiSpark
    • The KOST Stack
    • Lab: Deploying TiDB Platform on GKE
    • Recap: Deploying TiDB Platform on GKE
  • MySQL Compatibility:
    • Overview
    • Behavior Differences
    • Default Differences
    • Lab: Loading Sample Data
    • Recap: Loading Sample Data
  • Query Optimization:
    • Overview
    • EXPLAIN
    • Lab: Optimize Queries
    • Lab Recap: Optimize Queries
    • The Coprocessor
  • HTAP:
    • Overview
    • TiDB + Apache Spark
    • Lab: HTAP
    • Lab Recap: HTAP
  • Backup and Restore:
    • Overview
    • Lab: Restore from Accidental Delete
    • Lab Recap: Restore from Accidental Delete
    • Lab: Backup and Restore
    • Lab Recap: Backup and Restore
  • Schema Changes:
    • Overview
    • Google's F1 DDL Algorithm
    • Lab: ALTER TABLE online
    • Lab Recap: ALTER TABLE online
  • Scaling the TiDB Platform:
    • Overview
    • Scaling Patterns
    • Lab: Scaling TiDB
    • Lab Recap: Scaling TiDB
    • Placement Driver
  • Updates, Upgrades and Migrations:
    • Overview
    • Updates
    • Upgrades
    • Migration from MySQL
  • Data Migration (DM):
    • Overview
    • Example Usage
  • RocksDB:
    • Overview
    • Architecture
  • Monitoring and Observability:
    • Overview
    • Observability
    • Lab: Prometheus and Grafana
    • Lab Recap: Prometheus and Grafana
  • Conclusion:
    • Course Summary
    • Shutdown your TiDB Cluster
    • What's Next?

Horizontal Scaling

Transcript

Welcome back. In this video, we are going to talk about scaling, which for the TiDB platform you can independently perform across two different dimensions.

First, you can scale the SQL processing by changing the number of TiDB Servers. Since TiDB servers are stateless, this is a very quick operation, both in terms of scaling out by increasing the count of TiDB instances and in terms of scaling in by decreasing the count.

The second type of scaling is with regard to storage and the number of TiKV Servers. With TiKV, it is relatively simple to increase or scale up the number of instances, but with decreasing there is a little bit of added complexity. Because TiKV maintains state (it stores your data), scale in activity has to be performed in such a fashion that it doesn’t degrade the health of the cluster.

That is to say, scaling TiKV involves an act of rebalancing the Regions (which is TiDB Platform terminology for units of approximately 100MB each). A graceful scale in leaves sufficient time for servers to be drained of their Regions with the remaining TiKV servers having sufficient free capacity to take over.

This problem is not unique to TiKV. The good news is: Kubernetes understands that there are these additional steps to scale stateful services. With Kubernetes and operator, scaling both SQL and storage is not only possible but actually very easy to achieve.

Product

  • TiDB
  • TiSpark
  • Roadmap

Docs

  • Quick Start
  • Best Practices
  • FAQ
  • TiDB Tools
  • Release Notes

Resources

  • Blog
  • Weekly
  • GitHub
  • TiDB Community

Company

  • About
  • Careers
  • News
  • Contact Us
  • Privacy Policy
  • Terms of Service

Connect

  • Twitter
  • LinkedIn
  • Reddit
  • Google Group
  • Stack Overflow

© 2019 PingCAP. All Rights Reserved.

中文