Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Not a Bug
-
10.6.11
-
None
Description
If I use the CONNECT engine to federate data from another table, and then issue something like the following on the CONNECT table:
ALTER TABLE tbl1 ENGINE=InnoDB |
When converting from CONNECT to InnoDB, both the schema and table contents will be copied.
If I instead use the SPIDER engine to federate the access, only the schema definition is modified with the previous SQL statement, but no data is copied into the local table, instead the table remain empty.
My particular intent is to archive legacy data, moving it from one physical server to another after it has aged out.
I would simply use the CONNECT engine itself, but it fails to support SETs, ENUMs, and NULLable indexes.
Attachments
Issue Links
- relates to
-
MDEV-24389 CREATE TABLE ... ENGINE=S3 fails with (errno: 131 "Command not supported by the engine")
-
- Closed
-
ralf.gebhardt, sure - here's how to do it.
Suppose we have a table src on a remote server, and we want to copy its content to an innodb table dst on the local server using spider.
Let's say the src table has the following schema: (c INT, d DATE, PRIMARY KEY(c)).
First, create the dst table with the same schema if it does not already exist:
Then, create a spider table t with both src and dst as HA data nodes. Also ensure spider_same_server_link because t and src are on the same server (assuming the src is on SERVER s1 and the local server is defined to be SERVER s2):
Finally, copy data from src to dst using spider_copy_tables:
I've also added a testcase which I'll push as a "fix" for this issue once it is reviewed.