- Introduction
-
Concepts
- Architecture
-
Key Features
- Horizontal Scalability
- MySQL Compatible Syntax
- Replicate from and to MySQL
- Distributed Transactions with Strong Consistency
- Cloud Native Architecture
- Minimize ETL with HTAP
- Fault Tolerance & Recovery with Raft
- Automatic Rebalancing
- Deployment and Orchestration with Ansible, Kubernetes, Docker
- JSON Support
- Spark Integration
- Read Historical Data Without Restoring from Backup
- Fast Import and Restore of Data
- Hybrid of Column and Row Storage
- SQL Plan Management
- Open Source
- Online Schema Changes
- How-to
-
Reference
- Tools
- MySQL Compatibility
-
SQL
- SQL Language Structure
- Data Types
-
Functions and Operators
- Function and Operator Reference
- Type Conversion in Expression Evaluation
- Operators
- Control Flow Functions
- String Functions
- Numeric Functions and Operators
- Date and Time Functions
- Bit Functions and Operators
- Cast Functions and Operators
- Encryption and Compression Functions
- Information Functions
- JSON Functions
- Aggregate (GROUP BY) Functions
- Window Functions
- Miscellaneous Functions
- Precision Math
-
SQL Statements
- ADD COLUMN
- ADD INDEX
- ADMIN
- ALTER DATABASE
- ALTER TABLE
- ALTER USER
- ANALYZE TABLE
- BEGIN
- COMMIT
- CREATE DATABASE
- CREATE INDEX
- CREATE TABLE LIKE
- CREATE TABLE
- CREATE USER
- CREATE VIEW
- DEALLOCATE
- DELETE
- DESC
- DESCRIBE
- DO
- DROP COLUMN
- DROP DATABASE
- DROP INDEX
- DROP TABLE
- DROP USER
- DROP VIEW
- EXECUTE
- EXPLAIN ANALYZE
- EXPLAIN
- FLUSH PRIVILEGES
- FLUSH STATUS
- FLUSH TABLES
- GRANT <privileges>
- INSERT
- KILL [TIDB]
- LOAD DATA
- MODIFY COLUMN
- PREPARE
- RECOVER TABLE
- RENAME INDEX
- RENAME TABLE
- REPLACE
- REVOKE <privileges>
- ROLLBACK
- SELECT
- SET [NAMES|CHARACTER SET]
- SET PASSWORD
- SET TRANSACTION
- SET [GLOBAL|SESSION] <variable>
- SHOW CHARACTER SET
- SHOW COLLATION
- SHOW [FULL] COLUMNS FROM
- SHOW CREATE TABLE
- SHOW CREATE USER
- SHOW DATABASES
- SHOW ENGINES
- SHOW ERRORS
- SHOW [FULL] FIELDS FROM
- SHOW GRANTS
- SHOW INDEXES [FROM|IN]
- SHOW INDEX [FROM|IN]
- SHOW KEYS [FROM|IN]
- SHOW PRIVILEGES
- SHOW [FULL] PROCESSSLIST
- SHOW SCHEMAS
- SHOW [FULL] TABLES
- SHOW TABLE REGIONS
- SHOW TABLE STATUS
- SHOW [GLOBAL|SESSION] VARIABLES
- SHOW WARNINGS
- SPLIT REGION
- START TRANSACTION
- TRACE
- TRUNCATE
- UPDATE
- USE
- Constraints
- Generated Columns
- Partitioning
- Character Set
- SQL Mode
- Views
- Configuration
- Key Monitoring Metrics
- Alert Rules
- Security
- Transactions
- System Databases
- Errors Codes
- Supported Client Drivers
- Garbage Collection (GC)
- Performance
- Best Practices
- TiSpark
- TiDB Binlog Cluster Overview
- Adopters
- TiDB in Kubernetes
- FAQs
- Support
- Contribute
- Roadmap
- Releases
Access the TiDB Cluster in Kubernetes
This document describes how to access the TiDB cluster in Kubernetes.
- To access the TiDB cluster within a Kubernetes cluster, use the TiDB service domain name
<release-name>-tidb.<namespace>. To access the TiDB cluster outside a Kubernetes cluster, expose the TiDB service port by editing the
tidb.servicefield configuration in thevalues.yamlfile of thetidb-clusterHelm chart.tidb: service: type: NodePort # externalTrafficPolicy: Cluster # annotations: # cloud.google.com/load-balancer-type: Internal
NodePort
If there is no LoadBalancer, expose the TiDB service port in the following two modes of NodePort:
externalTrafficPolicy=Cluster: All machines in the Kubernetes cluster assign a NodePort to TiDB Pod, which is the default mode.When using the
Clustermode, you can access the TiDB service by using the IP address of any machine plus a same port. If there is no TiDB Pod on the machine, the corresponding request is forwarded to the machine with a TiDB Pod.Note:
In this mode, the request’s source IP obtained by the TiDB server is the node IP, not the real client’s source IP. Therefore, the access control based on the client’s source IP is not available in this mode.
externalTrafficPolicy=Local: Only those machines that runs TiDB assign NodePort to TiDB Pod so that you can access local TiDB instances.When you use the
Localmode, it is recommended to enable theStableSchedulingfeature oftidb-scheduler.tidb-schedulertries to schedule the newly added TiDB instances to the existing machines during the upgrade process. With such scheduling, client outside the Kubernetes cluster does not need to upgrade configuration after TiDB is restarted.
View the IP/PORT exposed in NodePort mode
To view the Node Port assigned by Service, run the following commands to obtain the Service object of TiDB:
namespace=<your-tidb-namesapce>release=<your-tidb-release-name>kubectl -n <namespace> get svc <release-name>-tidb -ojsonpath="{.spec.ports[?(@.name=='mysql-client')].nodePort}{'\n'}"To check you can access TiDB services by using the IP of what nodes, see the following two cases:
- When
externalTrafficPolicyis configured asCluster, you can use the IP of any node to access TiDB services. When
externalTrafficPolicyis configured asLocal, use the following commands to get the nodes where the TiDB instance of a specified cluster is located:kubectl -n <namespace> get pods -l "app.kubernetes.io/component=tidb,app.kubernetes.io/instance=<release-name>" -ojsonpath="{range .items[*]}{.spec.nodeName}{'\n'}{end}"
LoadBalancer
If Kubernetes is run in an environment with LoadBalancer, such as GCP/AWS platform, it is recommended to use the LoadBalancer feature of these cloud platforms by setting tidb.service.type=LoadBalancer.
See Kubernetes Service Documentation to know more about the features of Service and what LoadBalancer in the cloud platform supports.