重要

このページは英語版のページを機械翻訳しています。原文はこちらからご覧ください。

アップグレードおよびアップグレード後の FAQ

このドキュメントでは、TiDB のアップグレード時またはアップグレード後に、いくつかの FAQ とその解決方法を紹介します。

アップグレードに関するよくある質問

このセクションでは、TiDB をアップグレードする際のいくつかの FAQ とその解決方法をリストします。

ローリング更新の影響は何ですか?

ローリングアップデートを TiDB サービスに適用すると、実行中のアプリケーションはさまざまな程度の影響を受けます。したがって、ビジネスのピーク時にローリング更新を実行することはお勧めしません。最小のクラスタートポロジ (TiDB 2、PD 3、TiKV * 3) を構成する必要があります。 PumpまたはDrainerサービスがクラスターに含まれている場合は、ローリング更新の前にDrainerを停止することをお勧めします。 TiDB をアップグレードすると、 Pumpもアップグレードされます。

DDL の実行中に TiDB クラスターをアップグレードできますか?

DDL ステートメントがクラスターで実行されているときは、TiDB クラスターをアップグレードしないでください(通常、 ADD INDEXのような時間のかかる DDL ステートメントや列の型の変更のため)。

アップグレードの前に、 ADMIN SHOW DDLコマンドを使用して、TiDB クラスターに進行中の DDL ジョブがあるかどうかを確認することをお勧めします。クラスターに DDL ジョブがある場合、クラスターをアップグレードするには、DDL の実行が完了するまで待つか、 ADMIN CANCEL DDLコマンドを使用して DDL ジョブをキャンセルしてからクラスターをアップグレードします。

また、クラスターのアップグレード中は、DDL ステートメントを実行しないでください。そうしないと、未定義の動作の問題が発生する可能性があります。

バイナリを使用して TiDB をアップグレードするには?

バイナリを使用して TiDB をアップグレードすることはお勧めしません。代わりに、バージョンの一貫性と互換性の両方を保証するTiUPを使用して TiDB をアップグレードするまたはKubernetes で TiDB クラスターをアップグレードするにすることをお勧めします。

アップグレード後のよくある質問

このセクションでは、TiDB をアップグレードした後のいくつかの FAQ とその解決策をリストします。

DDL 操作の実行時の文字セット (charset) エラー

v2.1.0 以前のバージョン (v2.0 のすべてのバージョンを含む) では、TiDB の文字セットはデフォルトで UTF-8 です。ただし、v2.1.1 から、デフォルトの文字セットが UTF8MB4 に変更されました。

v2.1.0 以前のバージョンで新しく作成されたテーブルの文字セットを UTF-8 として明示的に指定すると、TiDB を v2.1.1 にアップグレードした後に DDL 操作の実行に失敗する可能性があります。

この問題を回避するには、次のことに注意する必要があります。

v2.1.3 より前では、TiDB は列の文字セットの変更をサポートしていません。したがって、DDL 操作を実行するときは、新しい列の文字セットが元の列の文字セットと一致していることを確認する必要があります。
v2.1.3 より前では、列の文字セットがテーブルの文字セットと異なっていても、 show create tableは列の文字セットを示しません。ただし、次の例に示すように、HTTP API を介してテーブルのメタデータを取得することで表示できます。

`unsupported modify column charset utf8mb4 not match origin utf8`

v2.1.0以前のバージョンでは、バージョンアップ前に以下の操作を実施しています。

create table t(a varchar(10)) charset=utf8;

Query OK, 0 rows affected
Time: 0.106s

show create table t;

+-------+-------------------------------------------------------+
| Table | Create Table                                          |
+-------+-------------------------------------------------------+
| t     | CREATE TABLE `t` (                                    |
|       |   `a` varchar(10) DEFAULT NULL                        |
|       | ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin |
+-------+-------------------------------------------------------+
1 row in set
Time: 0.006s

アップグレード後、v2.1.1 および v2.1.2 では以下のエラーが報告されていますが、v2.1.3 以降ではそのようなエラーは発生していません。
```
alter table t change column a a varchar(20);
```
```
ERROR 1105 (HY000): unsupported modify column charset utf8mb4 not match origin utf8
```

解決：

元の文字セットと同じように、列の文字セットを明示的に指定できます。

alter table t change column a a varchar(22) character set utf8;

ポイント 1 によると、列の文字セットを指定しない場合、デフォルトで UTF8MB4 が使用されるため、元の列の文字セットと一致するように列の文字セットを指定する必要があります。

ポイント 2 に従って、HTTP API を介してテーブルのメタデータを取得し、列名とキーワード「Charset」を検索することで列の charset を見つけることができます。

curl "http://$IP:10080/schema/test/t" | python -m json.tool

ここでは Python ツールを使用して JSON をフォーマットしますが、これは必須ではなく、コメントを追加するためだけに便利です。

{
    "ShardRowIDBits": 0,
    "auto_inc_id": 0,
    "charset": "utf8",   # The charset of the table.
    "collate": "",
    "cols": [            # The relevant information about the columns.
        {
            ...
            "id": 1,
            "name": {
                "L": "a",
                "O": "a"   # The column name.
            },
            "offset": 0,
            "origin_default": null,
            "state": 5,
            "type": {
                "Charset": "utf8",   # The charset of column a.
                "Collate": "utf8_bin",
                "Decimal": 0,
                "Elems": null,
                "Flag": 0,
                "Flen": 10,
                "Tp": 15
            }
        }
    ],
    ...
}

`unsupported modify charset from utf8mb4 to utf8`

アップグレード前に、v2.1.1 と v2.1.2 で以下の操作を実行します。

create table t(a varchar(10)) charset=utf8;

Query OK, 0 rows affected
Time: 0.109s

show create table t;

+-------+-------------------------------------------------------+
| Table | Create Table                                          |
+-------+-------------------------------------------------------+
| t     | CREATE TABLE `t` (                                    |
|       |   `a` varchar(10) DEFAULT NULL                        |
|       | ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin |
+-------+-------------------------------------------------------+

上記の例では、 show create tableテーブルの文字セットのみを示していますが、実際には列の文字セットは UTF8MB4 であり、HTTP API を介してスキーマを取得することで確認できます。ただし、新しいテーブルが作成された場合、列の文字セットはテーブルの文字セットと一致している必要があります。このバグは v2.1.3 で修正されています。

バージョンアップ後、v2.1.3以降では以下の操作を行います。

show create table t;

+-------+--------------------------------------------------------------------+
| Table | Create Table                                                       |
+-------+--------------------------------------------------------------------+
| t     | CREATE TABLE `t` (                                                 |
|       |   `a` varchar(10) CHARSET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL |
|       | ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin              |
+-------+--------------------------------------------------------------------+
1 row in set
Time: 0.007s

alter table t change column a a varchar(20);

ERROR 1105 (HY000): unsupported modify charset from utf8mb4 to utf8

解決：

v2.1.3 以降、TiDB は列とテーブルの文字セットの変更をサポートしているため、テーブルの文字セットを UTF8MB4 に変更することをお勧めします。
```
alter table t convert to character set utf8mb4;
```
問題 1 で行ったように、列の文字セットを指定して、元の列の文字セット (UTF8MB4) との一貫性を保つこともできます。
```
alter table t change column a a varchar(20) character set utf8mb4;
```

`ERROR 1366 (HY000): incorrect utf8 value f09f8c80(🌀) for column a`

TiDB v2.1.1 以前のバージョンでは、文字セットが UTF-8 の場合、挿入された 4 バイトデータに対する UTF-8 Unicode エンコーディングチェックは行われません。ただし、v2.1.2 以降のバージョンでは、このチェックが追加されています。

v2.1.1以前のバージョンでは、バージョンアップ前に以下の操作を実施しています。

create table t(a varchar(100) charset utf8);

Query OK, 0 rows affected

insert t values (unhex('f09f8c80'));

Query OK, 1 row affected

アップグレード後、v2.1.2 以降のバージョンで次のエラーが報告されます。

insert t values (unhex('f09f8c80'));

ERROR 1366 (HY000): incorrect utf8 value f09f8c80(🌀) for column a

解決：

v2.1.2: このバージョンは列の文字セットの変更をサポートしていないため、UTF-8 チェックをスキップする必要があります。
```
set @@session.tidb_skip_utf8_check=1;
```
```
Query OK, 0 rows affected
```
```
insert t values (unhex('f09f8c80'));
```
```
Query OK, 1 row affected
```
v2.1.3 以降のバージョンでは、列の文字セットを UTF8MB4 に変更することをお勧めします。または、 tidb_skip_utf8_checkを設定して UTF-8 チェックをスキップすることもできます。ただし、チェックをスキップすると、MySQL がチェックを実行するため、TiDB から MySQL へのデータの複製に失敗する可能性があります。
```
alter table t change column a a varchar(100) character set utf8mb4;
```
```
Query OK, 0 rows affected
```
```
insert t values (unhex('f09f8c80'));
```
```
Query OK, 1 row affected
```
具体的には、変数tidb_skip_utf8_checkを使用して、データに対する有効な UTF-8 および UTF8MB4 チェックをスキップできます。ただし、チェックをスキップすると、MySQL がチェックを実行するため、TiDB から MySQL へのデータの複製に失敗する可能性があります。
UTF-8 チェックのみをスキップする場合は、 tidb_check_mb4_value_in_utf8を設定できます。この変数は v2.1.3 でconfig.tomlファイルに追加され、構成ファイルでcheck-mb4-value-in-utf8を変更してから、クラスターを再起動して有効にすることができます。
v2.1.5 以降では、HTTP API とセッション変数を使用してtidb_check_mb4_value_in_utf8を設定できます。
- HTTP API（HTTP API は 1 つのサーバーでのみ有効にできます）
  - HTTP API を有効にするには:
```
curl -X POST -d "check_mb4_value_in_utf8=1" http://{TiDBIP}:10080/settings
```
  - HTTP API を無効にするには:
```
curl -X POST -d "check_mb4_value_in_utf8=0" http://{TiDBIP}:10080/settings
```
- セッション変数
  - セッション変数を有効にするには:
```
set @@session.tidb_check_mb4_value_in_utf8 = 1;
```
  - セッション変数を無効にするには:
```
set @@session.tidb_check_mb4_value_in_utf8 = 0;
```