shutdownを伴うTiDBクラスター操作ではリソース不足にご注意を
ざっくりまとめ 1. 【前提】 shutdownを伴うTiDBクラスター操作には、TiDB Serverのスケールアップ/ダウン/イン、TiDB Clusterのアップグレードなどがある TiDBではshutdownを伴う操作に対して、1ノードずつローリングアップデートする方式を取ることで、無停止で
Category
tidb
26 articles
TiDB Cloudの最大コネクション数は制限無し、、、ではなさそうだった(v8.5.5)
本記事は「TiDB Cloud Dedicated v8.5.5」を対象とした記事です。 サーバレスタイプやSelf hostedタイプのTiDBとは仕様が異なる場合があります。 TiDB Cloudの最大コネクション数の制限はunlimited TiDB Cloudには様々な制限がありますが、最大
アーキテクチャから学ぶ分散SQL TiDBの強み・弱み
本スライド資料はTiDB・NewSQLの導入を検討しており、ステークホルダーにメリットデメリットを説明する必要がある人向けの資料になります。 https://speakerdeck.com/yukiodesuyo/akitekutiyakaraxuebufensansqltidbnoqiangmir
TiDBクラスター操作時にロングトランザクションがkillされる流れについて図解解説
はじめに 今回は無停止でのクラスター操作が可能と言われているTiDBにおいて、SpringBatchの使い方の誤りにより、クラスター操作中にtxがkillされてしまう事例についてご紹介します。 前提となるTiDBクラスター構成 前提となるクラスター構成は以下の通りです。 ポイントはTiProxyを挟
TiDB移行PoCの一番のハードルは仕組みを理解してもらうことだった
DBのコストが高い 「インフラをAzureからAWSへ移行したことでシステムは安定するようになったがインフラコストが高い、、、特にDBがRDS ON SQL SERVERを使っており、高い、、、」 これは私が所属する部署内で何年も言われてきた課題ですが、実際OSSの安いデーターベースに移行をしようと
マルチテナントシステムにおけるTiDBのResource Group戦略の例
はじめに スケーラブルかつ高可用性・強整合性という特徴を持った分散DBであるTiDBにはユーザごとに論理的にリソース上限を設けることが可能である。 今回はリソース上限を設ける仕組みであるResource Groupの構成例について示す。 想定するシステム 想定しているシステムは以下のようにテナントご
TiDBのLONGTEXT型にはデフォルト設定では6MiBまでしか保存できないことを検証してみた
はじめに TiDBのLONGTEXT型の最大列長は 4,294,967,295 ですが、実はデフォルト設定では6MiB以上のデータはエラーで保存できなくなっています。 今回はその回避方法について1つずつ検証しながら解説します。 結論 先に結論を書いておくと、以下の通り設定をいじって保存できるデータサ
TiDBのLONGTEXTはデフォルトだと4GB格納できない
v8.5のTiDBで利用できるLONGTEXTは型は最大長では4GB格納できますが、txnentrysizelimitという設定により6MiB以下のデータしか保存できないようになっています。 https://docs.pingcap.com/ja/tidb/stable/datatypestring
【図解】TiDBのAUTO_INCREMENTを体系的に理解する
はじめに TiDBはクラスタ化された分散ノードが協調動作することでスケーラビリティを実現しています。 一方でスケーラビリティを重視してノードを分散させるようにしたことで、デフォルトのAUTOINCREMENTの動作ではIDは1, 30001, 2, 30002のように値が飛び飛びで採番されます。 本
TiFlashをテーブルに設定したがTiFlashが使われない問題の解決 ~ANALYZE TABLEの実施~
TiFlashの利用方法 TiDB Cloud DedicatedではTiFlashを簡単に利用することができます。 利用方法は以下のとおりです。 1. TiDB Cloud DedicatedのConsole画面からクラスターを変更し、TiFlashを追加する 3. ALTER TABLE tab
「作って壊して直して学ぶNewSQL入門 / CH8 TiDBクラスターをつくって運用しよう」をLinuxでやってみる
はじめに 「作って壊して直して学ぶNewSQL入門」というTiDBの書籍が出ており、その中で様々なハンズオンがあったので実際にやってみました。 https://amzn.to/3HB8dtmhttps://amzn.to/3HB8dtm Localで実施できるものは皆やってそうだなーと思ったのでさく
TiDBのissueを眺める「flaky test for IMPORT INTO」
https://github.com/pingcap/tidb/issues/60109https://github.com/pingcap/tidb/issues/60109 どんなissueか？ このissueはintegration test実行時に権限に関するテストがflakyであるというイ
TiDBに組み込み関数を追加実装する
本記事ではTiDBの開発者ガイドの「add a function」を参考に新しい関数を追加してみようと思います。 https://github.com/pingcap/tidbdevguide/blob/master/src/extendingtidb/addafunction.mdhttps://
TiDBのコードリーディング「サーバの起動」
本記事ではTiDBのOSSのコードを読みつつ、メモをしていきます。 サーバー起動 まずTiDBではサーバ起動時にtidbserver/main.goが実行されます。 https://github.com/pingcap/tidb/blob/master/cmd/tidbserver/main.goh
TiDBをソースコードからビルドしてターミナルから実行する
https://pingcap.github.io/tidbdevguidehttps://pingcap.github.io/tidbdevguide TiDBで利用されているバージョンのGoをインストールする まずTiDBで使われているGoのバージョンを以下のコマンドで取得して、そのバージョンの
TiDBのテストをIDE上で実行する
https://pingcap.github.io/tidbdevguide/getstarted/setupanide.htmlhttps://pingcap.github.io/tidbdevguide/getstarted/setupanide.html IDEの準備 まずVsCodeをインス
マルチテナントのスキーマレベル分離をどのように実装するか？[マルチテナントアーキテクチャ]
現状のテナント分離構造「インスタンスレベル分離」 私が関わっているプロダクトでは図のような「インスタンスレベル分離」というテナント分離構造になっています。 具体的にはテナント毎にアプリケーションが別れており、DBクラスタSQL Serverも同様にテナント毎に別れている状況です。 DBからテナントの
TiDB Cloudで外部キー制約のチェックをGLOBALスコープでオフにしても、引き続きチェックが走る [TiDB Cloud Dedicated]
やりたかったこと「外部キー制約のチェックをオフにしたい」 TiDB Cloudでの性能試験時にインサートのクエリが遅くなっており、実行計画を見ると外部キー制約のチェックで4秒ほど時間を使っていることがわかりました。 TiDBにおいて外部キー制約によってインサートが遅くなる理由については以下の記事で紹
TiDB Cloud DedicatedでAuroraのSnapShotをインポートする際に、Access Deniedと出る
やりたかったこと「AuroraのSnapShotをTiDB Cloudのインポート画面から読み込んでTiDBにデータ作成する」 AuroraMySQLのデータをTiDBに移行するために、まず、以下の記事を参考にDumplingでAuroraのDDLをエクスポートし、それをTiDBにインポートしました
外部キー制約によるインサートの性能劣化はNewSQLの意外な欠点
NewSQLの代表的な欠点「レイテンシー」 NewSQLの欠点としてよく上がるのが「レイテンシー」です。 これは分散DBである程度強いデータ整合性を達成しようと思うと、仕方ない話なのかなと思います。 構造的にも納得できます。 意外な欠点「外部キー制約で性能劣化する」「外部キー制約が使えない」 多少レ
tidb lightning encountered error: [Lightning:Storage:ErrStorageUnknown]unknown storage error: ExpiredToken: The provided token has expired.
What I did I executed Llightning for importing Aurora MySQL SnapShot into TiDB Cloud Dedicatedv8.1.2. Encountered Error lightening.go Workaround: Fix
[TiDB] Aurora MySQLのスナップショットをLightningでTiDBに復元しようとしたら「tidb lightning encountered error: [Lightning:Restore:ErrSchemaNotExists]table hoge.gz schema not found」が出た
What I do: やろうとしていたこと Aurora MySQLのスナップショットをTiDB Cloud Dedicatedに復元する Encountered Error: 発生したエラー toml for lightning: ライトニング実行時のtomlファイル Command: 実行したコ
TiDB vs Aurora on TPC-H10 with Query Description: Foreign Keys Accelerate Massive Aggregation Queries
benchmark result: https://gist.github.com/c4pt0r/4c29c9cd387dd89fd51a84be7c6e9586https://gist.github.com/c4pt0r/4c29c9cd387dd89fd51a84be7c6e9586 This
TiDB CloudのコンソールからDDLをインポートした際に「The table 'Hoge' has some problems with the schema file: [ddl:1067]Invalid default value for 'created_at'" }. Please check the content of the schema file.」というエラーが出た
環境 実施日: 2025/03/18 TiDB: TiDB Cloud Dedicated v8.1.2 Mac OS: Sequoia 15.3.2 24D81 tiup: 1.16.1 v1.16.1nightly20 go: go1.21.13 dumpling: v8.5.1 やろうとしてい
[TiDB] TiDBのdumplingでAuroraMySQLのDDLをダンプして、TiDB Cloud Consoleからインポートするとgeometory型でバリデーションエラーが出る
やっていたこと 以下の記事を参考にAuroraMySQLのデータをTiDBに積み直していました。 前段としてAuroraMySQLのDDLをTiDBにインポートする必要があったので、dumplingというTiDBのツールでAuroraMySQLのDDLをダンプして、そのデータをTiDB Cloudの
[TiDB v8.1.2] datetime型のカラムとデフォルト値の精度が異なる場合の挙動がTiDBとMySQLで異なる。
環境情報 MySQLの環境: AuroraMySQL MySQL 8系 TiDB Cloud: v8.1.2 MySQLの挙動「datetime型のカラムとデフォルト値のNOWメソッドの精度が合っていなくてもエラーにならない」 MySQLには日付型の中にTIMESTAMPと言う型があるようですが、こ