MTR test Automation Techniques

In this blog i am going to talk about couple of techniques how to automate certain MTR testcases,

these techniques are really underlying inside the suites and they never got exposed much to the test members. In case he/she wants to make use of these techniques for writing MTR testcase. One should really invest time and search from the existing suites.


My effort here is to bring up such techniques and consolidate them as a single reference for the end user.I will also keep updating this blog whenever i find something interesting.

The Viewers also can keep posting to this blog.

Technique 1:


The following sample code describes how to pass a value from MTR to perl

#Set the value of the variable in MTR
let  x=100;

#Get the value into perl & print
perl;

my $var1 = $ENV{'x'};
print "var1 = $var1 \n";

EOF

Technique 2:


The following sample code describes how to pass a value vice versa (Perl to MTR).Here it is not straight forward like above mentioned, hence store the value into a temp file and use source command to bring into MTR, and finally cleanup the temp file.

#Set the value of variable in the perl
perl;
 my $dir = $ENV{'MYSQLTEST_VARDIR'};
 open ( OUTPUT, ">$dir/tmp/tar.inc") ;
 print OUTPUT "let \$stat = 100;\n";
 close (OUTPUT);
EOF

#Get the value of the variable from to MTR, from perl
--source  $MYSQLTEST_VARDIR/tmp/tar.inc

#Print the value in MTR
--echo $stat

#Remove the temp file
--remove_file $MYSQLTEST_VARDIR/tmp/tar.inc

Technique 3:

Assume that, there are 2 DATADIR locations old and new are existing, in case user wants to star the DB server with new DATADIR location and do some testing during MTR test execution. Here is the sample code

1. Stop the server which was running with old DATADIR
2. Restrat the DB server with new DATADIR

Following sample code describes how to start from new location.

#Stop server with old location
-- exec echo "wait" > $MYSQLTEST_VARDIR/tmp/mysqld.1.expect
-- shutdown_server 30
-- source include/wait_until_disconnected.inc

#Restart the DB server from new location
-- exec echo "restart: --datadir=$MYSQL_TMP_DIR/mysqld.new/data/ " > $MYSQLTEST_VARDIR/tmp/mysqld.1.expect
-- enable_reconnect
-- source include/wait_until_connected_again.inc

Note: all DATA files should exist under new location otherwise DB startup will fail.

Remote & Transportable tablespace usage scenario.

Remote Tablespace:
In my previous blog ,we talked about the how to create a Remote tablespace . You may be thinking that, how this feature is really helpful for the user, just by mentioning the absolute path along with Create statement.

Assume a situation like, You had already created a table and it was grown to so big enough, now you wanted move that tablespace to some other location from the default location. due to various reasons like no disk space or high performance devices like SDD.

steps to move the tablespace file:
In the following example the default and new location are assumed as follows.

Default MySQL DATADIR is : /work/default/mysql/db1/
New location is : '/work/new/mysql/test'

1) stop the DB server
2) create an isl file (text file) with the same name as table and with extension called 'isl' (tab1.isl), mention the new location of the tab1.ibd file as
 '/work/new/mysql/test/tab1.ibd'
Note: Put  this file in the same location where the tab1.frm file lies.(default location).
3) move the tab1.ibd file to new location /work/new/mysql/test/ , from the old location
4) Restart the DB server
5) Now the table is ready for DML operations.
Note: Move the tablespace file tab1.ibd file cautiously as it is user responsibility of placing the right version of the file.

Conclusion:
Many DB's architectures are like that , it will not allow user to move the user tablespace files alone, freely to new location once the DB instance and tablespace files have been created, because, the biggest problem is recovery,
and also the tablespace files are tightly coupled with DB instance.Even if the files are moved, DBA's has to modify the system tables accordingly.which is not advisable at all.

will talk about the usage of transportable tablespace later.......

Remote Tablespace & Transportable tablespace of MySQL

Before talk about the Remote & transportable tablespace. Lets talk about the MySQL DB tablespace concepts.

MySQL consists of 2 kinds of tablespaces, system tablespace and user tablespace.

The system tablespace works same way as any other databases. one can ADD/DROP as many as DATAFILES from the system tablespace.

But the user tablespace architecture is entire different from other databases. Each user table would associate with one DATAFILE and One Format file, and the datafile will have the extension of .ibd and the format file will have the extension of .frm. The frm file would contain the structure of the table.And these files will be located in the default MySQL DATADIR location.

The following example will clearly explain you about the ibd and frm files.

When user execute the following DDL , it would create 2 files in the default DATADIR location of the DB instance.

CREATE TABLE tab(c1 int) ;
tab.frm -----> This is a format file (definition file)
tab.ibd -----> This is a datafile

Remote tablespace:
When user wants to create a table in different location than the Default location.User will have to mention the DDL with the location (absolute path) .

CREATE TABLE tab(c1 int) DATA DIRECTORY '/x/y';

Transportable tablespace:
Moving or copying the tablespace files (data file)  from one location to other location.

Note : Assuming innodb_file_per_table=ON (Default).

Now lets talk about how flexible these user tablespace files.

* The ibd file can be created either in the Default location or in the remote location on the same machine.
* Move the ibd files from old location to the new location,when the disk is full.
* Move/copy From One Database instance to another database instance when the DB servers are UP and running.
* Supports recovery from media.
* Faster than the traditional backup methods like logical & physical backup methods.
* Alter table Import tablespace.
* Alter table discard tablespace.
* Great flexibility and user friendly for moving/copying the tables.

Conclusion:
Remote tablespace and transportable tablepsace are the one of the greatest features of MySQL, supported in 5.6. I strongly believe that, this feature would give great advantage to the users during DB administration.

Will talk about more on how the remote & transportable tablespace usage  in my next blog.