ITSA Blog

One common scenario that I face in my daily work is to add disk to various filesystems. Setting up systems correctly so that this is possible will save time and frustration. One of the easiest cases is adding disk to a virtual machine when the guest is using LVM and ext3.

As always, please be sure to backup your data before trying any filesystem or disk manipulation.

After adding the virtual hard disk using the VI client, provision the space from within the virtual machine using the following steps:

1. re-scan storage

echo "- - -" > /sys/class/scsi_host/host0/scan

2. Create physical volume from new device (Note: check with your SAN admin to see if you need to create a partition and align appropriately.)

pvcreate /dev/sdb

3. Extend the volume group to the new PV (physical volume):

vgextend vg01 /dev/sdb

3. Extend the LV (logical volume) to the desired size:

lvextend -L +2G /dev/vg01/lvol05

4. Resize the filesystem to cover the newly extended LV:

resize2fs /dev/vg01/lvol05

Your newly resized filesystem should now be available.

I have not yet tried expanding existing VMDK files on the fly with vSphere but I plan to test that out next.

As a long time Redhat / Fedora user, starting daemons on system boot in Debian has been a mystery.  I recently took the time to search for the answer, rather than placing the start command in the rc.local file and it’s not that bad.  As long as the init script exists in /etc/init.d, run the following command to set it to persist:

update-rc.d <daemon>  defaults

This handy tip was taken from the official debian docs at:

http://www.debian.org/doc/FAQ/ch-customizing.en.html

I recently had to build out a new MySQL node and replace an existing replication master.  Here is the basic procedure that I followed.

1. Build out the new server
2. Install MySQL.  Place the data directory on a logical volume with at least 10% free space in the volume  group (for snapshot backups).
3. Take a good backup of the database(s) from an existing slave.
4. Restore backup to newly built server/mysql instance.
5. Set master to current master.
6. Lock tables on master.
7. Cut over to new master when replication is caught up.

I won’t belabor the issue of building out a server or installing MySQL.  I used CentOS 5.3 and the Percona 5.0.77 binaries for this server.

Taking a Restorable Backup from an Existing Slave

In order to create a point in time restorable backup, it is necessary to stop all writes to the database.  In order to do this on the slave, I simply stopped replication.  This is easily done with the ’stop slave;’ command.

mysql> stop slave;
Query OK, 0 rows affected (0.12 sec)

Also, issue a ’show slave status\G’ and note the master log file name and position.  This will be used to setup replication on the new master which will allow it to sync with the current master.

To perform the backup, I used a combination of mysqlhotcopy and mysqldump.  In this case, I only had < 1MB of data in InnoDB tables and 40GB of data in MyISAM tables.  Mysqlhotcopy is used to backup the MyISAM data while mysqldump is used for the InnoDB data.  Note that unless you stop the slave this will not allow a perfect point in time backup as the InnoDB tables might be changed between the time the mysqlhotcopy finishes and the mysqldump finishes.

After the backup is complete, start the slave thread on the MySQL instance where the backup was taken.

mysql> start slave;
Query OK, 0 rows affected (0.10 sec)

Restore Backup to New Server

To restore the backup, I copied the MyISAM files to the data directory on the destination host and chown’ed them to be owned by the mysql user and group.  I then started the MySQL server instance and imported the mysqldump data using the  mysql command.

Set (new) Master to Current Master

First, verify that the replication-user has access to the current master from the new master.  Once this is verified, set the current master by issuing the following command (or similar) on the new master.  This will allow the new master to sync data with the current master.

CHANGE MASTER TO
MASTER_HOST=’192.168.1.154′,
MASTER_USER=’replication-user’,
MASTER_PASSWORD=’replication-password’,
MASTER_LOG_FILE=’mysql-bin.00574′,
MASTER_LOG_POS=28347586;

You should be able to issue a ’show slave status\G’ command and see that replication is behind and catching up.

Once replication is caught up, it is safe to cut over to the new master.  In order to do this, all writes to the current master must be stopped and the new master must be allowed to be completely synched as far as replication is concerned.

Old master node:

mysql> flush tables with read lock;

Once this occurs, set any existing slaves to the new master and stop using the old master.  Also, stop the slave on the new master, set ‘reset slave;’ to remove all “master” variables.

New master node:

mysql> stop slave; reset slave;

Current slave nodes (use show master status on new master to get file name and position):

CHANGE MASTER TO
MASTER_HOST=’<IP of new master>’,
MASTER_USER=’replication-user’,
MASTER_PASSWORD=’replication-password’,
MASTER_LOG_FILE=’mysql-bin.00574′,
MASTER_LOG_POS=28347586;

While attempting to dump some photos from my newly acquired Sony Cybershot camera onto a Fedora 9 workstation, I had to switch to “Mass Storage” mode on the camera before I was able to mount the volume.

When I inserted the USB cable into my camera and turned it on, the dmesg output was as follows:

usb 1-6: new high speed USB device using ehci_hcd and address 3
usb 1-6: configuration #1 chosen from 2 choices
usb 1-6: New USB device found, idVendor=054c, idProduct=0010
usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-6: Product: Sony DSC
usb 1-6: Manufacturer: Sony

I saw an  Ubuntu forum note about switching to PTP mode, but that did not work for me, only returning the following:

usb 1-6: new high speed USB device using ehci_hcd and address 4
usb 1-6: configuration #1 chosen from 1 choice
usb 1-6: New USB device found, idVendor=054c, idProduct=004e
usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-6: Product: Sony PTP
usb 1-6: Manufacturer: Sony

After I switched to “Mass Storage” mode, I see the following output:

Initializing USB Mass Storage driver...
scsi4 : SCSI emulation for USB Mass Storage devices
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usb-storage: device found at 6
usb-storage: waiting for device to settle before scanning
usb-storage: device scan complete
scsi 4:0:0:0: Direct-Access     Sony     Sony DSC         6.00 PQ: 0 ANSI: 0 CCS
sd 4:0:0:0: [sdb] 3962880 512-byte hardware sectors (2029 MB)
sd 4:0:0:0: [sdb] Write Protect is off
sd 4:0:0:0: [sdb] Mode Sense: 00 00 00 00
sd 4:0:0:0: [sdb] Assuming drive cache: write through
sd 4:0:0:0: [sdb] 3962880 512-byte hardware sectors (2029 MB)
sd 4:0:0:0: [sdb] Write Protect is off
sd 4:0:0:0: [sdb] Mode Sense: 00 00 00 00
sd 4:0:0:0: [sdb] Assuming drive cache: write through
sdb: sdb1
sd 4:0:0:0: [sdb] Attached SCSI removable disk
sd 4:0:0:0: Attached scsi generic sg2 type 0

I was then able to mount the volume (was already mounted to /media/disk) and copy my pictures from the device.

$ lsusb
Bus 001 Device 006: ID 054c:0010 Sony Corp. DSC-S30/S70/S75/F505V/F505/FD92/W1 Cybershot/Mavica Digital Camera
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 002: ID 0a81:0205 Chesen Electronics Corp. PS/2 Keyboard+Mouse Adapter
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub