Mysql Replication without down time

There are several options. If you have taken a backup of the master at some point and recorded the binary log name and offset (from the output of SHOW MASTER STATUS ) corresponding to the snapshot, use the following procedure:

  1. Make sure that the slave is assigned a unique server ID.
  2. Execute the following statement on the slave, filling in appropriate values for each option:
  3. Execute START SLAVE on the slave.
  4. If you do not have a backup of the master server already, here is a quick procedure for creating one. All steps should be performed on the master host.
    1. Issue this statement:
    2. With the lock still in place, execute this command (or a variation of it):
    3. Issue this statement and make sure to record the output, which you will need later:
    4. Release the lock:

    An alternative is to make an SQL dump of the master instead of a binary copy as in the preceding procedure. To do this, you can use mysqldump --master-data on your master and later load the SQL dump into your slave. However, this is slower than making a binary copy.

    No matter which of the two methods you use, afterward follow the instructions for the case when you have a snapshot and have recorded the log name and offset. You can use the same snapshot to set up several slaves. Once you have the snapshot of the master, you can wait to set up a slave as long as the binary logs of the master are left intact. The two practical limitations on the length of time you can wait are the amount of disk space available to retain binary logs on the master and the length of time it will take the slave to catch up.

    You can also use LOAD DATA FROM MASTER. This is a convenient statement that transfers a snapshot to the slave and adjusts the log name and offset all at once. In the future, LOAD DATA FROM MASTER will be the recommended way to set up a slave. Be warned, however, that it works only for MyISAM tables and it may hold a read lock for a long time. It is not yet implemented as efficiently as we would like. If you have large tables, the preferred method at this time is still to make a binary snapshot on the master server after executing FLUSH TABLES WITH READ LOCK.

Mysql Replication – configuring master and slave

Here is a quick description of how to set up complete replication of your current MySQL server. It assumes that you want to replicate all your databases and have not configured replication before. You will need to shut down your master server briefly to complete the steps outlined here.

The procedure is written in terms of setting up a single slave, but you can use it to set up multiple slaves.

1. Make sure that you have a recent version of MySQL installed on the master and slaves

2.  Set up an account on the master server that the slave server can use to connect. This account must be given the REPLICATION SLAVE privilege. If the account is used only for replication (which is recommended), you don’t need to grant any additional privileges. Suppose that your domain is and you want to create an account with a username of repl such that slave servers can use the account to access the master server from any host in your domain using a password of slavepass. To create the account, this use GRANT statement:
-> TO ‘repl’@’’ IDENTIFIED BY ‘slavepass’;
For MySQL versions older than 4.0.2, the REPLICATION CLIENT privilege does not exist. Grant the FILE privilege instead:
mysql> GRANT FILE ON *.*
-> TO ‘repl’@’’ IDENTIFIED BY ‘slavepass’;
If you plan to use the LOAD TABLE FROM MASTER or LOAD DATA FROM MASTER statements from the slave host, you will need to grant this account additional privileges:
Grant the account the SUPER and RELOAD global privileges.
Grant the SELECT privilege for all tables that you want to load. Any master tables from which the account cannot SELECT will be ignored by LOAD DATA FROM MASTER.

3. If you are using only MyISAM tables, flush all the tables and block write statements by executing a FLUSH TABLES WITH READ LOCK statement.
Leave the client running from which you issue the FLUSH TABLES statement so that the read lock remains in effect. (If you exit the client, the lock is released.) Then take a snapshot of the data on your master server. The easiest way to create a snapshot is to use an archiving program to make a binary backup of the databases in your master’s data directory. For example, use tar on Unix, or PowerArchiver, WinRAR, WinZip, or any similar software on Windows. To use tar to create an archive that includes all databases, change location into the master server’s data directory, then execute this command:
shell> tar -cvf /tmp/mysql-snapshot.tar .
If you want the archive to include only a database called this_db, use this command instead:
shell> tar -cvf /tmp/mysql-snapshot.tar ./this_db
Then copy the archive file to the /tmp' directory on the slave server host. On that machine, change location into the slave's data directory, and unpack the archive file using this command:
shell> tar -xvf /tmp/mysql-snapshot.tar
You may not want to replicate the mysql database if the slave server has a different set of user accounts from those that exist on the master. In this case, you should exclude it from the archive. You also need not include any log files in the archive, or the’ or' files. While the read lock placed by FLUSH TABLES WITH READ LOCK is in effect, read the value of the current binary log name and offset on the master:
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
| mysql-bin.003 | 73 | test | manual,mysql |
The File column shows the name of the log, while Position shows the offset. In this example, the binary log value is mysql-bin.003 and the offset is 73. Record the values. You will need to use them later when you are setting up the slave. They represent the replication coordinates at which the slave should begin processing new updates from the master. After you have taken the snapshot and recorded the log name and offset, you can re-enable write activity on the master:
If you are using InnoDB tables, ideally you should use the InnoDB Hot Backup tool. It takes a consistent snapshot without acquiring any locks on the master server, and records the log name and offset corresponding to the snapshot to be later used on the slave. InnoDB Hot Backup is a non-free (commercial) additional tool that is not included in the standard MySQL distribution. See the InnoDB Hot Backup home page at for detailed information and screenshots. Without the Hot Backup tool, the quickest way to take a binary snapshot of InnoDB tables is to shut down the master server and copy the InnoDB data files, log files, and table definition files (.frm files). To record the current log file name and offset, you should issue the following statements before you shut down the server:
Then record the log name and the offset from the output of SHOW MASTER STATUS as was shown earlier. After recording the log name and the offset, shut down the server without unlocking the tables to make sure that the server goes down with the snapshot corresponding to the current log file and offset:
shell> mysqladmin -u root shutdown
An alternative that works for both MyISAM and InnoDB tables is to take an SQL dump of the master instead of a binary copy as described in the preceding discussion. For this, you can use mysqldump --master-data on your master and later load the SQL dump file into your slave. However, this is slower than doing a binary copy. If the master has been previously running without --log-bin enabled, the log name and position values displayed by SHOW MASTER STATUS or mysqldump will be empty. In that case, the values that you will need to use later when specifying the slave's log file and position are the empty string ('') and 4.

4.  Make sure that the [mysqld] section of the my.cnf’ file on the master host includes a log-bin option. The section should also have a server-id=master_id option, where master_id must be a positive integer value from 1 to 2^32 – 1. For example:

Continue reading

unable to start jboss: java.lang.IllegalStateException: Incompletely deployed

If you encounter this error message while starting the JBoss AS server you just need to make a small change in the profile.xml file.

java.lang.IllegalStateException: Incompletely deployed:

open server\default\conf\bootstrap\profile.xml, look for where “AttachmentStore” is defined and change the parameter to <constructor><parameter class=””>/

or just replace the entire line as follows

<bean name=”AttachmentStore” class=”org.jboss.system.server.profileservice.repository.AbstractAttachmentStore”>
<constructor>><parameter class=””><inject bean=”BootstrapProfileFactory” property=”attachmentStoreRoot” /></parameter></constructor>

Then try to run the file again and you can see JBOSS server starting successfully.