[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

GA

ラベル 3rd_party の投稿を表示しています。 すべての投稿を表示
ラベル 3rd_party の投稿を表示しています。 すべての投稿を表示

2025/03/03

古いバージョンのxtrabackupをビルドしようとしたら -DDOWNLOAD_BOOST=1 だとダウンロードできなかった

TL;DR
  • boostを同梱していないMySQLやxtrabackupでboostのダウンロードっぽいところでcmakeが転けていたら cmake/boost.cmake を編集するとうまくいくことがある
    • boostorg.jfrog.io から archives.boost.io に変わってるっぽい

yoku0825/xtrabackup-monkey-patch を使って XtraBackup 8.0.35-31 をビルドしようと思ったら、boostをダウンロードしてるっぽいところで転けた。

$ git clone git@github.com:yoku0825/xtrabackup-monkey-patch
$ cd xtrabackup-monkey-patch
$ git checkout checkout 8.0.35-31

$ cd src
$ cmake -DCMAKE_INSTALL_PREFIX=~/xb-8.0.35-1 -DWITH_BOOST=./boost -DDOWNLOAD_BOOST=1 -DFORCE_INSOURCE_BUILD=1
..
-- Downloading boost_1_77_0.tar.bz2 to /home/yoku0825/git/xtrabackup-monkey-patch/src/boost
-- [download 100% complete]
-- [download 9% complete]
-- [download 22% complete]
-- [download 34% complete]
-- [download 46% complete]
-- [download 58% complete]
-- [download 70% complete]
-- [download 82% complete]
-- [download 94% complete]
-- [download 100% complete]
-- cd /home/yoku0825/git/xtrabackup-monkey-patch/src/boost; tar xfj /home/yoku0825/git/xtrabackup-monkey-patch/src/boost/boost_1_77_0.tar.bz2
CMake Error: Problem with archive_read_open_file(): Unrecognized archive format
CMake Error: Problem extracting tar: /home/yoku0825/git/xtrabackup-monkey-patch/src/boost/boost_1_77_0.tar.bz2
-- WITH_BOOST /home/yoku0825/git/xtrabackup-monkey-patch/src/boost.
-- Failed to extract files.
   Please try downloading and extracting yourself.
   The url is: https://boostorg.jfrog.io/artifactory/main/release/1.77.0/source/boost_1_77_0.tar.bz2
CMake Error at cmake/boost.cmake:256 (MESSAGE):
  Giving up.
Call Stack (most recent call first):
  CMakeLists.txt:1567 (INCLUDE)

-- Configuring incomplete, errors occurred!

DOWNLOAD_BOOSTのあたりで転けている様子…。

$ ll /home/yoku0825/git/xtrabackup-monkey-patch/src/boost/boost_1_77_0.tar.bz2
-rw-r--r--. 1 yoku0825 yoku0825 11534 Feb 20 07:21 /home/yoku0825/git/xtrabackup-monkey-patch/src/boost/boost_1_77_0.tar.bz2

$ file /home/yoku0825/git/xtrabackup-monkey-patch/src/boost/boost_1_77_0.tar.bz2
/home/yoku0825/git/xtrabackup-monkey-patch/src/boost/boost_1_77_0.tar.bz2: HTML document, ASCII text, with very long lines

$ w3m -no-mouse -T text/html /home/yoku0825/git/xtrabackup-monkey-patch/src/boost/boost_1_77_0.tar.bz2 | cat
bunzip2: (stdin) is not a bzip2 file.

ブラウザで https://boostorg.jfrog.io/artifactory/main/release/ を開いてみると我々が期待しないような感じになっているのでたぶんここのURLが古い…。

$ grep -r boostorg.jfrog.io cmake/
cmake/boost.cmake:  "https://boostorg.jfrog.io/artifactory/main/release/1.77.0/source/${BOOST_TARBALL}"

cmake/boost.cmake の中で指定している。

本家8.0.41のcmake/boost.cmakearchives.boost.io に向いているのでそれを検索してみる。
jfrogと archives.boost.io の話題で正に Where is https://archives.boost.io/ hosted? · Issue #845 · boostorg/boost なんていうのが出てきたし、 Boost公式のダウンロードページ から辿れるリンクも archives.boost.io に向いているので正しそう。

というわけでpushしました。

古いソースコードで同じようになるやつはこれで使えるようになるかも。

2024/12/24

gh-ostの-postpone-cut-over-flag-fileみたいなことをpt-oscでもやりたい

この記事は MySQL Advent Calendar 2024 の24日目の記事です。

昨日は updraftさん今日は、MySQL 8.0.35で非推奨になった「SHOW PROCESSLIST」の代わりのパフォーマンススキーマを見てみるの日。 - 今日はなにの日。 でした。


最近、ALTER TABLEのメタデータロックの競合がちょっと話題に上がっていました(ので便乗して今年書いたスライドを載せておきます)

それでちょっと思い出したんですが、 gh-ostpt-online-schema-change (以下、pt-osc) とメタデータロックを比較するとこんな感じになります。

type 開始時排他MDL 終了時排他MDL
ネイティブALTER TABLE(ALGORITHM=INPLACE) 取る 取る
ネイティブALTER TABLE(ALGORITHM=INSTANT) 取る 取らない
gh-ost 取らない 取る
pt-osc 3回取る 取る

pt-oscの仕組み的にトリガーを使うので、 CREATE TRIGGER のぶんだけ (INSERT Trigger, Update Trigger, Delete Triggerがそれぞれ同時に作れないので計3回) 排他MDLが必要になります。

で、ネイティブALTER TABLEにせよgh-ost, pt-oscにせよ

があって、開始時のMDLは「まあCtrl+Cですぐ中断できるし lock_wait_timeout でAbortさせても良い」んですが終了時のMDLは「終わる時間が完全には読みにくい」とか「終わる時間が深夜になると無理」とか「ここでタイムアウトしちゃうと作業が最初からやり直し」とかがあります。

gh-ostは(おそらく作ってる人たちがそもそもこの悩みを抱えていて) -postpone-cut-over-flag-file というのがあって、この「終了処理で排他MDLを取らないといけないステップをファイルの存在で遅延させる」仕組みがあります。

たとえば -postpone-cut-over-flag-file /tmp/flag とかやっておくと、 /tmp/flag がある間は終了処理に入らない(gh-ostを起動した時点でファイルは勝手に作られる)ので、ピークタイムを避けてゆっくり余裕がありそうな時間に rm /tmp/flag で排他MDLの処理を実行させることができます。

対して、pt-oscにはデフォルトでこの機能はない ( —pause-file だとカットオーバー以外の INSERT IGNORE INTO .. の部分も止まってしまう) ので、自分で --plugin で使える Perlスクリプト を書いてフックしてやる必要があります。

pt-oscのドキュメントにも書いてあるんですがこの形の方が人に説明しやすかったので前に書いたものがこちらです。

https://github.com/yoku0825/pt-osc-plugin/blob/main/pt-osc-plugin.pl

init(pt-osc起動時に呼ばれるフック)でフラグファイルを作ってあげて

sub init
{
  my ($self, %args)= @_;
  _logger(DEBUG, "start init");
  open(my $flag_file, ">", "/tmp/flag");
  close($flag_file);
  _logger(DEBUG, "finish init");
}

before_swap_tables(排他MDLが必要になる処理の直前)でフラグファイルをチェックしてあげれば

sub before_swap_tables
{
  my ($self, %args)= @_;
  _logger(DEBUG, "start before_swap_tables");

  while (-e "/tmp/flag")
  {
    _logger(INFO, "flag file does not exist, sleepling..");
    sleep 5;
  }

  _logger(DEBUG, "finish before_swap_tables");
}

↓pt-oscの終了(するときの排他MDL)のタイミングを調整できます。

$ PLUGIN_LOG_LEVEL=9 pt-online-schema-change --user=root --socket=/usr/mysql/8.0.40/data/mysql.sock --alter "Engine = InnoDB" D=d1
,t=t1 --execute --plugin=/tmp/pt-osc.pl

..
start after_copy_rows at pt_online_schema_change::main
finish after_copy_rows at pt_online_schema_change::main
start before_swap_tables at pt_online_schema_change::main
flag file does not exist, sleepling.. at pt_online_schema_change::main
flag file does not exist, sleepling.. at pt_online_schema_change::main
flag file does not exist, sleepling.. at pt_online_schema_change::main

「pt-oscは終了時の排他MDLが制御できなくて…」という時に試してみてください。

明日は zoosm3さん です!

2021/12/08

今度はConoHa 1GBの上でMariaDBをビルドする

このエントリは ConoHa Advent Calendar 2021MySQL Advent Calendar 2021 の8日目の記事です。

昨日は @diglateam3 さんの えっ!?ConoHaでVRコンテンツを!? 〜 A-Frameで手軽に始めるWebXR@hamchance0215 さんの MySQLの行ロックを図解 でした。


そういえばもう10.0以来、MariaDBをソースビルドしてないんじゃないかなという気になったので、ふと思うままにビルドしてみることにしました。

最近はMroongaストレージエンジンが鬼門だという噂を聞いて、そういえば10.0の時もあったなあとか思い出したんですが、最近のバージョンだとどの Mroonga が同梱されてるのか更新されてなかったりするのかしら。

About Mroonga - MariaDB Knowledge Base

取り敢えず逝ってみよう。

ConoHa 1GBのVPSをCentOS Stream 8でポチ。

CentOS Stream 8は一応一通りのバージョンでサポートされていそう。

OS Compatibility — MariaDB Enterprise Documentation


取り敢えず10.6の最新版。


$ wget https://ftp.yz.yamagata-u.ac.jp/pub/dbms/mariadb/mariadb-10.6.5/source/mariadb-10.6.5.tar.gz

$ tar xf mariadb-10.6.5.tar.gz

$ cd mariadb-10.6.5/

$ cmake .

-bash: cmake: command not found

いきなり忘れていた。

$ sudo dnf install -y cmake gcc gcc-c++
$ cmake .
..
CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
  Could NOT find Curses (missing: CURSES_LIBRARY CURSES_INCLUDE_PATH)
Call Stack (most recent call first):
  /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE)
  /usr/share/cmake/Modules/FindCurses.cmake:268 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  cmake/readline.cmake:55 (FIND_PACKAGE)
  cmake/readline.cmake:185 (FIND_CURSES)
  CMakeLists.txt:384 (MYSQL_CHECK_READLINE)

..

おお、 -DWITH_BOOST 要らないのか。ちょっと新鮮。

$ sudo dnf install -y ncurses-devel
$ rm CMakeCache.txt
$ cmake .
..
CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
  Could NOT find GnuTLS (missing: GNUTLS_LIBRARY GNUTLS_INCLUDE_DIR)
  (Required is at least version "3.3.24")
Call Stack (most recent call first):
  /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE)
  /usr/share/cmake/Modules/FindGnuTLS.cmake:68 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  libmariadb/CMakeLists.txt:326 (FIND_PACKAGE)

..

OpenSSLではなくGnuTLSを要求された。

$ sudo dnf install -y gnutls-devel

$ cmake .
..

$ time make
..
real    97m11.810s
user    85m56.911s
sys     7m46.945s

あれ、超あっさり終わった…。

ついでに、現在開発版の10.8

$ wget https://ftp.yz.yamagata-u.ac.jp/pub/dbms/mariadb/mariadb-10.7.1/source/mariadb-10.7.1.tar.gz
$ tar xf mariadb-10.7.1.tar.gz
$ cd mariadb-10.7.1/
$ cmake .
..

$ time make
..
real    100m15.233s
user    88m40.496s
sys     7m59.481s

超あっさりビルドできた…

$ du -sh ~/mariadb-10.?.?
6.5G    /home/yoku0825/mariadb-10.6.5
6.6G    /home/yoku0825/mariadb-10.7.1

ビルド済のサイズは5.7以上8.0未満といった感じ

5.3G    mysql-5.7.36/

19G     mysql-8.0.27/

というか噂に聞いていたよりLinuxだからかあっさりビルドできてしまった…。

明日は @hironobu_s さんと @tkooler_lufar さんです!

2021/09/11

pt-online-schema-changeがColumn 'xx' cannot be nullで止まる

TL;DR
  • NULLが入っているカラムを後から NOT NULL にしようとすると出る
  • 何故出るかというと、 INSERT IGNORE INTOがNOT NULL DEFAULTを裏切る から敢えて SHOW WARNINGS を拾ってエラーにしている
    • 裏切られるのを承知の上で強行するなら pt-online-schema-change --null-to-not-null でいける
  • UPDATE t1 SET val = ? WHERE val IS NULL でNULLを排除してからpt-online-schema-changeすればいいんじゃないかな

日々の覚書: INSERT IGNORE INTOがNOT NULL DEFAULTを裏切る の続き。

pt-oscは INSERT IGNORE INTO を使ってるはずなのになんでこのメッセージでエラるんだろ? と思ったら、 ↑の裏切りを防ぐために明示的にワーニングを拾ってエラーにエスカレーションしているのであった。

https://github.com/percona/percona-toolkit/blob/v3.3.1/bin/pt-online-schema-change#L11791-L11828

mysql80 121> CREATE TABLE t1 (num int PRIMARY KEY, val varchar(32));
Query OK, 0 rows affected (0.02 sec)

mysql80 121> INSERT INTO t1 VALUES (1, 'one'), (2, NULL);
Query OK, 2 rows affected (0.01 sec)
Records: 2  Duplicates: 0  Warnings: 0

mysql80 121> SELECT * FROM t1;
+-----+------+
| num | val  |
+-----+------+
|   1 | one  |
|   2 | NULL |
+-----+------+
2 rows in set (0.00 sec)

mysql80 123> SELECT @@global.sql_mode;
+-------------------+
| @@global.sql_mode |
+-------------------+
|                   |
+-------------------+
1 row in set (0.00 sec)

sql_modeに関係ないことを確認するために、グローバルSQL_MODEを空っぽにしておく。

$ pt-online-schema-change -S /usr/mysql/8.0.26/data/mysql.sock -uroot --alter "MODIFY val varchar(32) NOT NULL DEFAULT 'z'" D=d2,t=t1 --execute
No slaves found.  See --recursion-method if host 150-95-141-50 has slaves.
Not checking slave lag because no slaves were found and --check-slave-lag was not specified.
Operation, tries, wait:
  analyze_table, 10, 1
  copy_rows, 10, 0.25
  create_triggers, 10, 1
  drop_triggers, 10, 1
  swap_tables, 10, 1
  update_foreign_keys, 10, 1
Altering `d2`.`t1`...
Creating new table...
Created new table d2._t1_new OK.
Altering new table...
Altered `d2`.`_t1_new` OK.
2021-09-11T00:11:48 Creating triggers...
2021-09-11T00:11:48 Created triggers OK.
2021-09-11T00:11:48 Copying approximately 2 rows...
2021-09-11T00:11:48 Dropping triggers...
2021-09-11T00:11:48 Dropped triggers OK.
2021-09-11T00:11:48 Dropping new table...
2021-09-11T00:11:48 Dropped new table OK.
`d2`.`t1` was not altered.
        (in cleanup) 2021-09-11T00:11:48 Error copying rows from `d2`.`t1` to `d2`.`_t1_new`: 2021-09-11T00:11:48 Copying rows caused a MySQL error 1048:
    Level: Warning
     Code: 1048
  Message: Column 'val' cannot be null
    Query: INSERT LOW_PRIORITY IGNORE INTO `d2`.`_t1_new` (`num`, `val`) SELECT `num`, `val` FROM `d2`.`t1` LOCK IN SHARE MODE /*pt-online-schema-change 5706 copy table*/
2021-09-11T00:11:48 Dropping triggers...
2021-09-11T00:11:48 Dropped triggers OK.
`d2`.`t1` was not altered.

とまあ転けて終わる。
…と、ジェネラルログをよく見てたら、元のsql_modeに関わらずいったんsql_modeを全OFFしていた。

2021-09-11T00:11:48.055972+09:00          132 Query     /*!40101 SET @@SQL_MODE := @OLD_SQL_MODE, @@SQL_QUOTE_SHOW_CREATE := @OLD_QUOTE */

まあいっか。

—null-to-not-null オプションをつけると、通る。ただし、DEFAULTに裏切られるので暗黙のフォールバックを受ける。

mysql80 136> SHOW CREATE TABLE t1\G
*************************** 1. row ***************************
       Table: t1
Create Table: CREATE TABLE `t1` (
  `num` int NOT NULL,
  `val` varchar(32) NOT NULL DEFAULT 'z',
  PRIMARY KEY (`num`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
1 row in set (0.00 sec)

mysql80 136> SELECT * FROM t1;
+-----+-----+
| num | val |
+-----+-----+
|   1 | one |
|   2 |     |
+-----+-----+
2 rows in set (0.00 sec)

これが嫌な場合、 先んじて UPDATE t1 SET val = 'z' WHERE val IS NULL とでもしてNULLをつぶしておくのが正しいと思う。実際にNULLに当たらなければ、 --null-to-not-null をつけなくてもpt-oscは完走する。

ちなみにMySQLのNative ALTER TABLEはsql_modeに影響を受ける。STRICTな時はエラーになるし

mysql80 136> SELECT @@session.sql_mode;
+-----------------------------------------------------------------------------------------------------------------------+
| @@session.sql_mode                                                                                                    |
+-----------------------------------------------------------------------------------------------------------------------+
| ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION |
+-----------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

mysql80 136> SELECT * FROM t1;
+-----+------+
| num | val  |
+-----+------+
|   1 | one  |
|   2 | NULL |
+-----+------+
2 rows in set (0.00 sec)

mysql80 136> ALTER TABLE t1 MODIFY val varchar(32) NOT NULL DEFAULT 'z';
ERROR 1138 (22004): Invalid use of NULL value

Non-Strictな場合はDEFAULTを裏切ってALTERが走る。

mysql80 136> SET SESSION sql_mode = '';
Query OK, 0 rows affected (0.00 sec)

mysql80 136> ALTER TABLE t1 MODIFY val varchar(32) NOT NULL DEFAULT 'z';
Query OK, 2 rows affected, 1 warning (0.04 sec)
Records: 2  Duplicates: 0  Warnings: 1

mysql80 136> SHOW WARNINGS;
+---------+------+------------------------------------------+
| Level   | Code | Message                                  |
+---------+------+------------------------------------------+
| Warning | 1265 | Data truncated for column 'val' at row 2 |
+---------+------+------------------------------------------+
1 row in set (0.00 sec)

mysql80 136> SELECT * FROM t1;
+-----+-----+
| num | val |
+-----+-----+
|   1 | one |
|   2 |     |
+-----+-----+
2 rows in set (0.00 sec)

こっちももちろんNULLに当たらなければSTRICT + ALTER TABLEでもエラーにはならないので、「NULLABLEからNOT NULLにする時はUPDATEでまずNULLを排除しましょう」という極めてフツーの感じになるのであった。

mysql80 136> SELECT @@session.sql_mode;
+-----------------------------------------------------------------------------------------------------------------------+
| @@session.sql_mode                                                                                                    |
+-----------------------------------------------------------------------------------------------------------------------+
| ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION |
+-----------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

mysql80 136> CREATE TABLE t1 (num int PRIMARY KEY, val varchar(32));
Query OK, 0 rows affected (0.01 sec)

mysql80 136> INSERT INTO t1 VALUES (1, 'one'), (2, NULL);
Query OK, 2 rows affected (0.01 sec)
Records: 2  Duplicates: 0  Warnings: 0

mysql80 136> UPDATE t1 SET val = 'z' WHERE val IS NULL;
Query OK, 1 row affected (0.01 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql80 136> SELECT * FROM t1;
+-----+------+
| num | val  |
+-----+------+
|   1 | one  |
|   2 | z    |
+-----+------+
2 rows in set (0.00 sec)

mysql80 136> ALTER TABLE t1 MODIFY val varchar(32) NOT NULL DEFAULT 'z';
Query OK, 0 rows affected (0.04 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql80 136> SELECT * FROM t1;
+-----+-----+
| num | val |
+-----+-----+
|   1 | one |
|   2 | z   |
+-----+-----+
2 rows in set (0.00 sec)

2021/06/09

Percona Toolkitのテスト環境を整える

TL;DR
  • Setting up the development environment の通りに ~やるつもりがない人または~ やっても上手くいかなかった人向け
    • ほら、テストしたいバージョンがいろいろある人とかさ

Setting up the development environment は一通り目を通しておいた方が良い気がします。

Percona Toolkitのテストは MySQL::Sandbox っぽいスクリプトを内包していて、バイナリをポンと置いて環境変数をセットするだけで、3つくらいの mysqld を起動してそれに対してテストを走らせてくれます。

というわけでまずは mysqld 実行ファイルが必要。PXCのテストをするつもりでないなら吊るしのMySQLでも良い。ただし INSTALL_LAYOUT=STANDALONE を想定しているので、rpmでインストールするのはダメ。Linux - Genericのtarボールを解凍するのが良いんではないか。

$ wget https://dev.mysql.com/get/Downloads/MySQL-8.0/mysql-8.0.25-linux-glibc2.12-x86_64.tar.xz
$ tar -C /tmp -xf mysql-8.0.25-linux-glibc2.12-x86_64.tar.xz
$ ll -d /tmp/mysql-8.0.25-linux-glibc2.12-x86_64
$ export PERCONA_TOOLKIT_SANDBOX=/tmp/mysql-8.0.25-linux-glibc2.12-x86_64

展開した先のディレクトリを PERCONA_TOOLKIT_SANDBOX 環境変数に詰めておく。

次はPercona Toolkitのソースコードを持ってくる。

$ git clone https://github.com/percona/percona-toolkit.git
$ cd percona-toolkit
$ pwd  ### まあどこでもいいんだけど
/root/git/percona-toolkit
$ export PERCONA_TOOLKIT_BRANCH="$PWD"   ### percona-toolkitディレクトリが PERCONA_TOOLKIT_BRANCH環境変数
$ export PERL5LIB=${PERCONA_TOOLKIT_BRANCH}/lib ### percona-toolkit/lib をPERL5LIBに追加

percona-toolkitのトップディレクトリとlibディレクトリをそれぞれ環境変数で指定。
全部設定が通ってれば、sandboxディレクトリの test-env スクリプトでテスト用のインスタンスが立ち上げられる。

$ ./sandbox/test-env checkconfig
PERCONA_TOOLKIT_BRANCH=/root/git/percona-toolkit - ok
PERCONA_TOOLKIT_SANDBOX=/tmp/mysql-8.0.25-linux-glibc2.12-x86_64 - ok
Percona Toolkit test environment config is ok!

$ ./sandbox/test-env stop
MySQL test server on port 12349 does not exist.
MySQL test server on port 12348 does not exist.
Stopping MySQL test server on port 12347... OK (1s)
Stopping MySQL test server on port 12346... OK (11s)
Stopping MySQL test server on port 12345... OK (12s)
MySQL test server on port 2903 does not exist.
MySQL test server on port 2902 does not exist.
MySQL test server on port 2901 does not exist.
MySQL test server on port 2900 does not exist.
Percona Toolkit test environment stopped.
[root@81dc970554a2 percona-toolkit]$ ./sandbox/test-env start
Creating default databases ...
Starting MySQL test server on port 12345... return 0
OK (1s)
Creating default databases ...
Starting MySQL test server on port 12346... return 0
OK (2s)
Creating default databases ...
Starting MySQL test server on port 12347... return 0
OK (9s)
Loading sakila database... OK
LOAD DATA LOCAL INFILE is enabled
Waiting for replication to finish... OK
Percona Toolkit test environment started with MySQL v8.0.

こいつらが起動している状態でテストを実行してやればOK。
t ディレクトリの真下ではなくて、コマンドごとにさらにディレクトリが掘ってあるのでその単位で prove してやる。

$ ps auxwww | grep mysqld
root      2358  4.1  8.5 1636704 86304 pts/0   Sl   09:52   0:08 /tmp/mysql-8.0.25-linux-glibc2.12-x86_64/bin/mysqld --defaults-file=/tmp/12346/my.sandbox.cnf -u root --init-file /tmp/12346/mysql-init
root      2510  4.7 28.6 1635464 290640 pts/0  Sl   09:52   0:09 /tmp/mysql-8.0.25-linux-glibc2.12-x86_64/bin/mysqld --defaults-file=/tmp/12347/my.sandbox.cnf -u root --init-file /tmp/12347/mysql-init
root      2703  5.0 33.9 1634624 344132 pts/0  Sl   09:55   0:02 /tmp/mysql-8.0.25-linux-glibc2.12-x86_64/bin/mysqld --defaults-file=/tmp/12345/my.sandbox.cnf -u root --init-file /tmp/12345/mysql-init
root      2986  0.0  0.0   9092   672 pts/0    S+   09:56   0:00 grep --color=auto mysqld

$ prove t/pt-table-usage/
t/pt-table-usage/basics.t .................... ok
t/pt-table-usage/create_table_definitions.t .. ok
t/pt-table-usage/explain_extended.t .......... ok
All tests successful.
Files=3, Tests=21,  5 wallclock secs ( 0.03 usr  0.01 sys +  0.91 cusr  0.44 csys =  1.39 CPU)
Result: PASS

ちなみにMySQL::Sandboxっぽいので、 /tmp/ポート番号/use とか起動すると中に入れる。

$ ll /tmp/12345/
total 28
drwxr-x--- 8 root root 4096 Jun  9 09:55 data
-rw-r--r-- 1 root root 1475 Jun  9 09:52 my.sandbox.cnf
-rw-r--r-- 1 root root  529 Jun  9 09:52 mysql-init
srwxrwxrwx 1 root root    0 Jun  9 09:55 mysql_sandbox12345.sock
-rw------- 1 root root    5 Jun  9 09:55 mysql_sandbox12345.sock.lock
-rwxr-xr-x 1 root root 2589 Jun  9 09:52 start
-rwxr-xr-x 1 root root 1537 Jun  9 09:52 stop
-rwxr-xr-x 1 root root  135 Jun  9 09:52 use

8.0.25だと t/pt-show-grants が転けたとか、5.6ベースでも t/pt-online-schema-change が転けるとかいろいろあるけど取り敢えずここまで