TiDB Dashboard is a Web UI for monitoring, diagnosing and managing the TiDB cluster.
Feel free to open GitHub issues for questions, support and suggestions.
You may also consider to reach out on the TiDB Internals forum if you encounter any problems about TiDB development.
For Chinese users, you can visit the PingCAP official user forum AskTUG.com to make life easier.
The most easy way to use TiDB Dashboard with an existing TiDB cluster is to use the one embedded into PD: http://127.0.0.1:2379/dashboard. You need PD master branch or 4.0+ version to use TiDB Dashboard.
Note: The TiDB Dashboard inside PD may be not up to date. To play with latest TiDB Dashboard, build it from source (see next section).
Manage SSO while signed in directly with a SQL account that has Dashboard write privileges. Enabling or updating SSO requires the password of the currently impersonated SQL account. To disable SSO and clear its configuration and delegation, re-enter the currently signed-in SQL account's password; its Dashboard write privileges are checked again. This also allows recovery if the old impersonated account has been deleted or lost privileges. To choose another SQL account, disable SSO first, then enable it with the new account's credentials. Configuration and SQL authorization are saved together; existing SSO sessions and their sharing codes are revoked whenever the configuration or authorization changes.
Upgrading from the legacy SSO implementation invalidates existing Dashboard sessions and sharing codes, including SQL sessions. Sign in again using SQL credentials and save the SSO configuration with fresh SQL authorization before using SSO again. Existing SSO credentials are not automatically trusted with the new configuration binding. If configuration persistence fails, SSO may remain unavailable until the configuration is successfully saved again; SQL login remains available for recovery.
Upgrade the Dashboard backend and bundled UI together. A new UI connected to a legacy
backend displays an upgrade requirement and does not fall back to insecure SSO management.
OIDC ID tokens signed with HS256, HS384, or HS512 are verified using the configured client
secret; asymmetric signatures continue to use the provider's JWKS. The settings API hides
the client secret. Leaving it blank preserves the stored secret for the same provider and
Client ID, including during upgrade reauthorization. To replace it, enter a new secret;
to remove it, select the explicit clear option (clear_client_secret for API callers).
Changing provider or Client ID requires a new secret or explicit clearing, so the stored
secret is never silently forwarded to another client or provider. Disabling SSO clears it.
Key Visualizer policies must be db or kv, even while collection is disabled.
Invalid updates are rejected before persistence. A disable-only API request may omit
the policy; the current valid policy is preserved. Existing missing or invalid policies
are repaired to db during startup before collection can be enabled. Valid policies and
key separators are preserved. An unsupported strategy returns a service error instead
of terminating the Dashboard or embedding PD process.
Checkout our help wanted issues for a list of recommended tasks, in which we have also marked the difficulty level.
See CONTRIBUTING.md for a detailed step-by-step contributing guide, or steps to build TiDB Dashboard from source.
If you need any help, feel free to reach out on the TiDB Internals forum.
Thank you to all the people who already contributed to TiDB Dashboard!
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
This repository contains both Dashboard HTTP API and Dashboard UI. Dashboard HTTP API is placed in
pkg/ directory, written in Golang. Dashboard UI is placed in ui/ directory, powered by React.
TiDB Dashboard can also be integrated into PD, as follows:
Copyright 2020 PingCAP, Inc.