- TiDBについて
- クイックスタート
- デプロイ
- 移行する
- 管理
- アップグレード
- 規模
- バックアップと復元
- BRツールを使用する(推奨)
- タイムゾーンの構成
- 毎日のチェックリスト
- TiFlashを管理する
- TiUPを使用してTiDBを管理する
- オンラインでConfiguration / コンフィグレーションを変更する
- オンラインの安全でない回復
- 監視と警告
- トラブルシューティング
- 性能チューニング
- システムチューニング
- ソフトウェアのチューニング
- Configuration / コンフィグレーション
- コプロセッサーキャッシュ
- SQLチューニング
- チュートリアル
- TiDBツール
- 概要
- ユースケース
- ダウンロード
- TiUP
- ドキュメントマップ
- 概要
- 用語と概念
- TiUPコンポーネントを管理する
- FAQ
- トラブルシューティングガイド
- コマンドリファレンス
- 概要
- TiUPコマンド
- TiUPクラスターコマンド
- 概要
- tiup cluster audit
- tiup cluster check
- tiup cluster clean
- tiup cluster deploy
- tiup cluster destroy
- tiup cluster disable
- tiup cluster display
- tiup cluster edit-config
- tiup cluster enable
- tiup cluster help
- tiup cluster import
- tiup cluster list
- tiup cluster patch
- tiup cluster prune
- tiup cluster reload
- tiup cluster rename
- tiup cluster replay
- tiup cluster restart
- tiup cluster scale-in
- tiup cluster scale-out
- tiup cluster start
- tiup cluster stop
- tiup cluster template
- tiup cluster upgrade
- TiUPDMコマンド
- 概要
- tiup dm audit
- tiup dm deploy
- tiup dm destroy
- tiup dm disable
- tiup dm display
- tiup dm edit-config
- tiup dm enable
- tiup dm help
- tiup dm import
- tiup dm list
- tiup dm patch
- tiup dm prune
- tiup dm reload
- tiup dm replay
- tiup dm restart
- tiup dm scale-in
- tiup dm scale-out
- tiup dm start
- tiup dm stop
- tiup dm template
- tiup dm upgrade
- TiDBクラスタートポロジリファレンス
- DMクラスタートポロジリファレンス
- ミラーリファレンスガイド
- TiUPコンポーネント
- TiDB Operator
- バックアップと復元(BR)
- TiDB Binlog
- TiDB Lightning
- TiDBデータ移行
- TiDBデータ移行について
- DMの概要
- 基本的な機能
- 高度な機能
- シャーディングされたテーブルからのデータのマージと移行
- GH-ost/PT-oscを使用するMySQLデータベースからの移行
- SQL式を使用してDMLをフィルタリングする
- DMアーキテクチャ
- ベンチマーク
- クイックスタート
- データ移行シナリオ
- デプロイ
- 管理
- ツール
- クラスターのアップグレード
- データソースを作成する
- データソースの管理
- データ移行タスクの管理
- シャーディングDDLロックを手動で処理する
- 移行するMySQLインスタンスを切り替える
- 移行するテーブルのスキーマを管理する
- アラートを処理する
- デイリーチェック
- トラブルシューティング
- 性能チューニング
- 参照
- セキュリティ
- モニタリング指標
- アラートルール
- エラーコード
- FAQ
- 用語集
- 例
- リリースノート
- TiCDC
- Dumpling
- sync-diff-inspector
- TiSpark
- 参照
- クラスターアーキテクチャ
- 主要な監視指標
- セキュリティ
- 権限
- SQL
- SQL言語の構造と構文
- SQLステートメント
ADD COLUMN
ADD INDEX
ADMIN
ADMIN CANCEL DDL
ADMIN CHECKSUM TABLE
ADMIN CHECK [TABLE|INDEX]
ADMIN SHOW DDL [JOBS|QUERIES]
ADMIN SHOW TELEMETRY
ALTER DATABASE
ALTER INDEX
ALTER INSTANCE
ALTER PLACEMENT POLICY
ALTER TABLE
ALTER USER
ANALYZE TABLE
BACKUP
BEGIN
CHANGE COLUMN
COMMIT
CHANGE DRAINER
CHANGE PUMP
CREATE [GLOBAL|SESSION] BINDING
CREATE DATABASE
CREATE INDEX
CREATE PLACEMENT POLICY
CREATE ROLE
CREATE SEQUENCE
CREATE TABLE LIKE
CREATE TABLE
CREATE USER
CREATE VIEW
DEALLOCATE
DELETE
DESC
DESCRIBE
DO
DROP [GLOBAL|SESSION] BINDING
DROP COLUMN
DROP DATABASE
DROP INDEX
DROP PLACEMENT POLICY
DROP ROLE
DROP SEQUENCE
DROP STATS
DROP TABLE
DROP USER
DROP VIEW
EXECUTE
EXPLAIN ANALYZE
EXPLAIN
FLASHBACK TABLE
FLUSH PRIVILEGES
FLUSH STATUS
FLUSH TABLES
GRANT <privileges>
GRANT <role>
INSERT
KILL [TIDB]
LOAD DATA
LOAD STATS
MODIFY COLUMN
PREPARE
RECOVER TABLE
RENAME INDEX
RENAME TABLE
REPLACE
RESTORE
REVOKE <privileges>
REVOKE <role>
ROLLBACK
SELECT
SET DEFAULT ROLE
SET [NAMES|CHARACTER SET]
SET PASSWORD
SET ROLE
SET TRANSACTION
SET [GLOBAL|SESSION] <variable>
SHOW ANALYZE STATUS
SHOW [BACKUPS|RESTORES]
SHOW [GLOBAL|SESSION] BINDINGS
SHOW BUILTINS
SHOW CHARACTER SET
SHOW COLLATION
SHOW [FULL] COLUMNS FROM
SHOW CONFIG
SHOW CREATE PLACEMENT POLICY
SHOW CREATE SEQUENCE
SHOW CREATE TABLE
SHOW CREATE USER
SHOW DATABASES
SHOW DRAINER STATUS
SHOW ENGINES
SHOW ERRORS
SHOW [FULL] FIELDS FROM
SHOW GRANTS
SHOW INDEX [FROM|IN]
SHOW INDEXES [FROM|IN]
SHOW KEYS [FROM|IN]
SHOW MASTER STATUS
SHOW PLACEMENT
SHOW PLACEMENT FOR
SHOW PLACEMENT LABELS
SHOW PLUGINS
SHOW PRIVILEGES
SHOW [FULL] PROCESSSLIST
SHOW PROFILES
SHOW PUMP STATUS
SHOW SCHEMAS
SHOW STATS_HEALTHY
SHOW STATS_HISTOGRAMS
SHOW STATS_META
SHOW STATUS
SHOW TABLE NEXT_ROW_ID
SHOW TABLE REGIONS
SHOW TABLE STATUS
SHOW [FULL] TABLES
SHOW [GLOBAL|SESSION] VARIABLES
SHOW WARNINGS
SHUTDOWN
SPLIT REGION
START TRANSACTION
TABLE
TRACE
TRUNCATE
UPDATE
USE
WITH
- データ型
- 関数と演算子
- クラスター化インデックス
- 制約
- 生成された列
- SQLモード
- テーブル属性
- トランザクション
- ガベージコレクション(GC)
- ビュー
- パーティショニング
- 一時的なテーブル
- 文字セットと照合
- SQLの配置ルール
- システムテーブル
mysql
- INFORMATION_SCHEMA
- 概要
ANALYZE_STATUS
CLIENT_ERRORS_SUMMARY_BY_HOST
CLIENT_ERRORS_SUMMARY_BY_USER
CLIENT_ERRORS_SUMMARY_GLOBAL
CHARACTER_SETS
CLUSTER_CONFIG
CLUSTER_HARDWARE
CLUSTER_INFO
CLUSTER_LOAD
CLUSTER_LOG
CLUSTER_SYSTEMINFO
COLLATIONS
COLLATION_CHARACTER_SET_APPLICABILITY
COLUMNS
DATA_LOCK_WAITS
DDL_JOBS
DEADLOCKS
ENGINES
INSPECTION_RESULT
INSPECTION_RULES
INSPECTION_SUMMARY
KEY_COLUMN_USAGE
METRICS_SUMMARY
METRICS_TABLES
PARTITIONS
PLACEMENT_RULES
PROCESSLIST
REFERENTIAL_CONSTRAINTS
SCHEMATA
SEQUENCES
SESSION_VARIABLES
SLOW_QUERY
STATISTICS
TABLES
TABLE_CONSTRAINTS
TABLE_STORAGE_STATS
TIDB_HOT_REGIONS
TIDB_HOT_REGIONS_HISTORY
TIDB_INDEXES
TIDB_SERVERS_INFO
TIDB_TRX
TIFLASH_REPLICA
TIKV_REGION_PEERS
TIKV_REGION_STATUS
TIKV_STORE_STATUS
USER_PRIVILEGES
VIEWS
METRICS_SCHEMA
- UI
- TiDBダッシュボード
- 概要
- 管理
- アクセス
- 概要ページ
- クラスター情報ページ
- Top SQL
- キービジュアライザーページ
- メトリクス関係グラフ
- SQLステートメント分析
- 遅いクエリページ
- クラスター診断
- 検索ログページ
- インスタンスプロファイリング
- セッションの管理とConfiguration / コンフィグレーション
- FAQ
- CLI
- コマンドラインフラグ
- Configuration / コンフィグレーションファイルのパラメーター
- システム変数
- ストレージエンジン
- テレメトリー
- エラーコード
- テーブルフィルター
- トポロジラベルによるレプリカのスケジュール
- よくある質問
- リリースノート
- すべてのリリース
- リリースタイムライン
- TiDBバージョニング
- v5.4
- v5.3
- v5.2
- v5.1
- v5.0
- v4.0
- v3.1
- v3.0
- v2.1
- v2.0
- v1.0
- 用語集
古いバージョンの TiDB データベース (TiDB {{ curdocVersion }}) のドキュメントを表示しています。
TiDBBinlogチュートリアル
このチュートリアルは、各コンポーネント(Placement Driver、TiKV Server、TiDB Server、Pump、およびDrainer)の単一ノードを使用して、MariaDBServerインスタンスにデータをプッシュするように設定された単純なTiDBBinlogデプロイメントから始まります。
このチュートリアルは、 TiDBアーキテクチャにある程度精通しているユーザー、すでにTiDBクラスタをセットアップしている可能性がある(必須ではない)ユーザー、およびTiDBBinlogを実際に体験したいユーザーを対象としています。このチュートリアルは、TiDB Binlogの「タイヤを蹴る」ための良い方法であり、そのアーキテクチャの概念に慣れるための良い方法です。
このチュートリアルのTiDBを展開する手順は、本番環境または開発設定でTiDBを展開するために使用しないでください。
このチュートリアルは、x86-64で最新のLinuxディストリビューションを使用していることを前提としています。このチュートリアルでは、例として、VMwareで実行されている最小限のCentOS7インストールを使用しています。既存の環境の癖に影響されないように、クリーンインストールから開始することをお勧めします。ローカル仮想化を使用したくない場合は、クラウドサービスを使用してCentOS7VMを簡単に起動できます。
TiDBBinlogの概要
TiDB Binlogは、TiDBからバイナリログデータを収集し、リアルタイムのデータバックアップとレプリケーションを提供するソリューションです。 TiDBサーバークラスタからダウンストリームプラットフォームに増分データ更新をプッシュします。
TiDB Binlogを使用して、増分バックアップを行ったり、あるTiDBクラスタから別のクラスターにデータを複製したり、Kafkaを介して選択したダウンストリームプラットフォームにTiDB更新を送信したりできます。
TiDB Binlogは、MySQLまたはMariaDBからTiDBにデータを移行する場合に特に便利です。この場合、TiDB DM(データ移行)プラットフォームを使用してMySQL / MariaDBクラスタからTiDBにデータを取得し、TiDBBinlogを使用してTiDBクラスタと同期した個別のダウンストリームMySQL/MariaDBインスタンス/クラスタ。 TiDB Binlogを使用すると、TiDBへのアプリケーショントラフィックをダウンストリームのMySQLまたはMariaDBインスタンス/クラスタにプッシュできます。これにより、ダウンタイムやデータ損失なしにアプリケーションをMySQLまたはMariaDBに簡単に戻すことができるため、TiDBへの移行のリスクが軽減されます。
詳細については、 TiDBBinlogClusterユーザーガイドを参照してください。
建築
TiDB Binlogは、ポンプとドレイナーの2つのコンポーネントで構成されています。いくつかのポンプノードがポンプクラスタを構成します。各PumpノードはTiDBサーバーインスタンスに接続し、クラスタの各TiDBサーバーインスタンスに対して行われた更新を受信します。 DrainerはPumpクラスタに接続し、受信した更新を特定のダウンストリーム宛先(Kafka、別のTiDBクラスター、MySQL / MariaDBサーバーなど)の正しい形式に変換します。
Pumpのクラスター化されたアーキテクチャにより、新しいTiDBサーバーインスタンスがTiDBクラスターに参加または離脱したり、PumpノードがPumpクラスタに参加または離脱したりしても、更新が失われることはありません。
インストール
この場合、MySQLServerの代わりにMariaDBServerを使用しています。これは、RHEL /CentOS7のデフォルトのパッケージリポジトリにMariaDBServerが含まれているためです。後で使用するために、クライアントとサーバーが必要になります。今すぐインストールしましょう:
sudo yum install -y mariadb-server
curl -L https://download.pingcap.org/tidb-latest-linux-amd64.tar.gz | tar xzf -
cd tidb-latest-linux-amd64
期待される出力:
[kolbe@localhost ~]$ curl -LO https://download.pingcap.org/tidb-latest-linux-amd64.tar.gz | tar xzf -
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 368M 100 368M 0 0 8394k 0 0:00:44 0:00:44 --:--:-- 11.1M
[kolbe@localhost ~]$ cd tidb-latest-linux-amd64
[kolbe@localhost tidb-latest-linux-amd64]$
Configuration / コンフィグレーション
次に、 tikv-server
、およびtidb-server
のそれぞれにpd-server
つのインスタンスを使用して、単純なTiDBクラスタを開始します。
以下を使用して構成ファイルにデータを入力します。
printf > pd.toml %s\\n 'log-file="pd.log"' 'data-dir="pd.data"'
printf > tikv.toml %s\\n 'log-file="tikv.log"' '[storage]' 'data-dir="tikv.data"' '[pd]' 'endpoints=["127.0.0.1:2379"]' '[rocksdb]' max-open-files=1024 '[raftdb]' max-open-files=1024
printf > pump.toml %s\\n 'log-file="pump.log"' 'data-dir="pump.data"' 'addr="127.0.0.1:8250"' 'advertise-addr="127.0.0.1:8250"' 'pd-urls="http://127.0.0.1:2379"'
printf > tidb.toml %s\\n 'store="tikv"' 'path="127.0.0.1:2379"' '[log.file]' 'filename="tidb.log"' '[binlog]' 'enable=true'
printf > drainer.toml %s\\n 'log-file="drainer.log"' '[syncer]' 'db-type="mysql"' '[syncer.to]' 'host="127.0.0.1"' 'user="root"' 'password=""' 'port=3306'
次のコマンドを使用して、構成の詳細を確認します。
for f in *.toml; do echo "$f:"; cat "$f"; echo; done
期待される出力:
drainer.toml:
log-file="drainer.log"
[syncer]
db-type="mysql"
[syncer.to]
host="127.0.0.1"
user="root"
password=""
port=3306
pd.toml:
log-file="pd.log"
data-dir="pd.data"
pump.toml:
log-file="pump.log"
data-dir="pump.data"
addr="127.0.0.1:8250"
advertise-addr="127.0.0.1:8250"
pd-urls="http://127.0.0.1:2379"
tidb.toml:
store="tikv"
path="127.0.0.1:2379"
[log.file]
filename="tidb.log"
[binlog]
enable=true
tikv.toml:
log-file="tikv.log"
[storage]
data-dir="tikv.data"
[pd]
endpoints=["127.0.0.1:2379"]
[rocksdb]
max-open-files=1024
[raftdb]
max-open-files=1024
ブートストラップ
これで、各コンポーネントを開始できます。これは特定の順序で行うのが最適です。最初に配置ドライバー(PD)、次にTiKVサーバー、次にポンプ(TiDBはバイナリログを送信するためにポンプサービスに接続する必要があるため)、最後にTiDBサーバーです。
以下を使用してすべてのサービスを開始します。
./bin/pd-server --config=pd.toml &>pd.out &
./bin/tikv-server --config=tikv.toml &>tikv.out &
./bin/pump --config=pump.toml &>pump.out &
sleep 3
./bin/tidb-server --config=tidb.toml &>tidb.out &
期待される出力:
[kolbe@localhost tidb-latest-linux-amd64]$ ./bin/pd-server --config=pd.toml &>pd.out &
[1] 20935
[kolbe@localhost tidb-latest-linux-amd64]$ ./bin/tikv-server --config=tikv.toml &>tikv.out &
[2] 20944
[kolbe@localhost tidb-latest-linux-amd64]$ ./bin/pump --config=pump.toml &>pump.out &
[3] 21050
[kolbe@localhost tidb-latest-linux-amd64]$ sleep 3
[kolbe@localhost tidb-latest-linux-amd64]$ ./bin/tidb-server --config=tidb.toml &>tidb.out &
[4] 21058
jobs
を実行すると、実行中のデーモンのリストが表示されます。
[kolbe@localhost tidb-latest-linux-amd64]$ jobs
[1] Running ./bin/pd-server --config=pd.toml &>pd.out &
[2] Running ./bin/tikv-server --config=tikv.toml &>tikv.out &
[3]- Running ./bin/pump --config=pump.toml &>pump.out &
[4]+ Running ./bin/tidb-server --config=tidb.toml &>tidb.out &
サービスの1つが開始に失敗した場合(たとえば、「 Running
」ではなく「 Exit 1
」が表示された場合)、その個々のサービスを再起動してみてください。
接続する
これで、TiDBクラスターの4つのコンポーネントすべてが実行され、MariaDB/MySQLコマンドラインクライアントを使用してポート4000でTiDBサーバーに接続できるようになります。
mysql -h 127.0.0.1 -P 4000 -u root -e 'select tidb_version()\G'
期待される出力:
[kolbe@localhost tidb-latest-linux-amd64]$ mysql -h 127.0.0.1 -P 4000 -u root -e 'select tidb_version()\G'
*************************** 1. row ***************************
tidb_version(): Release Version: v3.0.0-beta.1-154-gd5afff70c
Git Commit Hash: d5afff70cdd825d5fab125c8e52e686cc5fb9a6e
Git Branch: master
UTC Build Time: 2019-04-24 03:10:00
GoVersion: go version go1.12 linux/amd64
Race Enabled: false
TiKV Min Version: 2.1.0-alpha.1-ff3dd160846b7d1aed9079c389fc188f7f5ea13e
Check Table Before Drop: false
この時点で、TiDBクラスターが実行されており、クラスタからバイナリログを読み取り、それらをpump
としてデータディレクトリに保存しています。次のステップは、 drainer
が書き込み可能なMariaDBサーバーを起動することです。
以下を使用してdrainer
を開始します。
sudo systemctl start mariadb
./bin/drainer --config=drainer.toml &>drainer.out &
MySQLサーバーのインストールを容易にするオペレーティングシステムを使用している場合は、それでも問題ありません。ポート3306でリッスンしていることと、空のパスワードを使用してユーザー「root」として接続できること、または必要に応じてdrainer.tomlを調整できることを確認してください。
mysql -h 127.0.0.1 -P 3306 -u root
show databases;
期待される出力:
[kolbe@localhost ~]$ mysql -h 127.0.0.1 -P 3306 -u root
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 20
Server version: 5.5.60-MariaDB MariaDB Server
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| test |
| tidb_binlog |
+--------------------+
5 rows in set (0.01 sec)
ここでは、TiDBクラスタからのバイナリログが適用された時点までを記録するためにdrainer
が使用するcheckpoint
のテーブルを含むtidb_binlog
のデータベースをすでに確認できます。
MariaDB [tidb_binlog]> use tidb_binlog;
Database changed
MariaDB [tidb_binlog]> select * from checkpoint;
+---------------------+---------------------------------------------+
| clusterID | checkPoint |
+---------------------+---------------------------------------------+
| 6678715361817107733 | {"commitTS":407637466476445697,"ts-map":{}} |
+---------------------+---------------------------------------------+
1 row in set (0.00 sec)
次に、TiDBサーバーへの別のクライアント接続を開いて、テーブルを作成し、そこにいくつかの行を挿入できるようにします。 (複数のクライアントを同時に開いたままにできるように、GNU画面でこれを行うことをお勧めします。)
mysql -h 127.0.0.1 -P 4000 --prompt='TiDB [\d]> ' -u root
create database tidbtest;
use tidbtest;
create table t1 (id int unsigned not null AUTO_INCREMENT primary key);
insert into t1 () values (),(),(),(),();
select * from t1;
期待される出力:
TiDB [(none)]> create database tidbtest;
Query OK, 0 rows affected (0.12 sec)
TiDB [(none)]> use tidbtest;
Database changed
TiDB [tidbtest]> create table t1 (id int unsigned not null AUTO_INCREMENT primary key);
Query OK, 0 rows affected (0.11 sec)
TiDB [tidbtest]> insert into t1 () values (),(),(),(),();
Query OK, 5 rows affected (0.01 sec)
Records: 5 Duplicates: 0 Warnings: 0
TiDB [tidbtest]> select * from t1;
+----+
| id |
+----+
| 1 |
| 2 |
| 3 |
| 4 |
| 5 |
+----+
5 rows in set (0.00 sec)
MariaDBクライアントに戻ると、新しいデータベース、新しいテーブル、および新しく挿入された行が見つかります。
use tidbtest;
show tables;
select * from t1;
期待される出力:
MariaDB [(none)]> use tidbtest;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
MariaDB [tidbtest]> show tables;
+--------------------+
| Tables_in_tidbtest |
+--------------------+
| t1 |
+--------------------+
1 row in set (0.00 sec)
MariaDB [tidbtest]> select * from t1;
+----+
| id |
+----+
| 1 |
| 2 |
| 3 |
| 4 |
| 5 |
+----+
5 rows in set (0.00 sec)
MariaDBサーバーにクエリを実行するときにTiDBに挿入したのと同じ行が表示されます。おめでとう! TiDBBinlogを設定しました。
binlogctl
クラスタに参加したポンプとドレイナーに関する情報は、PDに保存されます。 binlogctlツールクエリを使用して、それらの状態に関する情報を操作できます。詳細については、 binlogctlガイドを参照してください。
binlogctl
を使用して、クラスタのポンプとドレイナーの現在のステータスを表示します。
./bin/binlogctl -cmd drainers
./bin/binlogctl -cmd pumps
期待される出力:
[kolbe@localhost tidb-latest-linux-amd64]$ ./bin/binlogctl -cmd drainers
[2019/04/11 17:44:10.861 -04:00] [INFO] [nodes.go:47] ["query node"] [type=drainer] [node="{NodeID: localhost.localdomain:8249, Addr: 192.168.236.128:8249, State: online, MaxCommitTS: 407638907719778305, UpdateTime: 2019-04-11 17:44:10 -0400 EDT}"]
[kolbe@localhost tidb-latest-linux-amd64]$ ./bin/binlogctl -cmd pumps
[2019/04/11 17:44:13.904 -04:00] [INFO] [nodes.go:47] ["query node"] [type=pump] [node="{NodeID: localhost.localdomain:8250, Addr: 192.168.236.128:8250, State: online, MaxCommitTS: 407638914024079361, UpdateTime: 2019-04-11 17:44:13 -0400 EDT}"]
Drainerを強制終了すると、クラスタはそれを「一時停止」状態にします。これは、クラスタがDrainerが再び参加することを期待していることを意味します。
pkill drainer
./bin/binlogctl -cmd drainers
期待される出力:
[kolbe@localhost tidb-latest-linux-amd64]$ pkill drainer
[kolbe@localhost tidb-latest-linux-amd64]$ ./bin/binlogctl -cmd drainers
[2019/04/11 17:44:22.640 -04:00] [INFO] [nodes.go:47] ["query node"] [type=drainer] [node="{NodeID: localhost.localdomain:8249, Addr: 192.168.236.128:8249, State: paused, MaxCommitTS: 407638915597467649, UpdateTime: 2019-04-11 17:44:18 -0400 EDT}"]
「NodeIDs」をbinlogctl
とすると、個々のノードを制御できます。この場合、ドレイナーのNodeIDは「localhost.localdomain:8249」であり、ポンプのNodeIDは「localhost.localdomain:8250」です。
このチュートリアルでのbinlogctl
の主な使用法は、クラスタの再起動の場合である可能性があります。 TiDBクラスタのすべてのプロセスを終了して再起動しようとすると(ダウンストリームのMySQL / MariaDBサーバーまたはDrainerを除く)、PumpはDrainerに接続できず、Drainerがまだ「オンライン」であると信じているため、起動を拒否します。
この問題には3つの解決策があります。
プロセスを強制終了する代わりに、
binlogctl
を使用してDrainerを停止します。./bin/binlogctl --pd-urls=http://127.0.0.1:2379 --cmd=drainers ./bin/binlogctl --pd-urls=http://127.0.0.1:2379 --cmd=offline-drainer --node-id=localhost.localdomain:8249
ポンプを始動する前にドレイナーを始動してください。
PDを開始した後(ただし、ドレイナーとポンプを開始する前)に
binlogctl
を使用して、一時停止したドレイナーの状態を更新します。./bin/binlogctl --pd-urls=http://127.0.0.1:2379 --cmd=update-drainer --node-id=localhost.localdomain:8249 --state=offline
掃除
TiDBクラスタおよびTiDBBinlogプロセスを停止するには、クラスタを形成するすべてのプロセス(pd-server、tikv-server、pump、tidb-server、drainer)を開始したシェルでpkill -P $$
を実行できます。各コンポーネントをクリーンにシャットダウンするのに十分な時間を与えるには、特定の順序でコンポーネントを停止すると便利です。
for p in tidb-server drainer pump tikv-server pd-server; do pkill "$p"; sleep 1; done
期待される出力:
kolbe@localhost tidb-latest-linux-amd64]$ for p in tidb-server drainer pump tikv-server pd-server; do pkill "$p"; sleep 1; done
[4]- Done ./bin/tidb-server --config=tidb.toml &>tidb.out
[5]+ Done ./bin/drainer --config=drainer.toml &>drainer.out
[3]+ Done ./bin/pump --config=pump.toml &>pump.out
[2]+ Done ./bin/tikv-server --config=tikv.toml &>tikv.out
[1]+ Done ./bin/pd-server --config=pd.toml &>pd.out
すべてのサービスが終了した後にクラスタを再始動する場合は、最初に実行したのと同じコマンドを使用してサービスを開始します。上記のbinlogctl
セクションで説明したように、 pump
の前にdrainer
を開始し、 tidb-server
の前にpump
を開始する必要があります。
./bin/pd-server --config=pd.toml &>pd.out &
./bin/tikv-server --config=tikv.toml &>tikv.out &
./bin/drainer --config=drainer.toml &>drainer.out &
sleep 3
./bin/pump --config=pump.toml &>pump.out &
sleep 3
./bin/tidb-server --config=tidb.toml &>tidb.out &
コンポーネントのいずれかが起動に失敗した場合は、失敗した個々のコンポーネントを再起動してみてください。
結論
このチュートリアルでは、単一のポンプと単一のドレイナーを備えたクラスタを使用して、TiDBクラスタからダウンストリームのMariaDBサーバーに複製するようにTiDBBinlogを設定しました。これまで見てきたように、TiDB Binlogは、TiDBクラスタへの変更をキャプチャして処理するための包括的なプラットフォームです。
より堅牢な開発、テスト、または本番デプロイメントでは、高可用性とスケーリングの目的で複数のTiDBサーバーを使用し、複数のPumpインスタンスを使用して、TiDBサーバーインスタンスへのアプリケーショントラフィックがPumpの問題の影響を受けないようにします。クラスタ。追加のDrainerインスタンスを使用して、更新をさまざまなダウンストリームプラットフォームにプッシュしたり、増分バックアップを実装したりすることもできます。