July 2010

HOW TO : Check status of bond interface in Linux

For my notes.. If you ever wanted to check the status of a bonded interface configure in Linux (esp RHEL), you can check the status by running the following command

[root@serverxyz bin]# cat /proc/net/bonding/bond0

i.e. assuming the name of your bond interface is bond0.

Output from the command

Ethernet Channel Bonding Driver: v3.4.0 (October 7, 2008)

Bonding Mode: fault-tolerance (active-backup)
Primary Slave: eth3 (primary_reselect always)
Currently Active Slave: eth3
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0

Slave Interface: eth3
MII Status: up
Link Failure Count: 0
Permanent HW addr: 00:10:18:6e:b8:1a

Slave Interface: eth0
MII Status: up
Link Failure Count: 0
Permanent HW addr: 00:21:5e:11:34:32

The configuration files involved are

/etc/sysconfig/network-scripts/ifcfg-bond0 (Bond Interface)

DEVICE=bond0
IPADDR=10.10.40.26
NETMASK=255.255.255.0
ONBOOT=yes
BOOTPROTO=none
USERCTL=no
GATEWAY=10.10.40.1
NETWORK=10.10.40.0
BROADCAST=10.10.40.255
TYPE=Ethernet

/etc/sysconfig/network-scripts/ifcfg-eth3 (Primary Interface)

DEVICE=eth3
BOOTPROTO=none
ONBOOT=yes
HWADDR=00:10:18:6e:b8:1a
MASTER=bond0
SLAVE=yes
TYPE=Ethernet
USERCTL=no

/etc/sysconfig/network-scripts/ifcfg-eth0 (Secondary Interface)

DEVICE=eth0
HWADDR=00:21:5e:11:34:32
USERCTL=no
ONBOOT=yes
MASTER=bond0
SLAVE=yes
BOOTPROTO=none
TYPE=Ethernet

Lessons of the Trade : Purging Databases

We ran into an interesting issue at work recently. Documenting the solution for my records..

BACKGROUND : We had a table in one of our databases that served as a “hopping” point for some jobs. Data was inserted into this table and at jobs get kicked off at periodic intervals to “process” the data and delete it.

CURRENT METHOD : Launch multiple jobs to process the data and delete the rows as soon as the data is processed. This is causing locks on the table because there are multiple delete operations occurring at the same time. Which in turn means that the jobs cannot complete processing the data causing the table to grow in size.

PROPOSED METHOD : Add a new column to the table called “PROCESSED_STATE” and modify the “processing” jobs to set a flag “Y” in this column as soon as the data is processed. Create a new job that will be launched periodically, which checks the PROCESSED_STATE column and if the flag is set to “Y”, deletes the row.

Morale of the story.. 🙂 .. Multiple deletes on a table are bad. Better way is to have multiple updates and one delete.