[MDEV-9759] MaraiDB 10.0 with Tokudb Slave can not replicaste from Master MairaDB 5.5 with Tokudb 7.1.0 Created: 2016-03-18  Updated: 2021-02-27  Resolved: 2016-04-15

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - TokuDB
Affects Version/s: 5.5
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: ye Assignee: Unassigned
Resolution: Incomplete Votes: 0
Labels: need_feedback
Environment:

Server version: 5.5.30-tokudb-7.1.0-MariaDB-log MariaDB Server



 Description   

What is the upgrade path for MariaDB with Tokudb ?
currently running Production with
Server version: 5.5.30-tokudb-7.1.0-MariaDB-log MariaDB Server

Tried 10.1 - but didn't work
Tried 10.0 - was able to startup with old datafiles - but while creating new tokudb on 5.5 Master it did not show up or replicate to 10.0 Slave ...

IS POSSIBLE TO REPLICATE FROM 5.5 MASTER to A 10.0 SLAVE WITH TOKUDB ?

  • can 10.0 Tokudb SLAVE replicate from mysql 5.5 TokuDB MASTER db ??

I know the Tokudb File header structure is different in MySQL 5.5 (FH FileHeader v2.4) and 10.0 has FH v2.7 or something
but
is it possible for a 10.0 Slave database to read from a 5.5 Master ???

  • or am I Doomed !! ?

Doing a mysqldump in PROD would take +1 day total down time of Prod MASTER
Copy the massive dump over to new Datacenter
Import dump which would take another day or two ....
Then point the application to start using the new Datacenter ....
This is not really acceptable to be down a couple day switching datacenteers!!

I trying to migrate from one Datacenter with MySQL 5.5 with tokudb storage engine
to a new datacenter with MySQL 10.0 w/ tokudb storage engine

I am trying to do this by building out Slaves in new datacenter reading from Master in Old Datacenter and when they are caught up - have a production outage for a couple minutes
Flush the master logs then switch application to read/write from old to new datacenter where I appoint one of the Slaves to be the new Master

After several attempt I was able to start the replication from 5.5 to 10.0
but I run into error
and I have to do too many GLOBAL skips_counters
so I have a feeling it's not supported to read from Tokudb 5.5 on a 10.0 slave....

Last_SQL_Errno: 1032
Last_SQL_Error: Could not execute Update_rows_v1 event on table YSIUSER.ysi_batch_notices; Can't find record in 'ysi_batch_notices', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log sjcprddbv202-binlog.023152, end_log_pos 9401388

[(none)]> stop slave;
Query OK, 0 rows affected (0.00 sec)

[(none)]> set GLOBAL SQL_SLAVE_SKIP_COUNTER = 1 ;
Query OK, 0 rows affected (0.00 sec)

[(none)]> start slave;
Query OK, 0 rows affected (0.00 sec)

Last_SQL_Errno: 1032
Last_SQL_Error: Could not execute Update_rows_v1 event on table YSIUSER.ysi_batch_notices; Can't find record in 'ysi_batch_notices', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND;



 Comments   
Comment by Elena Stepanova [ 2016-03-18 ]

IS POSSIBLE TO REPLICATE FROM 5.5 MASTER to A 10.0 SLAVE WITH TOKUDB ?
can 10.0 Tokudb SLAVE replicate from mysql 5.5 TokuDB MASTER db ??
is it possible for a 10.0 Slave database to read from a 5.5 Master ???

The 5.5 server that you are using is an ancient build created by a company that no longer exists, I can't find the downloadable binary and check what exactly can go wrong there.
I can say that in general,
1) MariaDB 10.0 can replicate TokuDB updates from current MariaDB 5.5, as well as MariaDB 5.5.33 which was the first MariaDB release with TokuDB (7.0.4), and MariaDB 5.5.34 (TokuDB 7.1.0);
2) MariaDB 10.0 with TokuDB can start on the datadir from MariaDB 5.5.33 and MariaDB 5.5.34, TokuDB starts and can access the old tables all right;
3) MariaDB 10.0 can not start on the datadir from Percona Server 5.6.29, but it can be because Percona Server has a higher TokuDB version.
4) MariaDB 10.0 can replicate TokuDB updates from current Percona Server (5.6.29), unless it uses syntax which is different between MariaDB's and Tokutek's versions (and apparently Percona's); for the differences, see https://mariadb.com/kb/en/mariadb/tokudb-differences .

Of course, for every point above there can be bugs that we are not aware of, which prevent things from working correctly; if you encounter them, please create bug reports.

For the rest of your complaints in the description, please formulate them in a readable manner if you want us to analyze them.
Here they are, one by one:

Tried 10.1 - but didn't work

Tried to do what? To run the server on the old datadir? To replicate? Did not work how? Did it crash? Did it refuse to start? What did it say?

Tried 10.0 - was able to startup with old datafiles - but while creating new tokudb on 5.5 Master it did not show up or replicate to 10.0 Slave ...

What did the slave status say? Was there an error? What did the error log say? What exactly was the CREATE statement? Did it use the syntax which is different between MariaDB and Tokutek (see the link above)?

I am trying to do this by building out Slaves in new datacenter reading from Master in Old Datacenter and when they are caught up...

Are you sure that on the master you have ALL binary logs from the begining of time? If you don't, you are very likely to get the problem you described next:

but I run into error
and I have to do too many GLOBAL skips_counters
so I have a feeling it's not supported to read from Tokudb 5.5 on a 10.0 slave....
Last_SQL_Errno: 1032
Last_SQL_Error: Could not execute Update_rows_v1 event on table YSIUSER.ysi_batch_notices; Can't find record in 'ysi_batch_notices', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log sjcprddbv202-binlog.023152, end_log_pos 9401388

This is a generic replication error which most likely has nothing to do with TokuDB specifically, it just means that your data on master and slave wasn't consistent by the time the event was processed, which is not surprising considering your rough path to this point.

Comment by Elena Stepanova [ 2016-04-15 ]

Please comment to re-open if you have further information on the issue.

Generated at Thu Feb 08 07:37:06 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.