Percona XtraDB 8.0.34-26.1 benchmark with HabberDB 4.9 build schema issue

[phaneesh]

I am trying to run a benchmark on Percona XtraDB 8.0.34-26.1 with HammerDB 4.9. I am facing issue with buildschema.

HammerDB is running on Linux and here is the OS version:

Distributor ID:	Ubuntu
Description:	Ubuntu 22.04.3 LTS
Release:	22.04
Codename:	jammy

Here is the tcl script I am using:

dbset db mysql
dbset bm TPC-C
vuset logtotemp 1

diset connection mysql_host perf-test001
diset connection mysql_port 3306
diset connection mysql_socket /tmp/mysql.sock

diset tpcc mysql_count_ware 250
diset tpcc mysql_num_vu 50
diset tpcc mysql_user perf_user
diset tpcc mysql_pass perf_password
diset tpcc mysql_storage_engine innodb
diset tpcc mysql_partition true
diset tpcc mysql_history_pk true
buildschema

I am getting the following error and buildschema fails:

Vuser 1:RUNNING
Vuser 1:Monitor Thread
Vuser 1:CREATING TPCC SCHEMA
Vuser 1:Ssl_cipher 
Vuser 1:CREATING DATABASE tpcc
Vuser 1:CREATING TPCC TABLES
Error in Virtual User 1: expected version number but got "8.0.34-26.1"
Vuser 1:FINISHED FAILED

Library Check says mysql library is loaded successfully:

hammerdb>librarycheck
Checking database library for Oracle
Error: failed to load Oratcl - can't read "env(ORACLE_HOME)": no such variable
Ensure that Oracle client libraries are installed and the location in the LD_LIBRARY_PATH environment variable
Checking database library for MSSQLServer
Error: failed to load tdbc::odbc - can't create object "::tdbc::odbc::connection": command already exists with that name
Ensure that MSSQLServer client libraries are installed and the location in the LD_LIBRARY_PATH environment variable
Checking database library for Db2
Error: failed to load db2tcl - couldn't load file "/root/HammerDB-4.9/lib/db2tcl2.0.1/libdb2tcl.so": libdb2.so.1: cannot open shared object file: No such file or directory
Ensure that Db2 client libraries are installed and the location in the LD_LIBRARY_PATH environment variable
Checking database library for MySQL
Success ... loaded library mysqltcl for MySQL
Checking database library for PostgreSQL
Error: failed to load Pgtcl - couldn't load file "/root/HammerDB-4.9/lib/pgtcl2.1.1/libpgtcl2.1.1.so": libpq.so.5: cannot open shared object file: No such file or directory
Ensure that PostgreSQL client libraries are installed and the location in the LD_LIBRARY_PATH environment variable
Checking database library for MariaDB
Error: failed to load mariatcl - couldn't load file "/root/HammerDB-4.9/lib/mariatcl0.1/libmariatcl0.1.so": libmariadb.so.3: cannot open shared object file: No such file or directory
Ensure that MariaDB client libraries are installed and the location in the LD_LIBRARY_PATH environment variable

Please let me know if I am miscongfiguring the configuration for mysql.

[sm-shaw]

It looks like Percona is returning a badly formed version number to the SQL select version() when we are checking to see if the version supports invisible primary keys.

As we don't explicitly test Percona then this is not a HammerDB bug - this is what we are looking for in version numbers that MySQL supports and it looks like Percona doesn't follow this format with the string 34-26. This is not best practice as it's not possible to compare higher/lower numbers with 34-26?.

VERSION NUMBERS
Version numbers consist of one or more decimal numbers separated by dots, such as 2 or 1.162 or 3.1.13.1. The first number is called the major version number. Larger numbers correspond to later versions of a package, with leftmost numbers having greater significance. For example, version 2.1 is later than 1.3 and version 3.4.6 is later than 3.3.5. Missing fields are equivalent to zeroes: version 1.3 is the same as version 1.3.0 and 1.3.0.0, so it is earlier than 1.3.1 or 1.3.0.2. A later version number is assumed to be upwards compatible with an earlier version number as long as both versions have the same major version number. For example, Tcl scripts written for version 2.3 of a package should work unchanged under versions 2.3.2, 2.4, and 2.5.1. Changes in the major version number signify incompatible changes: if code is written to use version 2.1 of a package, it is not guaranteed to work unmodified with either version 1.7.3 or version 3.1.

So there are 2 options:

1. Use the savescript command to save your build script, modify it (as described below) and load it and run it.

2. Edit the HammerDB source in src/mysql/mysqloltp.tcl - find the following section. Comment out/remove this section and manually set history_pk to true eor false whether you want a primary key for the history table. By default we don't, however MySQL needs one if using replication which is why this change was added.

proc CreateTables { mysql_handler mysql_storage_engine num_part history_pk } {
    puts "CREATING TPCC TABLES"
#    if { [ string toupper $mysql_storage_engine ] eq "INNODB" && $history_pk } {
#    set pkmin_version "8.0.30"
#    set version [ list [ mysql::sel $mysql_handler "select version()" -list ] ]
#    if { [ package vcompare $version $pkmin_version ]  eq -1 } {
#	    puts "Minimum MySQL version for invisible PK is $pkmin_version"
#	    set history_pk "false"
#    }
#    } else {
    set history_pk "false"
#    }

Then it won't check the badly formed Percona version number and will continue.

[phaneesh]

Thanks for the response! select version() does rerutn 8.0.34-26.1. This is definitely not MySQL standandard versioning scheme.
I modified the script as suggested and now I am able to build schema. I am preparing a small writeup on running massive scale benchmark on percona xtradb. Will add this as the workaround for this nuance with percona.

[sm-shaw]

👍