Friday, August 12, 2011

Use Google Apps for dual Deployment and Disaster Recover.

I have setup our Exchange Server, DNS Servers and Google Apps to Dual Deploy our email and to act as a secondary mail server.   In my opinion the best solution possible.

I looked at Google Apps before and didn't really see the potential.  Then my son in-law told me that you could use it and use your own domain with it and that got be thinking about the potential.  This is incredible.  You can have up to 50 users and each user can have 7 Gigs of space for emails.  That is more than I allow on our Exchange server.

Although I'm a big fan of MS Exchange I thought that maybe I could use Google Apps as a backup email in case Exchange fails.  I already have 1 Disaster Recovery solution in place.  I'm using Double-Take at a remote site to replicate our Exchange server.  Some would fill this is enough, but with Google Apps I have a complete solutions.

Here is what Google Apps offers me:

When our Exchange Server goes down and it does.  I don't have to fail over to the Disaster Recovery Site immediately.  Google Apps gives me time since the email will continue to flow to Google Apps we can continue to do business as usual.  I then have time to determine how serious the problem is, how long the Exchange server will be down and if we should fail over to our Exchange server at the Disaster Recovery Site.

I have a place for all the users email to be autoachive.  If they delete something on the Exchange server they can retrieve it on Google Server.

Here is how you setup Google Apps to Act as a Secondary email server and as an archive server.

1. You need to setup a Google Apps Account.  Choose the Standard Account if you have less than 50 users.  http://www.google.com/apps/intl/en/group/index.html
2. Once you enter your domain name or purchase the domain name then you need to verify that you are the administrator.  This can be a little tricky if you are using a production domain name.
3. Fortunately for me I have my own DNS servers so I was able to make the changes.  I used the html method to authenticate.   I setup my CNAME so that I could type docs.domain.com and it would go to the google docs website and I added the google MX host information to my MX records.  Now, you can either put them first and remove your current entry or you can get them the same values as your current email servers.  You will not be able to verify until Google see them as the top MX records.   I moved my current MX record to a higher value to verify my domain.  After my domain was verified I gave my current MX records a lower value so they were first.   For my sub-domain authentication I gave the google MX record the same value as my current MX records and google verified my sub-domain.
4.  Now I did the same thing to my internal DNS so that from my PC I could resolve the MX records from within my company.
5.  So in my CNAME I use that to give shorter URL to connect to my google sight.  The way I don't have to type the www.google.com/a/domainname.  Instead I can type email.domainname.com or docs.domainname.com.   In my MX records I have my subdomain that I setup at Google Apps with the same value as my MX records for my Exchange servers.  Ex:
@ mail.domainname.com. 10
gmailalias ASPMX.L.GOOGLE.COM.
@ mail2.domainname.com 20
gmailalias ALT1.ASPMX.L.GOOGLE.COM. 20

Don't forget your "." after FQDN

This provides the ability to use DUAL - Deployment by way of the Alias "gmailalias".  There are more steps to getting this to work.  I'll explain those below.


6. To get emails to go to my Google Apps email if exchange goes down you need to add Google to your MX record as secondary email servers.  Below the enters above I have the Google Apps MX records.  In other words, if Exchange goes down the next MX record will be used to delivery mail for "domainname.  I'm not talking about the alias emails.  I don't get emails coming to me with the alias domain, that is used to forward emails to my Google emails.  So in my case the next MX record for my "domainname" is "mail-Dr" with a value of 20.  Well, my "mail-DR" isn't setup to receive email only to receive replication and I would need to manually failover and start the services before I would receive any emails.  So then the next MX record would be the google account.  So here are the Google MX records.




http://www.google.com/support/a/bin/static.py?page=guide.cs&guide=22229&topic=22230

Monitor MySQL queries in Real Time

Just a quick tip on monitoring the queries that mysql is handling on a production site. You can use the mysqladmin tool to return a list of the processes currently being handled. Combining this with the UNIX watch command allows a real-time monitoring of what's going on.
watch -n 1 mysqladmin processlist
The "-n 1" specifies that mysqladmin executes every second. Depending on your set-up, you may need to specify a mysql user and password:
watch -n 1 mysqladmin --user= --password= processlist

LVM Snapshot script

LVM Snapshot script
Used for copying a MySQL schema to a test environment


There are so many ways to do this, but our need was to not have any production down time* and have the test database available ASAP.  

I wrote up a little how to and I thought I might share it so others could use it.  Like I said there are many ways to do this so just take a look and use the logic that works for you. 

A Method to copy Data to a test environment


This method will copy all data in a volume and MySQL a test environment with no downtime.  The method used could also be used for backing up data or replication.
Here are the steps needed to accomplish the copy to test.
1.       Add an additional hard drive for Storage. 
2.       Configure the disk using fdisk and then create a Physical Volume with the pvcreate command.*
3.       Add the Physical Volume to the VolGroup with the vgextend command.*
4.       Setup MySQL to run a second instance.*
5.       Run the this script.

#! /bin/sh

user=username
pwd=password
olddb=originalname
newdb=newname
socket=/tmp/mysql.sock2

#This will remove LVM and stop the second instance of MySQL .
mysqladmin -u$user -p$pwd --socket=$socket shutdown 
sleep 4
umount /dev/VolGroup01/databackup
lvremove -f /dev/VolGroup01/databackup

#This will flush mysql and Lock Tables and LVM snapshot (see below)**
mysql -u$user -p$pwd < lvm_snapshot

#At this point the volume and MySQL files have been copied

#This will will mount the LVM snapshot to /mnt/databackup
 mount -t ext3 /dev/VolGroup01/databackup  /mnt/databackup

#This will start the second instance of MySQL on port 3305
mysqld_multi start 2

#This is needed to allow enough time for MySQL to start and create the mysql.sock2 file
sleep 4

#This will login to the second instance of MySQL and rename the schema to dl4test. 
mysqlconn="mysql -u$user -p$pwd -S $socket -h localhost"

$mysqlconn -e "CREATE DATABASE $newdb"
params=$($mysqlconn -N -e "SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE table_schema='$olddb'")

for name in $params; do
      $mysqlconn -e "RENAME TABLE $olddb.$name to $newdb.$name"; done;

$mysqlconn -e "DROP DATABASE $olddb"

#This will grant user saitest access to the newdatabase schema
$mysqlconn -e "GRANT ALL PRIVILEGES ON newdatabase.* TO 'username'@'%' IDENTIFIED BY 'saitest'";

This script takes about 10 seconds to run and requires no down time in production.  
Note: the schema name change does not change any stored procedures so a script or logic would need to be added in order to create those after renaming the schema.

*More Information on Setup:
1.  Use fdisk to setup the disk. 
Type fdisk /dev/sdb1 (or whatever device your new hard drive is) and press Enter.  Then press, m,n,e(choose the defaults), p, and w to save the changes.  
2.  Create a Physical Volume.
Type “pvcreate /dev/sdb1”
3. Extend the Volume Group.
Type “vgextend VolGroup01 /dev/sdb1”

4. Add a second instance of MySQL.
Modify the /etc/my.cnf with the following changes.
a.       Add a [mysqld_multi] section that looks like this:
[mysqld_multi]
mysqld          = /usr/bin/mysqld_safe
mysqladmin      = /usr/bin/mysqladmin

b.      Rename [mysqld] to [mysqld1]
c.       Add a [mysqld2] section with the following parameters:
[mysqld2]
port            = 3305
datadir         = /mnt/databackup/mysql
socket          = /tmp/mysql.sock2
pid-file        = /mnt/databackup/mysql/mars-snapshot-test.pid2
log_error       = /mnt/databackup/mysql/error2.log
To start the second instance of mysql use the following command:
“mysqld_multi start 2”
To stop the second instance of mysql use the following command:
Mysqladmin –uusername –ppassword –socket=/tmp/mysql.sock2 shutdown.
To login to the second instance of mysql you will need to login using the socket:
Mysql –uusername –ppassword –S /tmp/mysql.sock2 –hlocation

DownTime - we run this at night when there are a minimal of users. 
Long queries at the time of the LVM snapshot will call some downtime.


** Here is the content of the lvm_snapshot file
FLUSH TABLES WITH READ LOCK;
system lvcreate -L 220G -s -n databackup /dev/VolGroup01/LogVol01;
UNLOCK TABLES;
QUIT