joshuaprunier / trite Goto Github PK

Depending on version. innodb_expand_import must be set instead of innodb_import_table_from_xtrabackup. Looks like this flag was renamed in Percona Server 5.5

http://www.percona.com/doc/percona-server/5.5/management/innodb_expand_import.html

Gzip compression for XtraBackup file transfers. Should speed up transfers when used on slower networks.

Certain table names (such as all numerics) require back ticks to properly interact with. This is mainly in the applyTables() function but double check if back tick quotes are needed elsewhere.

Expand Table Import seems to be no more needed with Percona server 5.6.
I think it should be trivial to add support for Percona server 5.6

What MySQL calls "national letters" are encoded in the MySQL datadir and by Percona Xtrabackup. For example a schema or table named "Ω" becomes "@7p".

http://dev.mysql.com/doc/refman/5.5/en/identifier-mapping.html

Executing dump command with trite causes this error message

TLS encryption requested but server does not support TLS

I am not sure what this error is due and how to fix it.

May be difficult to implement but would remove the burden on the user to set the number of workers. Many factors determine the optimal number of workers that should be used. This is a long term goal that may never be attempted.

os.Rename() can not be used to rename a file onto another partition. Copying the file would decrease speed so I think the best solution is to simply download the database files to their destination schema. This will prevent an error when schemas are symbolically linked to a different device.

It will not prevent problems if tables within the same schema are linked to different devices. This should be noted as a limitation.

There needs to be proper clean up if an error is detected so large orphaned files do not remain on disk.

When there is an error during the process, for example a syntax error, it could be tricky to find which table script is involved.

This is possible in MySQL/Percona Server 5.6+ and MariaDB 10+. Server code will greatly increase. Think about if a structure dump should still be used for customized restore. Possibly add the ability to bypass structure dump and just copying everything in a live db. Though then you need to deal with issues like tables being added/dropped during processing.

https://dev.mysql.com/doc/en/innodb-transportable-tablespace-examples.html

Items to think about:
-Locking tables for export. Appears only a single table may be exported at a time or in batch. If table a is being exported table b can not also be exported. Needs further investigation and testing.
-Timeouts & retry if a table is scheduled to be exported but in use.
-Can a database be active and serve queries while trite is copying tablespaces or is it too difficult and the database should be put in read only mode, all tables flushed for export, etc.
-Compression should probably changed to configurable so some cpu can be reserved for tablespace reimport on the sever and other database operations.
-Source database credentials need to be checked for proper permissions before starting. Also need the ability to provide different credentials to trite server db and client db.

While seldom observed currently the code will exit when a transfer fails. This requires starting the transfer over from the beginning. Implementing better throttling logic based on channels should allow failed transfers to be detected and retried.

Under certain conditions xtrabackup does not create a .exp for a table during export. This causes an invalid .exp file to be used during import and corrupts the tablespace. Check that the .exp file exists on the trite server, omit from download & import if it is missing and log an error.

Only apply objects based on replication filters that are set. Wilcard filters appear too difficult to implement and will probably not be support.