NewSQL Landscape

NewSQL Landscape Oracle Cloud Hangout Café Season8 #4 Yutaka Ichikawa
Oracle Corporation Japan Solutions Architect May 8, 2024

Copyright © 2024, Oracle and/or its affiliates 2 Profile Name
• Yutaka Ichikawa/市川豊 Belong • Solutions Architect Role • Principal Solution Architect SNS • X/GitHub/Qiita:cyberblack28 Blog • https://cyberblack28.hatenablog.com/ Materials • https://speakerdeck.com/cyberblack28/ • https://speakerdeck.com/oracle4engineer/ Community • Oracle Cloud Hangout Cafe #ochacafe • CloudNative Days Tokyo #cndt #o11y2022 Certified • Certified Kubernetes Administrator • Certified Kubernetes Application Developer • Certified Kubernetes Security Specialist • Kubernetes and Cloud Native Associate Publications

Copyright © 2024, Oracle and/or its affiliates 3 ThinkIT +
Oracle Cloud Hangout Cafe Oracle Cloud Hangout Café ダイジェスト • 第1回「CI/CD最新事情」 2023年1月 • 第2回「マイクロサービスの認証・認可とJWT」 2023年2月 • 第3回「Kubernetes Operator 超入門」 2023年3月 • 第4回「Kubernetes のセキュリティ」 2023年4月 • 第5回「実験！カオスエンジニアリング」 2023年5月 • 第6回「Service Mesh がっつり入門！」 2023年6月第一弾公開中 • 第1回「Kubernetes 超入門」 2023年12月 • 第2回「IaC のベストプラクティス」 2023年1月 • 第3回「Kubernetes のネットワーク」 2023年2月 • 第4回「Python で作る API サーバー」 2023年3月 • 第5回「Observability 再入門」 2023年4月 • 第6回「Kubernetes のオートスケーリング」 2023年5月第二弾連載開始 https://thinkit.co.jp/series/10728 https://thinkit.co.jp/series/11131

Copyright © 2024, Oracle and/or its affiliates 4 1. What’s
NewSQL ? • NewSQL Summary • RDBMS & NoSQL • NewSQL とは？ • Raft Agenda 2. NewSQL Products • TiDB • CockroachDB • YugabyteDB 3. TiDB Demo • TiDB on Kubernetes • TiDB Scale OUT/IN by TiDB Operator • TiDB Suspend & Restore by TiDB Operator • TiDB Upgrade • TiDB Monitor & Dashboard • WordPress on OKE & TiDB Cloud 4. Appendix • Community & TiDB • 参考資料

What’s NewSQL ? Copyright © 2024, Oracle and/or its affiliates
5

Copyright © 2024, Oracle and/or its affiliates 7 What’s NewSQL
? NewSQL Summary 伝統的なリレーショナルデータベースのトランザクション整合性と SQL 標準に準拠したクエリ言語の利点を保持しつつ、 NoSQL データベースのようなスケーラビリティと分散処理の機能を備えたデータベース

Copyright © 2024, Oracle and/or its affiliates 8 RDBMS &
NoSQL

? RDBMS & NoSQL データベース（ DB : Database ）は、データの追加、読込、更新、削除、検索、分析などの処理を目的とした “蓄積された情報” 構造化データ非構造化データ構造化データを扱うリレーショナルデータベース（ RDB: Relational Database ）非構造化データを扱う NoSQL データベース ID XXXX XXXXXX 1 • ••••••• 2 ▲ ▲▲▲▲▲ 3 ▪ ▪▪▪▪▪▪▪▪ テキスト音声画像動画予め定義されたデータモデルに基づき整理されたデータ特定の形式やデータモデルに従わないデータ

? RDBMS & NoSQL リレーショナルデータベースは、複数の表（テーブル）同士を関連付けて管理するデータベース ID 名前年齢役職ID 1 田中義男 45 1 2 山田博司 24 3 3 鈴木奈緒 32 2 ID 役職 1 社長 2 課長 3 社員ユーザーテーブル役職テーブル関連付け各テーブルにある一意のキーによる、データの特定や複数のテーブルとの関連付けが可能

? RDBMS & NoSQL SQL をはじめとするデータベース言語による命令に従い、データベース上のデータに対して追加、読込、更新、削除、検索、分析処理を実施するシステムを Database Management System (DBMS) という DBMS の主な分類 RDBMS NoSQL NewSQL それぞれの特徴から NewSQL とは何かを考えて行きましょう！

? RDBMS & NoSQL その前に、前提知識としておさえておきましょう！ ACID 特性 CAP 定理拡張性

? RDBMS & NoSQL ACID 特性トランザクションにおける4つの特性分割できない一連の流れ処理トランザクション開始コミットロールバック更新内容を DB に反映更新が無かったことにする Aさんの口座から10万円減算処理 Bさんの口座に10万円加算処理異常異常 A B A さんの銀行口座から B さんの銀行口座に 10万円振り込む処理 10万円データの整合性

? RDBMS & NoSQL ACID 特性トランザクションにおける4つの特性 ACID 特性概要 Atomicity（原子性）トランザクション内の全ての処理/操作が完全に成功するか、または全く実行されないかのどちらかであることを保証。つまり「全てまたは無し」の原則。 Consistency（一貫性）データベースが一貫した状態に保たれることを保証。つまり、トランザクションの前後でデータベースの整合性ルールが守られることを意味する。 Isolation（独立性）同時に実行される複数のトランザクションがお互いに干渉しないことを保証。つまり、一つのトランザクションが完了するまで、その結果が他のトランザクションに影響を与えないこと。 Durability（永続性）トランザクションが一度完了したら、その結果はシステムの障害が発生しても失われることがないことを保証。つまり、データの安全な永続性を意味する。エラーや障害が発生しても、データベースにおけるデータの整合性と信頼性が維持される

? RDBMS & NoSQL 分散システムにおいて、一貫性、可用性、分断耐性のうち、同時に満たせるのは2つまでという定理 CAP 定理概要 Consistency（一貫性）別々のノード上に接続したどのクライアントも、同じデータを参照することを保証。 Availability（可用性） 1つ以上のノードがダウンしても、システムとして正常に動作し続けることを保証。 Partition Tolerance（分断耐性）ノード間における通信障害が起きた場合も、システムとして正常に動作し続けることを保証。 CAP 定理分散システム：複数のノードにおいて、データを同時に保管するネットワーク Consistency Availability Partitioning Tolerance CA CP AP

? RDBMS & NoSQL 拡張性スケールアウト/イン：水平スケール、ハードウェア（サーバ）機器の上下スケールアップ/ダウン：垂直スケール、ハードウェア（サーバ）性能（CPU/RAM etc.）の上下スケールアップスケールアウトメリット複数サーバ間のデータ整合性など考慮事項が少ない理論上、サーバの台数を増やせば増やすほど性能が向上するため、拡張性が高いデメリットハードウェアスペックの限界に比例して、処理能力の限界の可能性を否めない台数が増えるほど、複数サーバ間でのデータ整合性を保つ必要があり、管理における考慮やコストが増えるデータベースサーバにおけるスケールアップとスケールアウトの主なメッリト/デメリット

? RDBMS & NoSQL RDBMS 構造化データを扱うことに適したデータベースマネージメントシステムカテゴリ説明言語 SQL CAP 定理一貫性と可用性に強い（分断耐性に弱い）メリット • ACID 特性を持つトランザクションを実行による処理の一貫性やデータの整合性および信頼性を保証デメリット • 非構造データを扱うのが難しい • 垂直スケールをベースに性能向上するためハードウェアの拡張限界に影響する • スキーマ変更に対する柔軟性が低い

? RDBMS & NoSQL RDBMS 構造化データを扱うことに適したデータベースマネージメントシステム RDBMS 開発元 Oracle Database Oracle MySQL Oracle SQL Server Microsoft PostgreSQL PostgreSQL Global Development Group MariaDB MariaDB Corporation Ab, MariaDB Foundation SQLite D. Richard Hipp

? RDBMS & NoSQL NoSQL カテゴリ説明言語プロダクト独自のコマンド CAP 定理分断耐性と可用性に強い（一貫性に弱い）メリット • 多種多様な非構造データを扱うことができる • キーバリュー型 • カラム指向型 • ドキュメント指向型 • グラフ型 • 複数のサーバにまたがってスケールアウトできるため拡張性が高い • 複数のサーバで負荷を分散できることにより大量アクセスに対する高速処理を実現できるデメリット • ACID 特性を保証しない • データの型におけるチェックが弱い非構造データを扱うことを得意として、複数のサーバにデータベースを構成する（分散データベース）ことで、高い可用性、拡張性、処理性能を持つデータベースマネージメントシステム

? RDBMS & NoSQL NoSQL 非構造データを扱うことを得意として、複数のサーバにデータベースを構成する（分散データベース）ことで、高い可用性、拡張性、処理性能を持つデータベースマネージメントシステム NoSQL 開発元型 Cloud Firestore Google ドキュメント指向型 Bigtable Google カラム指向型 DynamoDB Amazon Web Service キーバリュー型 Redis Salvatore Sanfilippo キーバリュー型 Cassandra Apache Software Foundation カラム指向型、キーバリュー型 MongoDB MongoDB ドキュメント指向型 Neo4j Neo4j グラフ型

? RDB & NoSQL NoSQL RDBMS ACID 特性を重要とし、データの一貫性を担保したい場合は、RDBMS スケーラビリティ、処理性能、データに対する柔軟性を重視する場合は NoSQL DBMS 一貫性可用性分断耐性拡張性 ACID トランザクション RDBMS 〇〇 × △ 〇 NoSQL × 〇〇〇 ×

? NewSQL とは？ RDBMS と NoSQL の両方の特徴を有した RDBMS 分散性を持った RDB ライクなデータベース NewSQL カテゴリ説明言語 SQL CAP 定理一貫性と分断耐性に強く、拡張性もあるメリット以下を兼ね備えたデータベース • ACID 特性 • スケーラビリティ • SQL 対応 • 高パフォーマンス • 分散システム（耐障害性/可用性）デメリット • 分散アーキテクチャによる管理の煩雑化 • スケール可能なRDBMSがベースとなるため、非構造データの扱いには弱い • 現状では新規性があるためナレッジの少なさやコストが高くなる傾向がある

Copyright © 2024, Oracle and/or its affiliates 24 RDBMS と
NoSQL の両方の特徴を有した RDBMS 分散性を持った RDB ライクなデータベース NewSQL NewSQL 開発元概要互換性 TiDB PingCap オープンソースの分散 SQL データベースで、HTAP（Hybrid Transactional/Analytical Processing）をサポート MySQL CockroachDB CockroachLabs オープンソースであり、地理的に分散されたデータセンターでの強力な一貫性を提供 PostgreSQL YugabyteDB Yugabyte PostgreSQL との互換性を持つオープンソースの分散SQLデータベースで、高いパフォーマンスと分散処理を特徴 PostgreSQL Cloud Spanner Google Google Cloud Platform にホストされる、グローバル分散型の NewSQL データベース PostgreSQL 互換インターフェース NuoDB NuoDB Inc. （ダッソー・システムズが買収）トランザクションの一貫性を保ちながら弾力的なスケーラビリティを提供する、オープンソースでありながらも商用サポートも可能な NewSQL データベース独自 VoltDB VoltDB, Inc. 高速なデータ処理に特化したインメモリ NewSQL データベースで、リアルタイム分析を可能独自 SingleStore SingleStore, Inc. オンライントランザクション処理とリアルタイム分析を統合したプラットフォームを提供 MySQL NewSQL とは？

? NewSQL とは？ DBMS 一貫性可用性分断耐性 ACID トランザクション拡張性 RDBMS 〇〇 × ◦ △ NoSQL × 〇〇 × ◦ NewSQL ◦ △ ◦ ◦ ◦ RDBMS と NoSQL の両方の特徴を有した RDBMS 分散性を持った RDB ライクなデータベース NewSQL

? Raft NewSQL の複数ノードにおけるデータの一貫性を支えるコンセンサスアルゴリズム Raft Leader • クライアントのリクエストを処理 • Replication された Follower と通信するクラスタ内の Leader • 現在の Leader がダウンした場合、投票が行われる Candidate ( Leader 候補者) • どのノードも Candidate ( Leader 候補者) になれる • Leader になるためには Candidate になる必要がある • 過半数の票が集まれば Leader になれる • どの Candidate も過半数の票が得られなければもう一度投票 Follower • 全てのノードは、Follower ステートから開始 • ログエントリに保存する • Leader や Candidate からのリクエストに応える 3つのステート

? Raft NewSQL の複数ノードにおけるデータの一貫性を支えるコンセンサスアルゴリズム Raft ログ分散システム内における操作（コマンド）の記録エントリそのログを記録するまたは記録した行 *State Machine Replication と呼ばれる、複数ノードでも同じコマンドを同じ順番で実行したら同じ状態になるという考えに基づいている。 Raft ではこのコマンドをログと呼ぶ。 * State Machine Replication : https://en.wikipedia.org/wiki/State_machine_replication

? Raft アルゴリズム • Leader から Follower に定期的に Heartbeats を送信 • Follower は Leader から一定期間 Heartbeats を受け取らなければ Leader が停止とみなして、新しい投票を開始 (Election Timeout) • Heartbeats の実態は、空のログ追加メッセージ (AppendEntries RPC) N2 N3 N4 N5 N1 Heartbeats Leader Follower

? Raft Leader Election（リーダー選挙） • 全てのノードは Follower から開始 • 各ノードがランダムで持っている Election Timeout の期限が終了後、そのノードは Follower から Candidate となって選挙開始 • Candidate は他のノードに RequestVote というRPCをブロードキャストする • 過半数の票を集めたら Leader として選出される Leader ダウンして Election Timeout 発生 N2 が Candidate となり、各ノードに RequestVote RPC をブロードキャスト投票で過半数を得た N2 が Leader

? Raft Log Replication（ログ複製） • Leader は AppendEntries というログにエントリを追加する RPC を Follower に送信 • AppendEntries を受信した Follower は自身のログにエントリを追加やコミットを実行 • エントリにはインデックスなどの情報が含まれている N1 N2 N3 N4 N5 2 1 2 3 4 … N1 N2 N3 N4 N5 2 1 2 3 4 … 2 2 2 2 N1 N2 N3 N4 N5 2 1 2 3 4 … 2 2 2 2 N1 N2 N3 N4 N5 2 1 2 3 4 … 2 2 2 2 Leader が新しいエントリをログに追加する Leader から Follower に新しいエントリを AppendEntries RPC 送信過半数からエントリを追加の応答後、 Leader がログをコミット次の RPC を Leader から受け取ったら Follower もログをコミットする Leader Follower

? Raft Raft による分散データベースシステムにおける一貫性と耐障害性の向上 RDBMS 分散トランザクションの一貫性分散された RDBMS 間でのトランザクションの一貫性を確保し、データの整合性を保つ障害時の高可用性リーダーの故障時に迅速に新リーダーを選出し、データベースのダウンタイムを最小限に抑えてサービスの継続性を保証 NoSQL 書き込み操作の一貫性分散ノード間での書き込みの一貫性と順序が保証、データの信頼性が向上データの冗長性と耐障害性ログ複製によるデータの冗長性、単一ノードに障害が発生してもデータの損失を防いで、データベース全体の耐障害性が強化共通データ整合性の強化分散システム内でのデータの整合性が強化され、システムの信頼性と効率が向上システム管理の簡素化自動的なリーダー選出や障害回復プロセスにより、システム管理が簡素化され、運用負荷が軽減

TiDB TiDB（タイデービーと読む、「 Ti 」は Titanium の元素記号が由来かつ堅牢の意味が込められている）は、分散型のリレーショナルデータベース。スケーラビリティ：TiDB は、必要に応じてノードを追加することで、容易にスケールアウト（水平スケーリング）可能互換性：MySQL との高い互換性を持っているため、多くのアプリケーションで MySQL を TiDB に置き換えることが容易分散トランザクション：ACID トランザクションをサポートしており、分散環境でのトランザクションも安全分散ストレージ：TiKV という分散型のキー・バリューストレージを使用しており、大量のデータを高い耐障害性で管理可能 TiDB は、伝統的なリレーショナルデータベースとは異なり、大規模なデータセットや高いトラフィックを持つ環境での使用に適している。オンライントランザクション処理（OLTP）とオンライン分析処理（OLAP）の両方のワークロードを効率的にサポートするハイブリッドトランザクション/分析処理（HTAP）の特徴を備える。 TiDB の主な特徴

CockroachDB Google の Spanner に触発されて開発されたオープンソースの分散データベース。 ACID トランザクションを備えた分散キーバリューストアであり、高いレジリエンスを持つ。スケーラビリティ：水平方向スケーリングによる高い耐障害性互換性：PostgreSQL と互換性のある SQL インターフェースを提供分散トランザクション：分散環境でも ACID トランザクションを保証し、データの整合性を維持地理分散：データセンターやクラウドのネットワーク分断でも稼働し続ける強靭なデータベース P2P アーキテクチャとゴシッププロトコルにより、中央集権的な管理なしで運用が可能で、ネットワークが分断されても稼働を継続。 RDBMS の整合性と NoSQL のスケーラビリティを組み合わせ、地理的に分散された環境でのデータ管理に最適なソリューションを提供。 CockroachDB の主な特徴

yugabyteDB RDB の一貫性と NoSQL の拡張性を兼ね揃えた分散型 SQL データベース。一貫性、拡張性、高可用性を兼ね備える。スケーラビリティ：データの量に応じた水平スケールを実現互換性：PostgreSQL や Cassandra と互換性がある分散トランザクション：分散データベースでありながら、リニアライザブルな読み書き一貫性を提供地理分散：ノードを異なるリージョンに配置し、Active-Active構成のDRを実現自動データシャーディングにより負荷を分散する分散SQLデータベースでもあり、データのレプリケーションと自動フェイルオーバーで高可用性を実現。強力な一貫性とクラウドネイティブ設計を持ち、さまざまなデータモデルに対応。 yugabyteDB の主な特徴

Copyright © 2024, Oracle and/or its affiliates 37 Oracle Globally
Distributed Database

Distributed Database https://atmarkit.itmedia.co.jp/ait/articles/2310/19/news009.html Oracle ACE 渡部さんと小林さんの対談記事 Oracle ACE から見た、オープンソースのデータベースの評価小林さん • どの企業も最終的には Oracle が提唱する「コンバージドデータベース」を体現しようとしている（私見） • トランザクション、分析、ドキュメント型などビジネス要件で必要となる全要素をうまく扱う、フル機能のデータベースを実現とスケールアウト構成で支える考え方渡部さん • Oracle にも Sharding や Global Database Services という、グローバルでスケーラブルなデータベースを実現しようという機能がある • 全体で見ると同じ方向に向かっているデータベースのプロフェッショナルのお二方の対談は必見です！！

Distributed Database ハイパースケールのグローバル分散データベース分散データ管理 • データセットを複数のシャード・データベースに分散 • オンプレミスとクラウド上のさまざまなコンピュータに配置マルチモデル・データベース • グローバルにスケーラブル • マルチモデル対応で柔軟なデータ処理専用ハードウェア不要 • 特別なハードウェアやソフトウェアは不要 • SQLのフルパワーをサポートデータ主権と可用性 • データ主権要件に対応 • 低レイテンシと高可用性を実現データの一貫性とエコシステム • 強力なデータ一貫性 • 構造化データと非構造化データの両方をサポート • Oracle Databaseエコシステムを提供シャーディングをシームレスにデータ配信の自動化データのシャーディングと再シャーディングの自動化 Oracle Sharding は、データを目的のシャードに自動的に配置するため、データを手動で準備する必要はなく、時間を短縮できます。 Oracle Database 23ai https://www.oracle.com/jp/database/distributed-database/#rc30p1 ai

Distributed Database Globally Distributed Autonomous Database グローバル規模の分散データベースをマネージド型クラウドサービスとして運用を実現フルマネージドの利便性 • 使用、開発、管理が簡単なフルマネージドクラウドデータベース高性能アーキテクチャ • シェアード・ナッシングとシャード・アーキテクチャに基づく構築 • トランザクション処理と分析アプリケーションでのハイパースケール性能スケーラビリティと可用性 • 優れたスケーラビリティと高可用性を提供グローバルニーズへの対応 • データ・レジデンシー要件の満たしやすさ • グローバルに分散するユーザーのニーズに対応 Oracle Sharding Oracle Autonomous Database https://www.oracle.com/jp/autonomous-database/distributed-autonomous-database/ ※Oracle Database19c（2024/5時点）

TiDB のアーキテクチャ TiDB は、役割に応じたコンポーネントが分散されて配置されるアーキテクチャ。各コンポーネント内は、複数ノードで冗長化できる仕組みのため、耐障害性の高い構成を組める。出典 : https://docs.pingcap.com/ja/tidb/stable/tidb-architecture PD cluster : メタデータ管理データが Storage cluster のどこに配置されているかを管理したり、ホットスポット発生時にデータを分割して再配置などクラスタ全体を管理する頭脳役 Storage cluster : データ格納 • TiKV（KVS）と TiFlash (カラム型)を使用 • リージョンという単位で分散配置。 • リージョンサイズ96MiB(デフォルト)、同じデータが3つコピーされる • TiFlashは、TiKVにデータが格納されると非同期でデータがコピーされる TiDB cluster • クライアントから MySQL のインターフェースで接続を受け付け、発行された SQL を解析して Storage cluster からデータを取得して返すコンポーネント • オプティマイザの機能があり、SQL クエリの内容によって Storage cluster 内の TiKV か TiFlash のどちらからデータを取得するのがよいかを自動で判定 • 読込書き込み両方の SQL クエリを受け付けることができる

TiDB の特徴 Master Slave MySQL におけるマスターとレプリカの構成運用における課題 • マスターの冗長化 • データの肥大化に伴うシャーディング • レプリカへの遅延監視・・・ TiDB の分散アーキテクチャによるこうした課題へアプローチ

TiDB の特徴マスター冗長化の容易性 TiDB cluster のコンポーネントは、読込と書込みの SQL クエリを処理できるため、TiDB cluster のコンポーネントのノードを水平にスケールして書き込み可能なエンドポイントを容易に増やせるシャーディング不要データが肥大化するとパフォーマンスが劣化しやすくなるため、パフォーマンスを維持するためにデータをシャーディンするケースがあるシャーディングはアプリケーション側もシャーディングロジックを理解しておく必要があるため、運用負荷が増す傾向がある TiDBは、データを自動的にリージョンという単位で分割されて、Storage cluster に分散して格納この仕組みによって、シャーディング不要

TiDB の特徴効率的なスケール TiDBは、コンポーネント単位でスケールを実現できるため、効率的なスケールの運用ができる。読取/書込の性能を向上 ⇒ TiDB クラスタのコンポーネントディスク容量だけ増やす場合 ⇒ Storage cluster のコンポーネント水平スケール • レプリカを作成する場合（水平）、同スペックのハードウェアを用意する必要がある • 性能を上げる（垂直）にしても、ハードウェアによる上限があるスケールする方向は、アウトだけでなくインも可能

TiDB の特徴データの反映 Master Slave 反映 • 遅延や停止は致命的 • 反映の正常/異常の管理は必須 Storage cluster の TiKV ノードへデータを反映データの書き込み TiKV ノードが自分以外 TiKV ノードへコピー • 自身と合わせて3ノードにコピー（デフォルト） • 必要なコピー数の過半数が書き込まれると成功とみなすデータの書き込み成功 ↓ データがコピーされて配置完了

TiDB の特徴タイムトラベルクエリ TiDB では、Storage cluster における TiKV の Multi Version Concurrency Control (MVCC) により、データを追記型に保持しているので、過去データの状態を参照可能 Multi Version Concurrency Control (MVCC) 多版同時実行制御、データベースのトランザクションの同時並行性と一貫性の両方を保証する仕組み。 MySQL のストレージエンジンである InnoDB でも利用されている。 https://dev.mysql.com/doc/refman/8.0/ja/innodb-multi- versioning.html • データの更新/削除が行われても元データが変わらず、新しいタイムスタンプと共に追記 • デフォルトでは10分前までのデータを保持（保持期間は設定変更可能） • FLASHBACK を使用することで削除したテーブルやデータベースなど復元可能

TiDB ラインナップ TiDB Serverless TiDB Dedicated OSS (Self-Hosted) • マルチテナント型のフルマネージド TiDB • SLA や性能に制限あり • 従量課金 (※5 クラスタ無料) • 専用 VPC 内に構築するクラウド型のフルマネージド TiDB • ユーザ専用環境のため SLA や性能に制限なし • プラットフォームは、AWS と GCP（ 2024 年 5 月時点） • OSS で提供されている TiDB を自身で管理 • 無償利用 • エンタープライズプラン契約でサポートあり https://github.com/pingcap/tidb https://pingcap.co.jp/tidb/

TiDB の構築 tiup コマンドによる環境構築 TiDB Operator による Kubernetes 向けの環境構築 • tiup コマンドによる自動構築 • スケールアウトおよびスケールイン • コンポーネントのバージョンアップ ※各ノードに ssh できる必要がある ※ tiup コマンドでは K8s に構築できない（2024年5月） • TiDB Operator による環境構築 • スケールアウトおよびスケールイン • コンポーネントのバージョンアップ • TiDB のサスペンド/リストア • モニタリング環境

デモ環境概要図 VM.Standard.E4.Flex OCPU x 1 MEM 16GB Canonical Ubuntu 22.04 kind-control-plane kubectl v1.28.1 構築手順等 https://github.com/oracle-japan/ochacafe-s8-4 Namespace : tidb-admin Namespace : default tidb-controller-manager tidb-shceduler sample-tidb-discovery sample-tidb-pd sample-tidb-tidb sample-tidb-tikv

デモ環境概要図 VM.Standard.E4.Flex OCPU x 1 MEM 16GB Canonical Ubuntu 22.04 kind-control-plane kubectl v1.28.1 構築手順等 https://github.com/oracle-japan/ochacafe-s8-4 Namespace:default pd-sample-tidb-pd tikv-sample-tidb-tikv PV PVC PV PVC StatefulSet sample-tidb-pd sample-tidb-tidb sample-tidb-tikv

StatefulSet 補足順序保証と一意性: Pod が順番に作成され、削除されることを保証。これにより、データの整合性が保たれ、同じ識別情報で Pod を再起動できる。安定したネットワークID: 各Podに固定のネットワーク識別子が与えられ、その識別子は Pod が再デプロイされても変更されない。永続ストレージ: 各 Pod に対して永続ボリューム（永続ストレージ）を使用でき、Pod が再起動または再デプロイされてもデータが保持される。順序付き、グレースフルなローリングアップデート: アプリケーションの更新時には、StatefulSet は順序よく一つずつ Pod を更新していくため、更新中もシステムの安定性を維持可能。

Copyright © 2024, Oracle and/or its affiliates 53 TiDB on
Kubernetes

TiDB Set Up $ kubectl create -f https://raw.githubusercontent.com/pingcap/tidb-operator/v1.5.2/manifests/crd.yaml Deploy TiDB Operator $ helm repo add pingcap https://charts.pingcap.org/ Install TiDB Operator $ kubectl create namespace tidb-admin $ helm install --namespace tidb-admin tidb-operator pingcap/tidb-operator --version v1.5.2 $ kubectl get pods --namespace tidb-admin -l app.kubernetes.io/instance=tidb-operator NAME READY STATUS RESTARTS AGE tidb-controller-manager-5967c9df78-rqgrh 1/1 Running 0 14s tidb-scheduler-69c6bb7cfb-krp78 2/2 Running 0 14s

TiDB Set Up apiVersion: pingcap.com/v1alpha1 kind: TidbCluster metadata: name: sample-tidb spec: version: v7.4.0 pd: baseImage: pingcap/pd replicas: 3 requests: storage: "1Gi" config: {} tikv: baseImage: pingcap/tikv replicas: 3 requests: storage: "1Gi" config: {} tidb: baseImage: pingcap/tidb replicas: 2 config: {} service: type: ClusterIP config: {} Deploy a TiDB cluster $ kubectl apply -f sample-tidb.yaml $ kubectl get pods NAME READY STATUS RESTARTS AGE sample-tidb-discovery-f74ddf8d-hgzmz 1/1 Running 0 18m sample-tidb-pd-0 1/1 Running 1 (17m ago) 18m sample-tidb-pd-1 1/1 Running 0 18m sample-tidb-pd-2 1/1 Running 0 18m sample-tidb-tidb-0 2/2 Running 0 17m sample-tidb-tidb-1 2/2 Running 0 17m sample-tidb-tikv-0 1/1 Running 0 17m sample-tidb-tikv-1 1/1 Running 0 17m sample-tidb-tikv-2 1/1 Running 0 17m sample-tidb.yaml

TiDB Set Up MySQL Client Access $ kubectl port-forward service/sample-tidb-tidb 14000:4000 > pf14000.out & $ mysql --comments -h 127.0.0.1 -P 14000 -u root Welcome to the MySQL monitor. Commands end with ; or ¥g. Your MySQL connection id is 1805648180 Server version: 8.0.11-TiDB-v7.4.0 TiDB Server (Apache License 2.0) Community Edition, MySQL 8.0 compatible Copyright (c) 2000, 2024, Oracle and/or its affiliates. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Type 'help;' or '¥h' for help. Type '¥c' to clear the current input statement. mysql> SELECT @@VERSION; +--------------------+ | @@VERSION | +--------------------+ | 8.0.11-TiDB-v7.4.0 | +--------------------+ 1 row in set (0.00 sec) mysql> exit Bye

TiDB Scale OUT/IN by TiDB Operator apiVersion: pingcap.com/v1alpha1 kind: TidbCluster metadata: name: sample-tidb spec: version: v7.4.0 pd: baseImage: pingcap/pd replicas: 3 requests: storage: "1Gi" config: {} tikv: baseImage: pingcap/tikv replicas: 3 requests: storage: "1Gi" config: {} tidb: baseImage: pingcap/tidb replicas: 3 #2⇒3に変更 config: {} service: type: ClusterIP config: {} Scale OUT sample-tidb.yaml $ kubectl apply -f sample-tidb.yaml $ kubectl get pods NAME READY STATUS RESTARTS AGE sample-tidb-discovery-f74ddf8d-hgzmz 1/1 Running 0 47m sample-tidb-pd-0 1/1 Running 1 (46m ago) 47m sample-tidb-pd-1 1/1 Running 0 47m sample-tidb-pd-2 1/1 Running 0 47m sample-tidb-tidb-0 2/2 Running 0 46m sample-tidb-tidb-1 2/2 Running 0 46m sample-tidb-tidb-2 2/2 Running 0 26s sample-tidb-tikv-0 1/1 Running 0 46m sample-tidb-tikv-1 1/1 Running 0 46m sample-tidb-tikv-2 1/1 Running 0 46m • マニフェストの更新と適用 • kubectl patch コマンドによる適用 • kubectl edit コマンドによる適用

TiDB Scale OUT/IN by TiDB Operator Scale IN $ kubectl patch TidbCluster sample-tidb --type merge -p '{"spec":{"tidb":{"replicas":2}}}' $ kubectl get pods NAME READY STATUS RESTARTS AGE sample-tidb-discovery-f74ddf8d-hgzmz 1/1 Running 0 64m sample-tidb-pd-0 1/1 Running 1 (63m ago) 64m sample-tidb-pd-1 1/1 Running 0 64m sample-tidb-pd-2 1/1 Running 0 64m sample-tidb-tidb-0 2/2 Running 0 62m sample-tidb-tidb-1 2/2 Running 0 62m sample-tidb-tikv-0 1/1 Running 0 63m sample-tidb-tikv-1 1/1 Running 0 63m sample-tidb-tikv-2 1/1 Running 0 63m kubectl patch コマンドによるスケールイン

TiDB Suspend & Restore by TiDB Operator apiVersion: pingcap.com/v1alpha1 kind: TidbCluster metadata: name: sample-tidb spec: suspendAction: suspendStatefulSet: true #追加 version: v7.4.0 pd: baseImage: pingcap/pd replicas: 3 requests: storage: "1Gi" config: {} tikv: baseImage: pingcap/tikv replicas: 3 requests: storage: "1Gi" config: {} tidb: baseImage: pingcap/tidb replicas: 3 config: {} service: type: ClusterIP config: {} sample-tidb.yaml $ kubectl apply -f sample-tidb.yaml $ kubectl get TidbCluster sample-tidb NAME READY PD STORAGE READY DESIRE TIKV STORAGE READY DESIRE TIDB READY DESIRE AGE sample-tidb True pingcap/pd:v7.4.0 1Gi 3 3 pingcap/tikv:v7.4.0 1Gi 3 3 pingcap/tidb:v7.4.0 2 2 5m44s • マニフェストの更新と適用 • kubectl patch コマンドによる適用 • kubectl edit コマンドによる適用 $ kubectl get pods NAME READY STATUS RESTARTS AGE sample-tidb-discovery-f74ddf8d-hgzmz 1/1 Running 0 97m Suspend

TiDB Suspend & Restore by TiDB Operator Restore $ kubectl patch TidbCluster sample-tidb --type merge -p '{"spec":{"suspendAction":{"suspendStatefulSet":false}}}' $ kubectl get pods NAME READY STATUS RESTARTS AGE sample-tidb-discovery-f74ddf8d-hgzmz 1/1 Running 0 110m sample-tidb-pd-0 1/1 Running 0 7m sample-tidb-pd-1 1/1 Running 0 7m sample-tidb-pd-2 1/1 Running 0 7m sample-tidb-tidb-0 2/2 Running 0 6m30s sample-tidb-tidb-1 2/2 Running 0 6m30s sample-tidb-tikv-0 1/1 Running 0 6m47s sample-tidb-tikv-1 1/1 Running 0 6m47s sample-tidb-tikv-2 1/1 Running 0 6m47s kubectl patch コマンドによるRestore

TiDB Upgrade Current Version $ kubectl get TidbCluster sample-tidb -o jsonpath='{.spec.version}' v7.4.0 $ kubectl get TidbCluster sample-tidb NAME READY PD STORAGE READY DESIRE TIKV STORAGE READY DESIRE TIDB READY DESIRE AGE sample-tidb True pingcap/pd:v7.4.0 1Gi 3 3 pingcap/tikv:v7.4.0 1Gi 3 3 pingcap/tidb:v7.4.0 2 2 5m44s Upgrade $ kubectl patch TidbCluster sample-tidb --type=merge -p '{"spec":{"version":"v7.5.0"}}' tidbcluster.pingcap.com/sample-tidb patched Upgrade Watch $ kubectl get Tidbcluster sample-tidb NAME READY PD STORAGE READY DESIRE TIKV STORAGE READY DESIRE TIDB READY DESIRE AGE sample-tidb True pingcap/pd:v7.5.0 1Gi 3 3 pingcap/tikv:v7.5.0 1Gi 3 3 pingcap/tidb:v7.5.0 2 2 16m

apiVersion: pingcap.com/v1alpha1 kind: TidbMonitor metadata: name: tidb-monitor spec: replicas: 1 clusters: - name: sample-tidb prometheus: baseImage: prom/prometheus version: v2.27.1 grafana: baseImage: grafana/grafana version: 7.5.11 initializer: baseImage: pingcap/tidb-monitor-initializer version: v7.5.0 reloader: baseImage: pingcap/tidb-monitor-reloader version: v1.0.1 prometheusReloader: baseImage: quay.io/prometheus- operator/prometheus-config-reloader version: v0.49.0 imagePullPolicy: IfNotPresent tidb-monitor.yaml $ kubectl apply -f tidb-monitor.yaml $ kubectl port-forward svc/tidb-monitor-grafana 3000 TiDB Monitor & Dashboard TiDB Monitor (Prometheus & Grafana)

TiDB Monitor & Dashboard apiVersion: pingcap.com/v1alpha1 kind: TidbDashboard metadata: name: tidb-dashboard spec: baseImage: pingcap/tidb-dashboard version: latest clusters: - name: sample-tidb requests: storage: 10Gi tidb-dashboard.yaml $ kubectl apply -f tidb-dashboard.yaml $ kubectl port-foward svc/tidb-dashboard-tidb-dashboard-exposed 12333 TiDB Dashboard

WordPress on OKE & TiDB Cloud Pod Service https://pingcap.co.jp/tidb-cloud-serverless-pricing-details/ Free : 5 クラスタ無料

WordPress on OKE & TiDB Cloud $ kubectl create secret generic mysql-pass --from-literal=password=TiDB-CLOUD-ROOT-PASSWORD Secret apiVersion: v1 data: password: TiDB-CLOUD-ROOT-PASSWORD kind: Secret metadata: creationTimestamp: "2024-04-01T02:11:48Z" name: mysql-pass namespace: default resourceVersion: "3186" uid: 5cef3e63-e85c-42d1-81ac-07eaaaa5684a type: Opaque ドキュメント : https://pingcap.co.jp/deploy-wordpress-on-tidb-serverless/

WordPress on OKE & TiDB Cloud apiVersion: apps/v1 kind: Deployment metadata: name: wordpress labels: app: wordpress spec: selector: matchLabels: app: wordpress tier: frontend strategy: type: Recreate template: metadata: labels: app: wordpress tier: frontend spec: containers: - image: wordpress name: wordpress env: - name: WORDPRESS_DB_HOST value: <database host url>:4000 - name: WORDPRESS_DB_USER value: <username> - name: WORDPRESS_DB_PASSWORD valueFrom: secretKeyRef: name: mysql-pass key: password - name: WORDPRESS_DB_NAME value: <database name> - name: WORDPRESS_DB_CHARSET value: utf8mb4 - name: WORDPRESS_DB_COLLATE value: utf8mb4_bin - name: WORDPRESS_CONFIG_EXTRA value: "define('MYSQL_CLIENT_FLAGS', MYSQLI_CLIENT_SSL);" ports: - containerPort: 80 name: wordpress

WordPress on OKE & TiDB Cloud Service apiVersion: v1 kind: Service metadata: name: wordpress labels: app: wordpress spec: ports: - port: 80 selector: app: wordpress tier: frontend type: LoadBalancer

TiDB Cloud Native Database Meetup & TiUG https://cndata.connpass.com/ https://tiug.connpass.com/ • 3年近く TiDB を使ってきた話（さくらインターネット） • TiDB 用インラインキャッシュ Rest API を Cloudflare Workers と Momento Cache で作った話 • SQL Server から TiDB 移行 • オンプレミス MySQL から TiDB Cloud 移行 • Hbase から TiDB への移行を選んだ理由 (CyberAgent) • Data Migration と Changefeed の間 • TiDB×Dataiku で AI の世界に入門 • ぼくらのDB戦略について（STARFACTORY） • マネージド MySQL 提供に向けた挑戦 • NewSQL 談義 #TiUG #CloudNativeDB

TiDB Cloud Native Database Meetup & TiUG https://tiug.connpass.com/ • Hbase から TiDB への移行を選んだ理由 (CyberAgent) • Data Migration と Changefeed の間 • TiDB×Dataiku で AI の世界に入門 ※ Vector Serarch が有効になった TiDB Serverless private beta への申し込みが必要 LangChain / LlamaIndex 対応 2024年3月時点最新情報

TiDB 私たちはなぜ NewSQL を使うのか TiDB 選定5社が語る選定理由と活用 LT https://findy.connpass.com/event/314602/ • LT1「最近たまに見かけるTiDBってなんだ？」（PingCAP株式会社） • LT2「検証を通して見えてきたTiDBの性能特性」（LINEヤフー株式会社） • LT3「@cosmeのTiDB採用までの道のりとか」（株式会社アイスタイル） • LT4「DMMプラットフォームがTiDBを採用した背景」（合同会社DMM .com） • LT5「コロプラでの長期運用プロジェクトでMySQLからTiDB移行の検証について」（株式会社コロプラ） • LT6「長期間TiDBを使ってきた話」（さくらインターネット株式会社） #TiDB_findy

Copyright © 2024, Oracle and/or its affiliates 79 参考資料クラウドネイティブな
DB を使ってみよう！ https://speakerdeck.com/makocchi/how-to-use-tidb-with-kubernetes いまこそ NewSQL を使ってみよう https://speakerdeck.com/makocchi/lets-try-newsql-now https://docs.pingcap.com/tidb-in-kubernetes/stable/get-started Get Started with TiDB on Kubernetes https://github.com/oracle-japan/ochacafe-s8-4 Oracle Hangout Cafe Season 8 #4 NewSQL TiDB 入門 ~ TiDB と周辺ツール群 ~ https://zenn.dev/koiping/articles/f4b6579f3e6a68 Raft について簡単に調べた https://naoto0822.medium.com/raft%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6%E7%B0%A1%E5%8D% 98%E3%81%AB%E8%AA%BF%E3%81%B9%E3%81%9F-2c77dca2e298 論文翻訳: In Search of an Understandable Consensus Algorithm (Extended Version) https://hazm.at/mox/distributed-system/algorithm/transaction/raft/index.html

NewSQL Landscape

NewSQL Landscape

Video

More Decks by oracle4engineer

Other Decks in Technology

Featured

Transcript