Great, now it is much more clear 🙂 Everything should exist in this MySQL version because it is the latest.
So after testing bunch of combinations it turned out it was due to COMPRESSION=’none’ statement.
If you exclude it from create statement:

You can puzzle it + can make a list of combinations to find the exact problem as me.
But it seems to be a bug – I can use encryption=’N’ but can not use compression=’none’?
Reported as -> https://bugs.mysql.com/bug.php?id=90040

In this topic I would like to make some notes about questions, how we can contribute or help on Open Source project.
The first thing is, to learn the product itself, how to install, how to remove, how to use etc.
Of course, the first place for this information is an official documentation.
How you can use the DOC? I am taking following approach:
* Read the doc to learn the needed thing.
* Test the info provided in the DOC –
if the info is valid(i.e you have different results)
continue
if it is not valid:
Report a bug – then continue reading.

The issue can be in DOC itself or in the product.
Did you find small typo in DOC? Did you think some info about topic is wrong? Or maybe you found wrong code samples?
Report it immediately and you will be the part of community.

Let’s take some DOC bug reports and examine them to get the idea.
The first is -> #87545:
While reading Connector/Python X Plugin reference did not see any info about Error module(mysqlx.errors).
So this missing info must be there, that is why reported as described. Simple? But it is crucial.

Another one is -> #81036
There is an entry about:
“Installing MySQL Shell on Yum-based Systems”:

> Install MySQL Shell with this command:

sudo apt-get install mysql-shell

Well you have already noticed that, it must be yum command not apt. Funny? But it is needed.

Here, I saw the error message in 5.7 but read about this only in 8.0 versions DOC. So the same info should be in 5.7s DOC as well, because I see error on 5.7 too.

In conclusion, we should understand the importance of documentation as well as, the importance to report DOC issues.
Many things are happening because of misunderstanding DOC or because of wrong info inside the DOCs.

Think about this twice in the next time, when you find some weird thing in DOC and just ignore it.
It is a real life, the thing which is not crucial for us can be important for others.

$ /home/shahriyar.rzaev/XB_TEST/server_dir/PS231017-percona-server-5.6.37-82.2-linux-x86_64-debug/bin/mysql -urepl --password='Baku12345' --port=10023 --socket=/home/shahriyar.rzaev/XB_TEST/server_dir/PS231017-percona-server-5.6.37-82.2-linux-x86_64-debug/socket.sock
Warning: Using a password on the command line interface can be insecure.
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 623
Server version: 5.6.37-82.2-debug-log MySQL Community Server (GPL)

So it turned out, the blank users were preventing slave connection to master server 🙂

This post is about, how I have tried to make simple Python script using mysqlx module work with MyRocks.
This is also related to pytest, as I have implemented simple pytest tests to call them from bash file.

So let’s discuss problem description:
The base problem is, by default when you create collection using Python X Plugin, the collection will have, 1 json type column called `doc` and 1 generated column from this `doc` column called `_id`.
So basically, you can not alter table engine to MyRocks because it will give an error something like:

Well, it can be solved by dropping generated `_id` column. Here we are encountering another issue that, if you have table with json data, please do NOT alter it to MyRocks, otherwise, you will get some weird results as described here:

Move binary mysql-bin.* files from datadir to /home/sh/small_mounted_dir/.
Update my.sandbox.cnf and add new path for log-bin variable. Then start MySQL using ./start script.
You can run sysbench to populate data:

It gives SEGFAULT exactly on (*sql_print_warning_hook)(wbuff) which makes clear that, sql_print_warning_hook is not initialized at that point.

So as a suggestion by Sergei Glushchenko the solution can be achieved by checking sql_print_warning_hook prior calling inside my_error.c or initialize earlier sql_print_warning_hook inside sql/mysqld.cc. The best to have both:

I decide to initialize sql_print_warning_hook inside init_server_components():
Took this one: