How To Convert VMWare Image (.vmdk) to VirtualBox Image (.vdi) on Linux

QEMU is free software written by Fabrice Bellard that implements a fast processor emulator, allowing a user to run one operating system within another one. It is similar to projects such as Bochs and VMware Workstation
First we need to install QEMU
# yum install qemu
Now using qemu, first we need to convert a .vmdk (VMware image) to a .bin format, which can then be converted to a Virtualbox native .vdi format.
# qemu-img convert /path/to/original.vmdk converted.bin
VirtualBox is a free, powerful and versatile virtualization program which is available for Linux, Mac, and Windows hosts, and can virtualize many different Operating Systems.
VirtualBox was originally developed by Innotek, but was purchased by Sun and renamed Sun xVM VirtualBox.
Now using VBoxManage utility that comes with Virtualbox we can easily convert the .bin file that we have generated using qemu to a native .vdi format:
#VBoxManage convertdd converted.bin converted.vdi

Basic MySQL performance tuning using Query Cache

The query cache stores the text of a SELECT statement together with the corresponding result that was sent to the client. If an identical statement is received later, the server retrieves the results from the query cache rather than parsing and executing the statement again. The query cache is shared among sessions, so a result set generated by one client can be sent in response to the same query issued by another client.
The query cache can be useful in an environment where you have tables that do not change very often and for which the server receives many identical queries. This is a typical situation for many Web servers that generate many dynamic pages based on database content.
NOTE: The query cache always contains current and reliable data. Any insert, update, delete, or other modification to a table causes any relevant entries in the query cache to be flushed.
Query Cache Configuration:
To set the size of the query cache, set the query_cache_size system variable.
For the query cache to actually be able to hold any query results, its size must be set larger:
                   mysql> SET GLOBAL query_cache_size = 1000000;
If the query cache size is greater than 0, the query_cache_type variable influences how it works. This variable can be set to the following values:
0 or OFF prevents caching or retrieval of cached results.
1 or ON enables caching except of those statements that begin with SELECT SQL_NO_CACHE.
2 or DEMAND causes caching of only those statements that begin with SELECT SQL_CACHE.
                   mysql> SET SESSION query_cache_type = ON;
Using Select statement using Query Cache:
SQL_CACHE: The query result is cached if it is cacheable and the value of the query_cache_type system variable is ON or DEMAND.
SQL_NO_CACHE: The query result is not cached.
Examples:
                  SELECT SQL_CACHE id, name FROM customer;
                  SELECT SQL_NO_CACHE id, name FROM customer;
Setting the GLOBAL query_cache_type value determines query cache behavior for all clients that connect after the change is made. Individual clients can control cache behavior for their own connection by setting the SESSION query_cache_type value.

How to Import / Export (Backup / Restore) MySQL Database

It is important to back up your databases so that you can recover your data and be up and running again in case problems occur. MySQL offers a variety of backup strategies from which you can choose the methods that best suit the requirements for your installation.
Export / Backup MySQL database: 
The mysqldump client can be used to dump a database or a collection of databases for backup or for transferring the data to another SQL server (not necessarily a MySQL server). The dump contains SQL statements to create the table and/or populate the table.
If you are doing a backup on the server, and your tables all are MyISAM tables, you could consider using the mysqlhotcopy instead since faster backups and faster restores can be accomplished with the latter
Here is the most simple way to export the database to a sql file
      # mysqldump -u USER -p DATABASE > FILENAME.sql
USER is the MySQL admin user
DATABASE is the name of the database that need to be exported
FILENAME.sql is the name of the file where your data will be exported
When you issue this command you will be prompted for the MySQL admin password. Enter that password and hit the Enter key. In the directory you issued the command you will now have a file with the FILENAME.sql file you then need to copy to your secure drive.
You can dump all databases by doing:
      # mysqldump -u root -p --all-databases > all_dbs.sql
Import/Restore MySQL database:
Below is the simple command through which you can restore / import the already exported MySQL database file (.sql)
     # mysql -u USER -p DATABASE < FILENAME.sql
USER is the MySQL admin user
DATABASE is the name of the database where data need to be imported / restore
FILENAME.sql is the dump that was exported.
You will be prompted for the MySQL administrator password.

iSCSI setup on Red Hat / CentOS 5.x

So you have huge volumes of storage on your iSCSI SAN storage array and you want to use the volumes on Red Hat Enterprise Linux 5.x or CentOS 5.x
First install the Open-iSCSI initiator utils:

# yum -y install iscsi-initiator-utils

Edit /etc/iscsi/iscsid.conf and set your username and password, only if you use CHAP authentication to your iSCSI service.
Most likely, you will have to allow access to the iSCSI volume on the array, so log into your NAS admin interface and authorize your Linux host either by username, IP, or initiator name. You can find your Linux host's initiator name in: 
/etc/iscsi/initiatorname.iscsi

Set iscsi to start on boot, and start it now:

# chkconfig iscsid on ; service iscsid start
# chkconfig iscsi on ; service iscsi start

Use iscsiadm to discover your iSCSI targets, replacing the IP with your own portal IP:

# iscsiadm -m discovery -t st -p 192.168.1.123

Once discovery tells you the target names, log into the one you want to work with:

# iscsiadm -m node -T iqn.2123-01.com:blah:blah:blah -p 192.168.1.123 -l

If you want to automatically login at boot:

# iscsiadm -m node -T iqn.2123-01.com:blah:blah:blah -p 192.168.1.123 -o update -n node.startup -v automatic

Now the iSCSI volume should be detected by your system as a block device. You can check what device it was detected as by tailing your log.

# tail -n 50 /var/log/messages

Let's assume that the block device was detected as /dev/sdd. We will have to partition and format our filesystem at this point. You can either use a straight Linux partition, or you can use Linux Volume Management. I prefer LVM because it allows for more flexibility, including easy volume growth. You must use LVM if your device will be over 2TB, which is a limitation of regular Linux partitions.
For LVM, we will Initialize the block device as a physical volume, create a volume group, create a logical volume and format it as ext3. Note that with LVM, you do not use fdisk/parted or create the sdd1 partition:

# pvcreate /dev/sdd
# vgcreate SANVolGroup01 /dev/sdd
# lvcreate --extents 100%VG --name SANLogVol01 SANVolGroup01
# mkfs -t ext3 -m 1 -L mysan1 -O dir_index,filetype,has_journal,sparse_super /dev/SANVolGroup01/SANLogVol01
# mount /dev/SANVolGroup01/SANLogVol01 /mnt/san01

For a simple Linux partition, instead of LVM, we will create a new partition on the block device and then format it as ext3:

# parted -s -- /dev/sdd mklabel gpt
# parted -s -- /dev/sdd mkpart primary ext3 1 -1
# mkfs -t ext3 -m 1 -L mysan1 -O  dir_index,filetype,has_journal,sparse_super /dev/sdd1
# mount /dev/sdd1 /mnt/san01

iSCSI fstab entries require the "_netdev" option, so there is not an attempt to mount until networking is enabled. Mounting by label is also a good option, as devices may be detected at boot in different orders.
 More info at
 http://www.open-iscsi.org/docs/README

How to Change MySQL Storage Engines

MySQL 5.0 and higher offers nine storage engines and more are likely to be added in the future. The most commonly used are MyISAM, InnoDB, and Berkeley DB (BDB). Each storage engine offers special features and advantages. You can even use different formats for each table in your database, though it may be harder to manage a mixed format database. Better is to keep all tables in a database using the same storage engine, but use different engines for different databases.
To determine which storage engines your server supports, run following SHOW ENGINES; statement. The value in the Support column indicates whether an engine can be used. A value of YES, NO, or DEFAULT indicates that an engine is available, not available, or available and currently set as the default storage engine.
MyISAM: 
The default MySQL storage engine and the one that is used the most in Web, data warehousing, and other application environments. MyISAM is supported in all MySQL configurations, and is the default storage engine unless you have configured MySQL to use a different one by default. MyISAM is designed with the idea that your database is queried far more than its updated and as a result it performs very fast read operations.
InnoDB: 
A transaction-safe (ACID compliant) storage engine for MySQL that has commit, roll-back, and crash-recovery capabilities to protect user data. InnoDB row-level locking (without escalation to coarser granularity locks) and Oracle-style consistent non-locking reads increase multi-user concurrency and performance.
Convert from one type of engine to other.
When you create a new table, you can specify which storage engine to use by adding an ENGINE or TYPE table option to the CREATE TABLE statement:
                             > CREATE TABLE t (i INT) ENGINE = INNODB;
                             > CREATE TABLE t (i INT) TYPE = MYISAM;
To convert a table from one storage engine to another, use an ALTER TABLE statement that indicates the new engine:
                             > ALTER TABLE t ENGINE = MYISAM;
                             > ALTER TABLE t TYPE = INNODB;
The above statement would change your MySQL storage Engine.
NOTE: Dont’ forget that it takes a lot of computer resource to convert large tables.