重要

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

TiDB 環境とシステムコンフィグレーションのチェック

このドキュメントでは、TiDB をデプロイする前の環境チェック操作について説明します。次の手順は優先順位に従っています。

TiKVを展開するターゲットマシンにオプション付きでデータディスクのext4ファイルシステムをマウントする

本番稼働環境では、TiKV データの保存に EXT4 ファイルシステムの NVMe SSD を使用することをお勧めします。この構成はベストプラクティスであり、その信頼性、セキュリティ、安定性は多数のオンラインシナリオで実証されています。

rootユーザーアカウントを使用してターゲットマシンにログインします。

データディスクを ext4 ファイルシステムにフォーマットし、ファイルシステムにnodelallocおよびnoatime nodelallocオプションを追加します。5 オプションを追加する必要があります。そうしないと、 TiUPデプロイメントは事前チェックに合格できません。7 noatimeはオプションです。

注記：
データディスクが ext4 にフォーマットされ、マウントオプションが追加されている場合は、 umount /dev/nvme0n1p1コマンドを実行してアンインストールし、以下の 5 番目の手順に直接進んで/etc/fstabファイルを編集し、オプションをファイルシステムに再度追加できます。

/dev/nvme0n1データディスクを例に挙げます。

データディスクをビュー。

fdisk -l

Disk /dev/nvme0n1: 1000 GB

パーティションを作成します。
```
parted -s -a optimal /dev/nvme0n1 mklabel gpt -- mkpart primary ext4 1 -1
```
注記：
パーティションのデバイス番号を表示するには、 lsblkコマンドを使用します。NVMe ディスクの場合、生成されるデバイス番号は通常nvme0n1p1です。通常のディスク (たとえば、 /dev/sdb ) の場合、生成されるデバイス番号は通常sdb1です。
データディスクを ext4 ファイルシステムにフォーマットします。
```
mkfs.ext4 /dev/nvme0n1p1
```

データディスクのパーティション UUIDをビュー。

この例では、nvme0n1p1 の UUID はc51eb23b-195c-4061-92a9-3fad812cc12fです。

lsblk -f

NAME    FSTYPE LABEL UUID                                 MOUNTPOINT
sda
├─sda1  ext4         237b634b-a565-477b-8371-6dff0c41f5ab /boot
├─sda2  swap         f414c5c0-f823-4bb1-8fdf-e531173a72ed
└─sda3  ext4         547909c1-398d-4696-94c6-03e43e317b60 /
sr0
nvme0n1
└─nvme0n1p1 ext4         c51eb23b-195c-4061-92a9-3fad812cc12f

/etc/fstabファイルを編集し、 nodelallocマウントオプションを追加します。

vi /etc/fstab

UUID=c51eb23b-195c-4061-92a9-3fad812cc12f /data1 ext4 defaults,nodelalloc,noatime 0 2

データディスクをマウントします。
```
mkdir /data1 && \
mount -a
```
次のコマンドを使用して確認します。
```
mount -t ext4
```
```
/dev/nvme0n1p1 on /data1 type ext4 (rw,noatime,nodelalloc,data=ordered)
```
ファイルシステムが ext4 であり、マウントオプションにnodelalloc含まれている場合、ターゲットマシンにオプションを使用してデータディスク ext4 ファイルシステムを正常にマウントしています。

システムスワップをチェックして無効にする

TiDB の動作には十分なメモリ領域が必要です。メモリが不足している場合、スワップをバッファとして使用するとパフォーマンスが低下する可能性があります。そのため、次のコマンドを実行してシステムスワップを永続的に無効にすることをお勧めします。

echo "vm.swappiness = 0">> /etc/sysctl.conf
swapoff -a && swapon -a
sysctl -p

注記：
swapoff -aを実行してからswapon -a実行すると、データをメモリにダンプし、スワップをクリーンアップしてスワップを更新します。swappiness の変更を削除してswapoff -aのみを実行すると、システムを再起動した後にスワップが再び有効になります。
sysctl -p 、システムを再起動せずに設定を有効にします。

TiDBインスタンスの一時スペースを設定する（推奨）

TiDB の一部の操作では、 rootファイルをサーバーに書き込む必要があるため、TiDB を実行するオペレーティングシステムユーザーに、ターゲットディレクトリの読み取りと書き込みを行うための十分な権限があることを確認する必要があります。1 権限で TiDB インスタンスを起動しない場合は、ディレクトリの権限を確認し、正しく設定する必要があります。

TiDB 作業領域
ハッシュテーブルの構築やソートなど、大量のメモリを消費する操作では、メモリ消費量を削減し、安定性を向上させるために、一時データをディスクに書き込むことがあります。書き込み先のディスクの場所は、構成項目tmp-storage-pathによって定義されます。デフォルト構成では、TiDB を実行するユーザーに、オペレーティングシステムの一時フォルダー (通常は/tmp ) に対する読み取りおよび書き込み権限があることを確認してください。
Fast Online DDL作業エリア
変数tidb_ddl_enable_fast_reorgがON (v6.5.0 以降のバージョンではデフォルト値) に設定されている場合、 Fast Online DDLが有効になり、一部の DDL 操作ではファイルシステム内の一時ファイルの読み取りと書き込みが必要になります。場所は構成項目temp-dirによって定義されます。TiDB を実行するユーザーには、オペレーティングシステムのそのディレクトリに対する読み取りおよび書き込み権限があることを確認する必要があります。デフォルトのディレクトリ/tmp/tidbを例に挙げます。
注記：
アプリケーション内に大きなオブジェクトに対する DDL 操作が存在する場合は、 temp-dir用に独立した大きなファイルシステムを構成することを強くお勧めします。
```
sudo mkdir /tmp/tidb
```
/tmp/tidbディレクトリがすでに存在する場合は、書き込み権限が付与されていることを確認してください。
```
sudo chmod -R 777 /tmp/tidb
```
注記：
ディレクトリが存在しない場合は、TiDB は起動時に自動的に作成します。ディレクトリの作成に失敗した場合、または TiDB にそのディレクトリの読み取りおよび書き込み権限がない場合は、実行時に予期しない問題Fast Online DDL発生する可能性があります。

対象マシンのファイアウォールサービスをチェックして停止する

TiDB クラスターでは、読み取りおよび書き込み要求やデータハートビートなどの情報の送信を確実にするために、ノード間のアクセスポートが開いている必要があります。一般的なオンラインシナリオでは、データベースとアプリケーションサービス間、およびデータベースノード間のデータインタラクションはすべて、安全なネットワーク内で行われます。したがって、特別なセキュリティ要件がない場合は、ターゲットマシンのファイアウォールを停止することをお勧めします。それ以外の場合は、ポートの使用を参照して、必要なポート情報をファイアウォールサービスの許可リストに追加します。

このセクションの残りの部分では、ターゲットマシンのファイアウォールサービスを停止する方法について説明します。

ファイアウォールの状態を確認します。CentOS Linux リリース 7.7.1908 (Core) を例に挙げます。
```
sudo firewall-cmd --state
sudo systemctl status firewalld.service
```
ファイアウォールサービスを停止します。
```
sudo systemctl stop firewalld.service
```
ファイアウォールサービスの自動起動を無効にします。
```
sudo systemctl disable firewalld.service
```
ファイアウォールの状態を確認します。
```
sudo systemctl status firewalld.service
```

NTPサービスを確認してインストールする

TiDB は、 ACIDモデルでのトランザクションの線形一貫性を保証するためにノード間のクロック同期を必要とする分散データベースシステムです。

現在、クロック同期の一般的なソリューションは、ネットワークタイムプロトコル (NTP) サービスを使用することです。インターネット上のpool.ntp.orgタイミングサービスを使用することも、オフライン環境で独自の NTP サービスを構築することもできます。

NTP サービスがインストールされ、NTPサーバーと正常に同期しているかどうかを確認するには、次の手順を実行します。

次のコマンドを実行します。 runningが返された場合、NTP サービスは実行されています。
```
sudo systemctl status ntpd.service
```
```
ntpd.service - Network Time Service
Loaded: loaded (/usr/lib/systemd/system/ntpd.service; disabled; vendor preset: disabled)
Active: active (running) since 一 2017-12-18 13:13:19 CST; 3s ago
```
- Unit ntpd.service could not be found.が返された場合は、次のコマンドを試して、システムが NTP とのクロック同期を実行するためにntpdではなくchronyd使用するように設定されているかどうかを確認します。
```
sudo systemctl status chronyd.service
```
```
chronyd.service - NTP client/server
Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2021-04-05 09:55:29 EDT; 3 days ago
```
  結果にchronydもntpd設定されていないと表示された場合は、どちらもシステムにインストールされていないことを意味します。まずchronydまたはntpdをインストールし、自動的に起動できることを確認してください。デフォルトではntpdが使用されます。
  システムがchronyd使用するように構成されている場合は、手順 3 に進みます。
ntpstatコマンドを実行して、NTP サービスが NTPサーバーと同期しているかどうかを確認します。
注記：
Ubuntu システムの場合は、 ntpstatパッケージをインストールする必要があります。
```
ntpstat
```
- synchronised to NTP serverが返された場合 (NTPサーバーと同期中)、同期プロセスは正常です。
```
synchronised to NTP server (85.199.214.101) at stratum 2
time correct to within 91 ms
polling server every 1024 s
```
- 次の状況は、NTP サービスが正常に同期していないことを示しています。
```
unsynchronised
```
- 次の状況は、NTP サービスが正常に実行されていないことを示しています。
```
Unable to talk to NTP daemon. Is it running?
```

chronyc trackingコマンドを実行して、Chrony サービスが NTPサーバーと同期しているかどうかを確認します。

注記：
これは、NTPd ではなく Chrony を使用するシステムにのみ適用されます。

chronyc tracking

コマンドがLeap status : Normalを返す場合、同期プロセスは正常です。

Reference ID    : 5EC69F0A (ntp1.time.nl)
Stratum         : 2
Ref time (UTC)  : Thu May 20 15:19:08 2021
System time     : 0.000022151 seconds slow of NTP time
Last offset     : -0.000041040 seconds
RMS offset      : 0.000053422 seconds
Frequency       : 2.286 ppm slow
Residual freq   : -0.000 ppm
Skew            : 0.012 ppm
Root delay      : 0.012706812 seconds
Root dispersion : 0.000430042 seconds
Update interval : 1029.8 seconds
Leap status     : Normal

コマンドが次の結果を返す場合、同期でエラーが発生しています。
```
Leap status    : Not synchronised
```
コマンドが次の結果を返す場合、 chronydサービスは正常に実行されていません。
```
506 Cannot talk to daemon
```

NTP サービスの同期をできるだけ早く開始するには、次のコマンドを実行します。1 pool.ntp.org NTPサーバーに置き換えます。

sudo systemctl stop ntpd.service && \
sudo ntpdate pool.ntp.org && \
sudo systemctl start ntpd.service

CentOS 7 システムに NTP サービスを手動でインストールするには、次のコマンドを実行します。

sudo yum install ntp ntpdate && \
sudo systemctl start ntpd.service && \
sudo systemctl enable ntpd.service

オペレーティングシステムの最適なパラメータを確認して構成する

本番環境の TiDB の場合、次の方法でオペレーティングシステム構成を最適化することをお勧めします。

THP (Transparent Huge Pages) を無効にします。データベースのメモリアクセスパターンは、連続的ではなく、散在的になる傾向があります。高レベルのメモリの断片化が深刻な場合、THP ページが割り当てられると、レイテンシーが高くなります。
storageメディアの I/O スケジューラをnoopに設定します。高速 SSDstorageメディアの場合、カーネルの I/O スケジューリング操作によってパフォーマンスが低下する可能性があります。スケジューラをnoopに設定すると、カーネルが他の操作なしでハードウェアに I/O 要求を直接送信するため、パフォーマンスが向上します。また、noop スケジューラの適用性も向上します。
CPU 周波数を制御する cpufrequ モジュールのperformanceモードを選択します。CPU 周波数が動的な調整なしでサポートされている最高の動作周波数に固定されている場合、パフォーマンスが最大化されます。

現在のオペレーティングシステムの構成を確認し、最適なパラメータを構成するには、次の手順を実行します。

THP が有効か無効かを確認するには、次のコマンドを実行します。
```
cat /sys/kernel/mm/transparent_hugepage/enabled
```
```
[always] madvise never
```
注記：
[always] madvise never出力された場合、THP が有効になっています。無効にする必要があります。
次のコマンドを実行して、データディレクトリが配置されているディスクの I/O スケジューラを確認します。sdb ディスクと sdc ディスクの両方にデータディレクトリを作成するものとします。
```
cat /sys/block/sd[bc]/queue/scheduler
```
```
noop [deadline] cfq
noop [deadline] cfq
```
注記：
noop [deadline] cfq出力された場合、ディスクの I/O スケジューラはdeadlineモードになっています。これをnoopに変更する必要があります。
ディスクのID_SERIAL表示するには、次のコマンドを実行します。
```
udevadm info --name=/dev/sdb | grep ID_SERIAL
```
```
E: ID_SERIAL=36d0946606d79f90025f3e09a0c1f9e81
E: ID_SERIAL_SHORT=6d0946606d79f90025f3e09a0c1f9e81
```
注記：
複数のディスクにデータディレクトリが割り当てられている場合は、各ディスクのID_SERIAL記録するために上記のコマンドを複数回実行する必要があります。
cpufreq モジュールの電源ポリシーを確認するには、次のコマンドを実行します。
```
cpupower frequency-info --policy
```
```
analyzing CPU 0:
current policy: frequency should be within 1.20 GHz and 3.10 GHz.
              The governor "powersave" may decide which speed to use within this range.
```
注記：
The governor "powersave"が出力された場合、 cpufreq モジュールの電源ポリシーはpowersaveです。これをperformanceに変更する必要があります。仮想マシンまたはクラウドホストを使用する場合、出力は通常Unable to determine current policyであり、何も変更する必要はありません。

オペレーティングシステムの最適なパラメータを構成します。

方法 1: チューニングを使用する (推奨)

現在のオペレーティングシステムの調整されたプロファイルを表示するには、 tuned-adm listコマンドを実行します。

tuned-adm list

Available profiles:
- balanced                    - General non-specialized tuned profile
- desktop                     - Optimize for the desktop use-case
- hpc-compute                 - Optimize for HPC compute workloads
- latency-performance         - Optimize for deterministic performance at the cost of increased power consumption
- network-latency             - Optimize for deterministic performance at the cost of increased power consumption, focused on low latency network performance
- network-throughput          - Optimize for streaming network throughput, generally only necessary on older CPUs or 40G+ networks
- powersave                   - Optimize for low power consumption
- throughput-performance      - Broadly applicable tuning that provides excellent performance across a variety of common server workloads
- virtual-guest               - Optimize for running inside a virtual guest
- virtual-host                - Optimize for running KVM guests
Current active profile: balanced

出力Current active profile: balanced 、現在のオペレーティングシステムの調整済みプロファイルがbalancedであることを意味します。現在のプロファイルに基づいて、オペレーティングシステムの構成を最適化することをお勧めします。

新しい調整プロファイルを作成します。

mkdir /etc/tuned/balanced-tidb-optimal/
vi /etc/tuned/balanced-tidb-optimal/tuned.conf

[main]
include=balanced

[cpu]
governor=performance

[vm]
transparent_hugepages=never

[disk]
devices_udev_regex=(ID_SERIAL=36d0946606d79f90025f3e09a0c1fc035)|(ID_SERIAL=36d0946606d79f90025f3e09a0c1f9e81)
elevator=noop

出力include=balancedオペレーティングシステムの最適化構成を現在のbalancedプロファイルに追加することを意味します。

新しく調整されたプロファイルを適用します。
```
tuned-adm profile balanced-tidb-optimal
```

方法 2: スクリプトを使用して構成します。すでに方法 1 を使用している場合は、この方法をスキップしてください。

デフォルトのカーネルバージョンを確認するには、 grubbyコマンドを実行します。
注記：
grubbyを実行する前に、まずgrubbyパッケージをインストールします。
```
grubby --default-kernel
```
```
/boot/vmlinuz-3.10.0-957.el7.x86_64
```
カーネル構成を変更するには、 grubby --update-kernel実行します。
```
grubby --args="transparent_hugepage=never" --update-kernel /boot/vmlinuz-3.10.0-957.el7.x86_64
```
注記：
--update-kernel後には実際のデフォルトのカーネルバージョンが続きます。

変更されたデフォルトのカーネル構成を確認するには、 grubby --info実行します。

grubby --info /boot/vmlinuz-3.10.0-957.el7.x86_64

注記：
--info後には実際のデフォルトのカーネルバージョンが続きます。

index=0
kernel=/boot/vmlinuz-3.10.0-957.el7.x86_64
args="ro crashkernel=auto rd.lvm.lv=centos/root rd.lvm.lv=centos/swap rhgb quiet LANG=en_US.UTF-8 transparent_hugepage=never"
root=/dev/mapper/centos-root
initrd=/boot/initramfs-3.10.0-957.el7.x86_64.img
title=CentOS Linux (3.10.0-957.el7.x86_64) 7 (Core)

THP を直ちに無効にするには、現在のカーネル構成を変更します。

echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag

udev スクリプトで I/O スケジューラを設定します。

vi /etc/udev/rules.d/60-tidb-schedulers.rules

ACTION=="add|change", SUBSYSTEM=="block", ENV{ID_SERIAL}=="36d0946606d79f90025f3e09a0c1fc035", ATTR{queue/scheduler}="noop"
ACTION=="add|change", SUBSYSTEM=="block", ENV{ID_SERIAL}=="36d0946606d79f90025f3e09a0c1f9e81", ATTR{queue/scheduler}="noop"

udev スクリプトを適用します。

udevadm control --reload-rules
udevadm trigger --type=devices --action=change

CPU 電力ポリシーを構成するサービスを作成します。

cat  >> /etc/systemd/system/cpupower.service << EOF
[Unit]
Description=CPU performance
[Service]
Type=oneshot
ExecStart=/usr/bin/cpupower frequency-set --governor performance
[Install]
WantedBy=multi-user.target
EOF

CPU 電源ポリシー構成サービスを適用します。

systemctl daemon-reload
systemctl enable cpupower.service
systemctl start cpupower.service

THP ステータスを確認するには、次のコマンドを実行します。
```
cat /sys/kernel/mm/transparent_hugepage/enabled
```
```
always madvise [never]
```
次のコマンドを実行して、データディレクトリが配置されているディスクの I/O スケジューラを確認します。
```
cat /sys/block/sd[bc]/queue/scheduler
```
```
[noop] deadline cfq
[noop] deadline cfq
```

cpufreq モジュールの電源ポリシーを確認するには、次のコマンドを実行します。

cpupower frequency-info --policy

analyzing CPU 0:
current policy: frequency should be within 1.20 GHz and 3.10 GHz.
              The governor "performance" may decide which speed to use within this range.

sysctlパラメータを変更するには、次のコマンドを実行します。
```
echo "fs.file-max = 1000000">> /etc/sysctl.conf
echo "net.core.somaxconn = 32768">> /etc/sysctl.conf
echo "net.ipv4.tcp_tw_recycle = 0">> /etc/sysctl.conf
echo "net.ipv4.tcp_syncookies = 0">> /etc/sysctl.conf
echo "vm.overcommit_memory = 1">> /etc/sysctl.conf
echo "vm.min_free_kbytes = 1048576">> /etc/sysctl.conf
sysctl -p
```
注記：
- vm.min_free_kbytesは、システムによって予約される空きメモリの最小量 (KiB 単位) を制御する Linux カーネルパラメータです。
- vm.min_free_kbytesに設定すると、メモリ再利用メカニズムに影響します。設定が大きすぎると使用可能なメモリが減少し、設定が小さすぎるとメモリ要求速度がバックグラウンド再利用速度を超え、メモリ再利用が発生してメモリ割り当てが遅れる可能性があります。
- 少なくともvm.min_free_kbytes ～ 1048576 KiB (1 GiB) に設定することをお勧めします。 NUMAがインストールされているの場合はnumber of NUMA nodes * 1048576 KiB に設定することをお勧めします。
- メモリサイズが 16 GiB 未満のサーバーの場合は、デフォルト値のvm.min_free_kbytesを変更せずに維持することをお勧めします。

ユーザーのlimits.confファイルを構成するには、次のコマンドを実行します。

cat << EOF >>/etc/security/limits.conf
tidb           soft    nofile          1000000
tidb           hard    nofile          1000000
tidb           soft    stack          32768
tidb           hard    stack          32768
EOF

SSH相互信頼とパスワードなしのsudoを手動で設定する

このセクションでは、SSH 相互信頼とパスワードなしの sudo を手動で構成する方法について説明します。デプロイメントには、SSH 相互信頼とパスワードなしのログインを自動的に構成するTiUPを使用することをお勧めします。TiUPを使用して TiDB クラスターをデプロイする場合は、このセクションを無視してください。

それぞれrootユーザーアカウントを使用してターゲットマシンにログインし、 tidbユーザーを作成してログインパスワードを設定します。
```
useradd tidb && \
passwd tidb
```
パスワードなしで sudo を設定するには、次のコマンドを実行し、ファイルの末尾にtidb ALL=(ALL) NOPASSWD: ALL追加します。
```
visudo
```
```
tidb ALL=(ALL) NOPASSWD: ALL
```
tidbユーザーを使用してコントロールマシンにログインし、次のコマンドを実行します。3 10.0.1.1ターゲットマシンの IP に置き換え、プロンプトに従ってターゲットマシンのtidbユーザーパスワードを入力します。コマンドの実行後、SSH 相互信頼がすでに作成されています。これは他のマシンにも適用されます。新しく作成されたtidbユーザーには.sshディレクトリがありません。このようなディレクトリを作成するには、RSA キーを生成するコマンドを実行します。コントロールマシンに TiDB コンポーネントを展開するには、コントロールマシンとコントロールマシン自体の相互信頼を構成します。
```
ssh-keygen -t rsa
ssh-copy-id -i ~/.ssh/id_rsa.pub 10.0.1.1
```
tidbユーザーアカウントを使用してコントロールマシンにログインし、 sshを使用してターゲットマシンの IP にログインします。パスワードを入力する必要がなく、正常にログインできる場合は、SSH 相互信頼が正常に構成されています。
```
ssh 10.0.1.1
```
```
[tidb@10.0.1.1 ~]$
```
tidbユーザーを使用してターゲットマシンにログインした後、次のコマンドを実行します。パスワードを入力する必要がなく、 rootユーザーに切り替えることができれば、 tidbユーザーのパスワードなしの sudo が正常に構成されています。
```
sudo -su root
```
```
[root@10.0.1.1 tidb]#
```

`numactl`ツールをインストールする

このセクションでは、NUMA ツールのインストール方法について説明します。オンライン環境では、ハードウェア構成が通常必要以上に高いため、ハードウェアリソースをより適切に計画するために、TiDB または TiKV の複数のインスタンスを 1 台のマシンに展開できます。このようなシナリオでは、NUMA ツールを使用して、パフォーマンスの低下を引き起こす可能性のある CPU リソースの競合を防ぐことができます。

注記：
NUMA を使用してコアをバインドすることは、CPU リソースを分離する方法であり、高度に構成された物理マシンに複数のインスタンスを展開するのに適しています。
tiup cluster deployを使用してデプロイを完了したら、 execコマンドを使用してクラスターレベルの管理操作を実行できます。

NUMA ツールをインストールするには、次の 2 つの方法のいずれかを実行します。

方法 1 : ターゲットノードにログインして NUMA をインストールします。CentOS Linux リリース 7.7.1908 (Core) を例に挙げます。

sudo yum -y install numactl

方法 2 : tiup cluster execコマンドを実行して、既存のクラスターに NUMA をバッチでインストールします。

TiUPを使用して TiDBクラスタをデプロイに従ってクラスターtidb-testを展開します。TiDB クラスターをインストールしている場合は、この手順をスキップできます。
```
tiup cluster deploy tidb-test v6.1.0 ./topology.yaml --user root [-p] [-i /home/root/.ssh/gcp_rsa]
```
sudo権限を使用してtiup cluster execコマンドを実行し、 tidb-testクラスター内のすべてのターゲットマシンに NUMA をインストールします。
```
tiup cluster exec tidb-test --sudo --command "yum -y install numactl"
```
tiup cluster execコマンドのヘルプ情報を取得するには、 tiup cluster exec --helpコマンドを実行します。