Nov
01
2017
--

Percona Server for MongoDB 3.2.17-3.8 Is Now Available

Percona Server for MongoDB 3.4

Percona Server for MongoDB 3.2Percona announces the release of Percona Server for MongoDB 3.2.17-3.8 on October 31, 2017. Download the latest version from the Percona web site or the Percona Software Repositories.

Percona Server for MongoDB is an enhanced, open-source, fully compatible, highly scalable, zero-maintenance downtime database that supports the MongoDB v3.2 protocol and drivers. It extends MongoDB with MongoRocksPercona Memory Engine and PerconaFT storage engine, as well as enterprise-grade features like External Authentication, Audit Logging, Profiling Rate Limiting, and Hot Backup at no extra cost. The software requires no changes to MongoDB applications or code.

NOTE: The PerconaFT storage engine is deprecated as of 3.2. It is no longer supported and isn’t available in higher version releases.

This release is based on MongoDB 3.2.17 and does not include any additional changes.

The Percona Server for MongoDB 3.2.17-3.8 release notes are available in the official documentation.

Sep
27
2017
--

Percona Server for MongoDB 3.2.16-3.7 Is Now Available

Percona Server for MongoDB 3.2

Percona Server for MongoDB 3.2Percona announces the release of Percona Server for MongoDB 3.2.16-3.7 on September 27, 2017. Download the latest version from the Percona web site or the Percona Software Repositories.

Percona Server for MongoDB is an enhanced, open-source, fully compatible, highly scalable, zero-maintenance downtime database that supports the MongoDB v3.2 protocol and drivers. It extends MongoDB with MongoRocksPercona Memory Engine and PerconaFT storage engine, as well as enterprise-grade features like External Authentication, Audit Logging, Profiling Rate Limiting, and Hot Backup at no extra cost. The software requires no changes to MongoDB applications or code.

NOTE: The PerconaFT storage engine is deprecated as of 3.4. It is no longer supported and isn’t available in higher version releases.

This release is based on MongoDB 3.2.16 and includes the following additional changes:

  • #PSMDB-164: Fixed MongoRocks failure to repair if database metadata is inconsistent with dropped collections and indexes.
  • Added packages for Debian 9 (“stretch”).

The Percona Server for MongoDB 3.2.16-3.7 release notes are available in the official documentation.

Jul
26
2017
--

Percona Server for MongoDB 3.2.15-3.5 is Now Available

Percona Server for MongoDB 3.2

Percona Server for MongoDB 3.2Percona announces the release of Percona Server for MongoDB 3.2.15-3.5 on July 26, 2017. Download the latest version from the Percona web site or the Percona Software Repositories.

Percona Server for MongoDB is an enhanced, open-source, fully compatible, highly scalable, zero-maintenance downtime database that supports the MongoDB v3.2 protocol and drivers. It extends MongoDB with MongoRocks, Percona Memory Engine, and PerconaFT storage engine, as well as enterprise-grade features like External Authentication, Audit Logging, Profiling Rate Limiting, and Hot Backup at no extra cost. The software requires no changes to MongoDB applications or code.

NOTE: We deprecated the PerconaFT storage engine. It will not be available in future releases.

This release is based on MongoDB 3.2.15 and does not include any additional changes.

Percona Server for MongoDB 3.2.15-3.5 release notes are available in the official documentation.

Jul
17
2017
--

Percona Server for MongoDB 3.2.14-3.4 is Now Available

Percona Server for MongoDB 3.2

Percona Server for MongoDB 3.2.14-3.4Percona announces the release of Percona Server for MongoDB 3.2.14-3.4 on July 17, 2017. Download the latest version from the Percona web site or the Percona Software Repositories.

Percona Server for MongoDB is an enhanced, open-source, fully compatible, highly scalable, zero-maintenance downtime database that supports the MongoDB v3.2 protocol and drivers. It extends MongoDB with MongoRocks, Percona Memory Engine, and PerconaFT storage engine, as well as enterprise-grade features like External Authentication, Audit Logging, Profiling Rate Limiting, and Hot Backup at no extra cost. Percona Server for MongoDB requires no changes to MongoDB applications or code.

NOTE: This release deprecates the PerconaFT storage engine. It will not be available in future releases.

This release is based on MongoDB 3.2.14 and includes the following additional changes:

New Features

Bugs Fixed

  • #PSMDB-67: Fixed mongod service status messages.

Percona Server for MongoDB 3.2.14-3.4 release notes are available in the official documentation.

May
26
2017
--

Percona Server for MongoDB 3.0.15-1.10 is Now Available

Percona Server for MongoDB 3.2

Percona Server for MongoDB 3.0Percona announces the release of Percona Server for MongoDB 3.0.15-1.10 on May 26, 2017. Download the latest version from the Percona web site or the Percona Software Repositories.

Percona Server for MongoDB is an enhanced, open source, fully compatible, highly-scalable, zero-maintenance downtime database supporting the MongoDB v3.0 protocol and drivers. It extends MongoDB with PerconaFT and MongoRocks storage engines, as well as several enterprise-grade features:

NOTE: PerconaFT was deprecated and is not available in later versions. TokuBackup was replaced with Hot Backup for WiredTiger and MongoRocks storage engines.

Percona Server for MongoDB requires no changes to MongoDB applications or code.

This release is based on MongoDB 3.0.15 and includes the following additional change:

Percona Server for MongoDB 3.0.15-1.10 release notes are available in the official documentation.

May
15
2017
--

Percona Server for MongoDB 3.2.13-3.3 is Now Available

Percona Server for MongoDB 3.2

Percona Server for MongoDB 3.2Percona announces the release of Percona Server for MongoDB 3.2.13-3.3 on May 15, 2017. Download the latest version from the Percona web site or the Percona Software Repositories.

Percona Server for MongoDB is an enhanced, open-source, fully compatible, highly scalable, zero-maintenance downtime database supporting the MongoDB v3.2 protocol and drivers. It extends MongoDB with MongoRocks, Percona Memory Engine, and PerconaFT storage engine, as well as enterprise-grade features like External Authentication, Audit Logging, Profiling Rate Limiting, and Hot Backup at no extra cost. Percona Server for MongoDB requires no changes to MongoDB applications or code.

NOTE: We deprecated the PerconaFT storage engine. It will not be available in future releases.

This release is based on MongoDB 3.2.13 and includes the following additional changes:

  • #PSMDB-127: Fixed cleanup of deleted documents and indexes for MongoRocks. When you upgrade to this release, deferred compaction may occur and cause database size to decrease significantly.
  • #PSMDB-133: Added the wiredTigerCheckpointSizeMB variable, set to 1000 in the configuration template for WiredTiger. Valid values are 32 to 2048 (2GB), with the latter being default.
  • #PSMDB-138: Implemented SERVER-23418 for MongoRocks.

Percona Server for MongoDB 3.2.13-3.3 release notes are available in the official documentation.

Mar
09
2017
--

Percona Server for MongoDB 3.2.12-3.2 is now available

Percona Server for MongoDB

Percona Server for MongoDBPercona announces the release of Percona Server for MongoDB 3.2.12-3.2 on March 9, 2017. Download the latest version from the Percona web site or the Percona Software Repositories.

Percona Server for MongoDB 3.2.11-3.1 is an enhanced, open-source, fully compatible, highly scalable, zero-maintenance downtime database supporting the MongoDB v3.2 protocol and drivers. It extends MongoDB with MongoRocks, Percona Memory Engine, and PerconaFT storage engine, as well as enterprise-grade features like External Authentication, Audit Logging, Profiling Rate Limiting, and Hot Backup at no extra cost. Percona Server for MongoDB requires no changes to MongoDB applications or code.

NOTE: We deprecated the PerconaFT storage engine. It will not be available in future releases.

This release is based on MongoDB 3.2.12 and includes the following additional changes:

  • PSMDB-17: Changed welcome message in the shell to mention Percona Server for MongoDB instead of MongoDB
  • PSMDB-90: Added error message for storage engines that do not support Hot Backup
  • PSMDB-91: Deprecated audit configuration section and added auditLog instead
  • PSMDB-95: Fixed version dependencies for sub packages so that all corresponding packages get updated accordingly
  • PSMDB-96: Excluded diagnostic.data directory when using TokuBackup with PerconaFT
  • PSMDB-98: Improved Hot Backup to create destination folder if it does not exist
  • PSMDB-101: Implemented the auditAuthorizationSuccess parameter to enable auditing of authorization success
  • PSMDB-104: Updated links in client shell output to point to Percona’s documentation and forum
  • PSMDB-107: Fixed behavior when creating the audit log file
  • PSMDB-111: Refactored external_auth tests
  • PSMDB-123: Fixed the creation of proper subdirectories inside the backup destination directory
  • PSMDB-126: Added index and collection name to duplicate key error message
  • Fixed startup scripts for Ubuntu 14.04.5 LTS (Trusty Tahr)
  • Fixed a number of other small issues and bugs

Percona Server for MongoDB 3.2.12-3.2 release notes are available in the official documentation.

Nov
01
2016
--

The Future of TokuDB at Percona

TokuDB

TokuDBIn this blog post, I’ll discuss the future of TokuDB at Percona. Spoiler: solid.

As soon as we announced the fact that MyRocks was coming to Percona Server for MySQL at Percona Live Europe, rumors appeared that this means we’re going to phase out TokuDB at the same time.  

I can understand why those rumors would start: just a few months ago we deprecated Fractal Trees technology (called PerconaFT) in favor of MongoRocks and RocksDB for Percona Server for MongoDB.

As much as this might look like the same situation as with PerconaFT, TokuDB is very different. PerconaFT was actually a new port of Fractal Trees technology for MongoDB. It used the MongoDB storage engine API and focused on replacing TokuMX (a full fork of an earlier version of MongoDB). PerconaFT was new, and MongoRocks was already well-established and battle-tested by Parse. The MongoDB internal design was also much more friendly towards the RocksDB storage engine than Fractal Trees technology (as David Murphy explains here).    

Our research revealed that PerconaFT had very few current users, and MongoRocks was a superior choice for new users. This is why we depreciated it.

For MySQL, TokuDB is a rather mature storage engine. It has been in production for more than five years and is trusted by many businesses and large enterprises (in industries ranging from banking and finance to gaming) for use with critical applications.

MyRocks however, with as much promise as it shows, has not been extensively battle-tested outside of Facebook. And as it is hard to beat “Facebook scale,” it hasn’t exposed its performance under a large variety of workloads. There are also some known limitations in MyRocks that need work.

Ultimately though, I believe MyRocks has a great future, and we at Percona are going to take part in making this future reality. But this does not mean we plan to immediately abandon TokuDB, or place it on “life support”.    

You can see new development going on for TokuDB: we have dramatically improved block allocation performance and added a new, more convenient TokuDB file layout option. We are also working on adding support for new compression algorithms in TokuDB, support for Performance Schema and refactoring the checkpoint process to ensure uniform performance on all workloads. It is true TokuDB is not changing as rapidly as RocksDB, but that is to be expected – as the more mature storage engine, it should embrace stability first and foremost.

Our overall principle at Percona is to keep our ego in check. We want to provide the best open source ecosystem solutions available to our customers, whether they were developed in-house or not. This means that within 3-5 years MyRocks could possibly be superior to TokuDB in functionality and performance for all imaginable workloads. Or an even better open source storage engine technology might get developed and come to market. If or when this happens, we will consider depreciating TokuDB in favor of such technology – while providing the customers with enough notice, tools and support to ensure they can successfully migrate.

What this really means is that TokuDB is still being actively supported and developed for at least Percona Server 5.7 and Percona Server 8.0 (and longer). We will continue this as long as a reasonable use case remains for this technology.

Please feel free to contact us with any questions, or add them in the comments below.

Oct
28
2016
--

New TokuDB and PerconaFT database file management feature in Percona Server 5.6.33-79.0 and Percona Server 5.7.15-9

TokuDB and PerconaFT database file management

TokuDB and PerconaFT database file managementThis blog post discusses a new TokuDB and PerconaFT database file management feature in two Percona Server releases.

By now you have hopefully read through Peter’s post and my two prior posts on the TokuDB/PerconaFT file set. If you have not, it is probably a good idea to run through them now before we get into the details of this new feature.

We introduced a new server option beginning in Percona Server 5.6.33-79.0 and Percona Server 5.7.15-9, called tokudb_dir_per_db, that addresses two shortcomings within the current TokuDB implementation:

  • The renaming of data files on table/index rename
  • The ability to group data files together within a directory that represents a single database.

The new option is disabled by default in 5.6.33-79.0, but will be enabled by default beginning in 5.7.15-9


New table renaming functionality

When you rename a TokuDB table via SQL, the data files on disk keep their original names. Only the mapping in the PerconaFT directory file is changed to map the new dictionary name to the original internal file names. This makes it difficult to quickly match database/table/index names to their actual files on disk, requiring you to use the INFORMATION_SCHEMA.TOKUDB_FILE_MAP to cross reference.

When tokudb_dir_per_db is enabled, this is no longer the case. When you rename a table, the mapping in the PerconaFT directory file will be updated, and the files will be renamed on disk to reflect the new table name. This was a lot more difficult to implement than we originally thought due to the non-transactional nature of the underlying file systems. We had to “invent” a transactional file system rename functionality within PerconaFT to ensure that a crash during a file system mv src dst was recoverable.


New directory layout functionality

Many users have had issues with managing the huge volume of individual files used by TokuDB and PerconaFT. We are beginning to take some steps to help improve the manageability of these files, and potentially even reduce the number of files present.

When you enable tokudb_dir_per_db, all new tables and indices are placed within their corresponding database directory within the tokudb_data_dir or system datadir. Existing table files will not be automatically relocated to their corresponding database directory.

You can easily move a table’s data files into the new scheme and proper database directory with a few steps:

mysql> SET GLOBAL tokudb_dir_per_db=true;
mysql> RENAME TABLE <table> TO <tmp_table>;
mysql> RENAME TABLE <tmp_table> TO <table>;

Two renames are needed because MySQL will not allow you to rename a table to itself. The first rename renames the table to the temporary name and mv‘s the tables files into the owning database directory. The second rename sets the table name back to the original name. Tables can, of course, also be renamed/moved across databases and will be placed correctly into the corresponding database directory.

You must be careful with renaming tables! If you have used any tricks to create symlinks of the database directories on different storage volumes, the mv is not a simple directory mv on the same volume, but a physical copy across volumes. This can take quite some time and prevents access to the table being moved during the copy.

NOTE: If you have tokudb_data_dir set to something other than the system datadir, TokuDB creates a directory matching the name of the database. Upon dropping of the database, this directory remains behind.


Example:

While running Percona Server 5.7.15-9 with tokudb_dir_per_db=false to illustrate the old behavior, create a table t1, show the file map, and list the data directory:

mysql> SET GLOBAL tokudb_dir_per_db=false;
Query OK, 0 rows affected (0.00 sec)
mysql> DROP DATABASE IF EXISTS test; CREATE DATABASE test; USE test;
Query OK, 0 rows affected (0.00 sec)
Query OK, 1 row affected (0.00 sec)
Database changed
mysql> CREATE TABLE t1(a INT PRIMARY KEY, b INT, c VARCHAR(200), KEY kab(a, b)) ENGINE=TOKUDB;
Query OK, 0 rows affected (0.07 sec)
mysql> SELECT * FROM INFORMATION_SCHEMA.TOKUDB_FILE_MAP;
*************************** 1. row ***************************
      dictionary_name: ./test/t1-key-kab
   internal_file_name: ./_test_t1_key_kab_de_3_1d.tokudb
         table_schema: test
           table_name: t1
table_dictionary_name: key-kab
*************************** 2. row ***************************
      dictionary_name: ./test/t1-main
   internal_file_name: ./_test_t1_main_de_2_1d.tokudb
         table_schema: test
           table_name: t1
table_dictionary_name: main
*************************** 3. row ***************************
      dictionary_name: ./test/t1-status
   internal_file_name: ./_test_t1_status_de_1_1d.tokudb
         table_schema: test
           table_name: t1
table_dictionary_name: status
3 rows in set (0.00 sec)

$ ls -1 data/*.tokudb
data/_test_t1_key_kab_de_3_1d.tokudb
data/_test_t1_main_de_2_1d.tokudb
data/_test_t1_status_de_1_1d.tokudb

We see the data files for our table t1 as the three files _test_t1_*

Rename t1 to all_the_kings_horses, show the file map again, and another listing of the data directory:

mysql> RENAME TABLE t1 TO all_the_kings_horses;
Query OK, 0 rows affected (0.01 sec)
mysql> SELECT * FROM INFORMATION_SCHEMA.TOKUDB_FILE_MAP;
*************************** 1. row ***************************
      dictionary_name: ./test/all_the_kings_horses-key-kab
   internal_file_name: ./_test_t1_key_kab_de_3_1d.tokudb
         table_schema: test
           table_name: all_the_kings_horses
table_dictionary_name: key-kab
*************************** 2. row ***************************
      dictionary_name: ./test/all_the_kings_horses-main
   internal_file_name: ./_test_t1_main_de_2_1d.tokudb
         table_schema: test
           table_name: all_the_kings_horses
table_dictionary_name: main
*************************** 3. row ***************************
      dictionary_name: ./test/all_the_kings_horses-status
   internal_file_name: ./_test_t1_status_de_1_1d.tokudb
         table_schema: test
           table_name: all_the_kings_horses
table_dictionary_name: status
3 rows in set (0.00 sec)

$ ls -1 data/*.tokudb
data/_test_t1_key_kab_de_3_1d.tokudb
data/_test_t1_main_de_2_1d.tokudb
data/_test_t1_status_de_1_1d.tokudb

The file names remained the same as the original table, but the file map has changed to reflect the new table/dictionary names.

Let us inject a little confusion by adding another index to the table:

mysql> alter table all_the_kings_horses add index kac(a,c);
Query OK, 0 rows affected (0.08 sec)
Records: 0  Duplicates: 0  Warnings: 0
mysql> SELECT * FROM INFORMATION_SCHEMA.TOKUDB_FILE_MAP;
*************************** 1. row ***************************
      dictionary_name: ./test/all_the_kings_horses-key-kab
   internal_file_name: ./_test_t1_key_kab_de_3_1d.tokudb
         table_schema: test
           table_name: all_the_kings_horses
table_dictionary_name: key-kab
*************************** 2. row ***************************
      dictionary_name: ./test/all_the_kings_horses-key-kac
   internal_file_name: ./_test_all_the_kings_horses_key_kac_e3_3_1d_B_0.tokudb
         table_schema: test
           table_name: all_the_kings_horses
table_dictionary_name: key-kac
*************************** 3. row ***************************
      dictionary_name: ./test/all_the_kings_horses-main
   internal_file_name: ./_test_t1_main_de_2_1d.tokudb
         table_schema: test
           table_name: all_the_kings_horses
table_dictionary_name: main
*************************** 4. row ***************************
      dictionary_name: ./test/all_the_kings_horses-status
   internal_file_name: ./_test_t1_status_de_1_1d.tokudb
         table_schema: test
           table_name: all_the_kings_horses
table_dictionary_name: status
4 rows in set (0.00 sec)

$ ls -1 data/*.tokudb
data/_test_all_the_kings_horses_key_kac_e3_3_1d_B_0.tokudb
data/_test_t1_key_kab_de_3_1d.tokudb
data/_test_t1_main_de_2_1d.tokudb
data/_test_t1_status_de_1_1d.tokudb

The file for the new index kac was created with the current table name, not the original.

Now we move on to the new behavior. First make sure that tokudb_dir_per_db=true, then rename the table again, show the file map, and do another directory listing:

mysql> SET GLOBAL tokudb_dir_per_db=true;
Query OK, 0 rows affected (0.00 sec)
mysql> RENAME TABLE all_the_kings_horses TO all_the_kings_men;
Query OK, 0 rows affected (0.02 sec)
mysql> SELECT * FROM INFORMATION_SCHEMA.TOKUDB_FILE_MAP;
*************************** 1. row ***************************
      dictionary_name: ./test/all_the_kings_men-key-kab
   internal_file_name: ./test/all_the_kings_men_key_kab_ea_2_1d.tokudb
         table_schema: test
           table_name: all_the_kings_men
table_dictionary_name: key-kab
*************************** 2. row ***************************
      dictionary_name: ./test/all_the_kings_men-key-kac
   internal_file_name: ./test/all_the_kings_men_key_kac_ea_3_1d.tokudb
         table_schema: test
           table_name: all_the_kings_men
table_dictionary_name: key-kac
*************************** 3. row ***************************
      dictionary_name: ./test/all_the_kings_men-main
   internal_file_name: ./test/all_the_kings_men_main_ea_4_1d.tokudb
         table_schema: test
           table_name: all_the_kings_men
table_dictionary_name: main
*************************** 4. row ***************************
      dictionary_name: ./test/all_the_kings_men-status
   internal_file_name: ./test/all_the_kings_men_status_ea_5_1d.tokudb
         table_schema: test
           table_name: all_the_kings_men
table_dictionary_name: status
4 rows in set (0.00 sec)

$ ls -1 data/test/*.tokudb
data/test/all_the_kings_men_key_kab_ea_2_1d.tokudb
data/test/all_the_kings_men_key_kac_ea_3_1d.tokudb
data/test/all_the_kings_men_main_ea_4_1d.tokudb
data/test/all_the_kings_men_status_ea_5_1d.tokudb

The database files have now been renamed to properly match the name of the database, table and keys, and they have been moved into the data/test directory.

Now let us watch all that action with an alternate tokudb_data_dir. Rather than showing how to move files around as mentioned in the previous blog posts, we will just reset our TokuDB installation and start the server with a different tokudb_data_dir that is a sibling to the server datadir, called tokudb_data.

mysql> SET GLOBAL tokudb_dir_per_db=true;
Query OK, 0 rows affected (0.00 sec)
mysql> DROP DATABASE IF EXISTS test; CREATE DATABASE test; USE test;
Query OK, 0 rows affected, 1 warning (0.00 sec)
Query OK, 1 row affected (0.00 sec)
Database changed
mysql> CREATE TABLE t1(a INT PRIMARY KEY, b INT, c VARCHAR(200), KEY kab(a, b)) ENGINE=TOKUDB;
Query OK, 0 rows affected (0.15 sec)
mysql> SELECT * FROM INFORMATION_SCHEMA.TOKUDB_FILE_MAP;
*************************** 1. row ***************************
      dictionary_name: ./test/t1-key-kab
   internal_file_name: /ssd/toku/DB-295/percona-server-install-5.7/tokudb_data/test/t1_key_kab_d9_3_1d.tokudb
         table_schema: test
           table_name: t1
table_dictionary_name: key-kab
*************************** 2. row ***************************
      dictionary_name: ./test/t1-main
   internal_file_name: /ssd/toku/DB-295/percona-server-install-5.7/tokudb_data/test/t1_main_d9_2_1d.tokudb
         table_schema: test
           table_name: t1
table_dictionary_name: main
*************************** 3. row ***************************
      dictionary_name: ./test/t1-status
   internal_file_name: /ssd/toku/DB-295/percona-server-install-5.7/tokudb_data/test/t1_status_d9_1_1d.tokudb
         table_schema: test
           table_name: t1
table_dictionary_name: status
3 rows in set (0.00 sec)

$ ls -1 tokudb_data/
test
__tokudb_lock_dont_delete_me_data
__tokudb_lock_dont_delete_me_temp
$ ls -1 tokudb_data/test/
t1_key_kab_d9_3_1d.tokudb
t1_main_d9_2_1d.tokudb
t1_status_d9_1_1d.tokudb

This shows us TokuDB now putting everything over in the directory we specified in our tokudb_data_dir, and is following the tokudb_dir_per_db paradigm by creating the directory called test before creating the table.

What happens when we drop that database?

mysql> drop database test;
Query OK, 1 row affected (0.02 sec)

$ ls -1 tokudb_data/
test
__tokudb_lock_dont_delete_me_data
__tokudb_lock_dont_delete_me_temp
$ ls -1 tokudb_data/test/

All of the tables files have been removed, but as mentioned above, the test still exists and needs to be removed manually.


Thanks for reading! We hope that you have found this blog series useful and look forward to hearing your experience with this new feature.

In the future we will investigate implementing the CREATE TABLE … DATA|INDEX DIRECTORY=… feature for TokuDB, which builds on top of this work.

We need to give a shout out to Vladislav Lesin, who took the lead on this issue and fought several battles in his attempt to ensure that this is fully crash safe and recoverable.

Oct
24
2016
--

TokuDB and PerconaFT Data Files: Database File Management Part 2 of 2

TokuDB and PerconaFT data files

TokuDB and PerconaFT data filesThis is the second installment of the blog series on TokuDB and PerconaFT data files. You can find my previous post here. In this post we will discuss some common file maintenance operations and how to safely execute these operations.


Moving TokuDB data (table/index) files to another location outside of the default MySQL datadir

TokuDB uses the location specified by the tokudb_data_dir variable for all of its data files. If you don’t explicitly set the tokudb_data_dir variable, TokuDB uses the location specified by the servers datadir for these files.

The the __tokudb_lock_dont_delete_me_data file, located in the same directory as the TokuDB data files, protects TokuDB data files from concurrent process access.

TokuDB data files can be moved to other locations, and symlinks left behind in their place. If those symlinks refer to files on other physical data volumes, the tokudb_fs_reserve_percent monitor will not traverse the symlink and monitor the real location for adequate space in the file system.

To safely move your TokuDB data files:

  1. Shut down the server cleanly.
  2. Change the tokudb_data_dir in your my.cnf to the location where you wish to store your TokuDB data files.
  3. Create your new target directory.
  4. Move your *.tokudb files and your __tokudb_lock_dont_delete_me_data from the current location to the new location.
  5. Restart your server.

Moving the TokuDB temporary files to another location outside of the default MySQL datadir

TokuDB uses the location specified by the tokudb_tmp_dir variable for all of its temporary files. If you don’t explicitly set the tokudb_tmp_dir variable, TokuDB uses the location specified by the tokudb_data_dir. If you don’t explicitly set the tokudb_data_dir variable, TokuDB uses the location specified by the servers datadir for these files.

The __tokudb_lock_dont_delete_me_temp file, located in the same directory as the TokuDB temporary files, protects the TokuDB temporary files from concurrent process access.

If you locate your TokuDB temporary files on a physical volume that is different from where your TokuDB data files or recovery log files are located, the tokudb_fs_reserve_percent monitor will not monitor their location for adequate space in the file system.

To safely move your TokuDB temporary files:

  1. Shut the server down cleanly. A clean shutdown will ensure that there are no temporary files that need to be relocated.
  2. Change the tokudb_tmp_dir in your my.cnf to the location where you wish to store your new TokuDB temporary files.
  3. Create your new target directory.
  4. Move your __tokudb_lock_dont_delete_me_temp file from the current location to the new location.
  5. Restart your server.

Moving TokuDB recovery log files to another location outside of the default MySQL datadir

TokuDB uses the location specified by the tokudb_log_dir variable for all of its recovery log files. If the tokudb_log_dir variable is not explicitly set, TokuDB uses the location specified by the servers datadir for these files.

The __tokudb_lock_dont_delete_me_logs file, located in the same directory as the TokuDB recovery log files, protects TokuDB recovery log files from concurrent process access.

TokuDB recovery log files can be moved to another location and a symlinks left behind in place of the tokudb_log_dir. If that symlink refers to a directory on another physical data volume, the tokudb_fs_reserve_percent monitor will not traverse the symlink and monitor the real location for adequate space in the file system.

To safely move your TokuDB recovery log files:

  1. Shut the server down cleanly.
  2. Change the tokudb_log_dir in your my.cnf to the location where you wish to store your TokuDB recovery log files.
  3. Create your new target directory.
  4. Move your log*.tokulog* files and your __tokudb_lock_dont_delete_me_logs file from the current location to the new location.
  5. Restart your server.

I hope this blog series is helpful. Another post discussing a long-awaited new feature to help you manage and organize your TokuDB data files is coming soon.

Powered by WordPress | Theme: Aeros 2.0 by TheBuckmaker.com