show service command from Exinda CLI, the database process appears as stopped and couldn't be started.
Checking the disk space (
df -h command) displays almost full /var partition filled up with sysdumps.
The Exinda performance is slow and the commands are taking extremely long to execute because of MySQL failures.
- Make sure to delete the sysdumps. For more information, please refer to System Disk Full for /var folder.
- Reboot the device from CLI:
- Perform hard reset: shut down the device, power drain for approx 15 mins and turn it on again.
- After entering the Linux shell (
_shellcommands), delete the biggest message log files in /var/log folder. You can use
ls -Slhcommand to sort from the biggest to lowest file size:
- Delete the database files:
- Check the RAID and disk status:
smartctl -a /dev/sda -d megaraid,N(where N is drive number, e.g. 1, 2, etc)
badblocks -v /dev/sda(shows the amount and location of bad blocks on your drive; the command execution might take awhile)
- Check the storage from CLI:
show storage raid adapter
show storage disk <sdaX>(where X is the disk number)
If the RAID/disks are faulty, you may see
Predictive Errors: more than 0 valuein Exinda WebUI > Configuration > System > Diagnostics > RAID tab.
- Check the disks physically if there are any Amber LEDs on the disks. In the following image, 2 out of 4 disks are failing. If that is the case, it's needed to replace the hard disk from the drive with a new one and insert it back to be rebuilt by RAID.
If the hardware device is under Hardware Maintenance, the RMA process can be started. If there is no valid license maintenance, please contact GFI Sales.