Ramblings from MostlyChris

A simple and quick way to get a status of the adapters and devices in the RAID array using megacli is to run the following command:

It will output a LOT of information for the adapter, but you should see the Device Present section that shows the status of the drives. For example, the following shows a failed drive in the array:

=====
Device Present
================
Virtual Drives : 1
Degraded : 1
Offline : 0
Physical Devices : 3
Disks : 2
Critical Disks : 0
Failed Disks : 1
=====

To get more detailed information on the drives in the array, issue the command:

Which results in the following output.

=====
Adapter #0

Number of Virtual Disks: 1
Virtual Disk: 0 (target id: 0)
Name:
RAID Level: Primary-1, Secondary-0, RAID Level Qualifier-0
Size:237464MB
State: Degraded
Stripe Size: 64kB
Number Of Drives:2
Span Depth:1
Default Cache Policy: WriteBack, ReadAdaptive, Cached, No Write Cache if Bad BBU
Current Cache Policy: WriteBack, ReadAdaptive, Cached, No Write Cache if Bad BBU
Access Policy: Read/Write
Disk Cache Policy: Disk's Default
Number of Spans: 1
Span: 0 – Number of PDs: 2
PD: 0 Information
Enclosure Device ID: 252
Slot Number: 0
Device Id: 4
Sequence Number: 2
Media Error Count: 0
Other Error Count: 0
Predictive Failure Count: 0
Last Predictive Failure Event Seq Number: 0
Raw Size: 238475MB [0x1d1c5970 Sectors]
Non Coerced Size: 237963MB [0x1d0c5970 Sectors]
Coerced Size: 237464MB [0x1cfcc000 Sectors]
Firmware state: Online
SAS Address(0): 0xb221c046788723f
Connected Port Number: 0(path0)
Inquiry Data: ATA ST3250620AS K 6QE1DRKL

PD: 1 Information
=====

Notice that it shows a state of degraded. The above output is that of the degraded variety. There are two PDs (physical disks) in this span but there is only one showing in the the output.

In order to find out what drive is failed, it is actually the absence of information that shows this. Issue the following command:

This results in an output similar to the following:

=====
Adapter #0

Enclosure Device ID: 252
Slot Number: 0
Device Id: 4
Sequence Number: 2
Media Error Count: 0
Other Error Count: 0
Predictive Failure Count: 0
Last Predictive Failure Event Seq Number: 0
Raw Size: 238475MB [0x1d1c5970 Sectors]
Non Coerced Size: 237963MB [0x1d0c5970 Sectors]
Coerced Size: 237464MB [0x1cfcc000 Sectors]
Firmware state: Online
SAS Address(0): 0xb221c046788723f
Connected Port Number: 0(path0)
Inquiry Data: ATA ST3250620AS K 6QE1DRKL
=====

In the case of the above, there are two drives, one each in slot 0 and slot 1. Since slot 1 is not listed above, the assumption is that the bad drive is slot 1. Slot 0 is showing with no errors. Note that the command

also shows the missing slot 1 information, indicating that slot 1 is the failed drive.

I have this problem. I am trying to send a SOAP request to a provider of information I need. In order to make this request correctly, I have to provide a value as a LONG. For whatever reason, they are not getting what I think I am sending. Therefore, I need a way to see what I am sending. Sure, I can use tcpdump to view the packets, but I can't decode this stuff. Wireshark comes to mind. The problem is, I am not doing this on a local box and Wireshark is GUI based. What to do…what to do? Here's how I am handling the issue.

First, I output my tcpdump results to a file:

I then import this file to a box that I have Wireshark running on and I can now view the conversation. Of course, this doesn't work if you want to follow something real-time but it at least works if you want to do some troubleshooting like I am.

Of course, if you have a better way a of doing this, leave a comment.

Changing the timezone on a server (replace Europe/Amsterdam with your faviorite zone file)

Set the ZONE entry in the file /etc/sysconfig/clock file

Sync the hardware clock

If your .FRM file gets hosed up, you'll need to repair it or your database(s) will be worthless. You'll still need to make sure you make regular backups of your databases so you can use them to rebuild the .FRM file.

1. Get last good backup of database (assumes the backup is an .sql formatted single file).

2. Grep out the schema from the .sql file (grep -v 'INSERT INTO' [.sql file] > somefile.sql)

3. Locate the schema for the broken table.

4. Go into a mysql shell and create a new table with a different name and same schema as the broken table (located in step 3) in the affected database.

5. Stop mysqld.

6. Copy the [newtable].frm file in /var/lib/mysql/[database] to the [brokentable].frm, overwriting [brokentable].frm

7. Remove the [newtable].MYI/.MYD files from /var/lib/mysql/[database].

8. Start mysqld.

9. Run on a count on the newly fixed table and make sure there are records.

10. Run a mysqldump of the database and make sure it completes successfully.

11. Clean up any unneeded files created in the process of the fix.

Launch `hpacucli’, the RAID interface and run the following:

All drives will be shown — it’s obvious which ones are not configured as a logical disk.

We’ve only added one drive, and the controller is smart enough to know that making a logical disk out of one drive will be a RAID-0, thus no RAID level is specified. If using multiple drives, list them with commas (drives=2:2,2:3,2:4) and add a “raid” command:

Using the ? will tell you what RAID levels are available for the drives selected. Specify the RAID level with “raid=5″.

Will show your new logical disk composed of the previously unused drives. You may need to run `partprobe’ on the server to enable it to see the new logical disk, but thereafter you are free to partition away and do what must be done.