Linux MKFS error format file system clears Sybase database recovery records

Source: Internet
Author: User
Tags sybase sybase database

The purpose of this blog is mainly to alert themselves in the operation of the Linux operating time can not be taken lightly, regardless of what kind of operation should be cautious, especially to run the core business of the system, before operation to confirm the operating environment of the system.


Introduction of Causes:

The development of the colleague to me to assist in the deployment of automatic backup Sybase database, the database schema for the RHCS high-availability cluster, the database is deployed in the shared disk SDA, while the feedback that the cluster is also problematic, unable to automatically switch, the following record operation errors and recovery of the whole process.


1, the afternoon I landed on the Sybase database server, first view the system version:

#cat/etc/redhat-release Red Hat Enterprise Linux Server Release 5.6

2. View Disk

# fdisk-l----------disk/dev/sda:600 GB, 299999952896 bytes255 heads, sectors/track, 36472 cylindersunits = cylinders of 16065 * 8225280 = BYTESDISK/DEV/SDA doesn ' t contain a valid partition tabledisk/dev/sdb:600 GB, 299999952896 by tes255 heads, sectors/track, 36472 cylindersunits = cylinders of 16065 * = 8225280 bytesdisk/dev/sdb doesn ' t conta In a valid partition table


3. View the file system SDA mount in the/opt,sybase database installation directory.


4, the problem appears in my colleague and I negotiated backup file storage location, I asked colleagues to confirm whether the system mounted two external disks, also

is a shared LUN, he said he did mount two external disks, without confirmation I believe him, how to say that looks like a predecessor, then I suggest that SDB is useless, it is used to store backup data, he must say that SDB is really useless, can be used to store backup data, and then I executed the following command:

#mkfs. Ext3/dev/sdb#mkdir/backup#chown Sybase:sybase/backup#mount/dev/sdb/backup

And that's where the tragedy begins.


I started to deploy automatic script backup, but the view backup log (/home/sybase/dump.log) automatic backup script was unsuccessful, I manually performed a backup of Sybase database master to/home/sybase, the backup was successful, It is not scientific to test the automatic backup successfully in the test environment (the Sybase RHCS high-availability cluster was deployed before your own computer). Next:

#cd  /backup#lldrwxr-xr-x 18 sybase sybase 4096 Jan  9 15:24  ase-15_0drwxr-xr-x  5 sybase sybase 4096 jan  9 12:24  asepdrwxr-xr-x 59 sybase sybase 4096 jan  9 12:15  charsetsdrwxr-xr-x  3 sybase sybase 4096 jan  9 12:15  collatedrwxr-xr-x  2 sybase sybase 4096 jan  9 12:18  configdrwxr-xr-x  2 sybase sybase 4096 jan  9 12:51  datadrwxr-xr-x  4 sybase sybase 4096 jan  9 12:20  dataaccessdrwxr-xr-x  4 sybase sybase 4096 jan  9 12:20  dataaccess64drwxr-xr-x  5 sybase sybase 4096 jan  9 12:21  dbisql-rw-r--r--  1 sybase sybase  155 Jan  9 14:57 interfaces-rw-r--r--  1 sybase sybase    70 jan  9 12:38 interfa.olddrwxr-xr-x  9 sybase sybase  4096 jan  9 12:17 jconnect-7_0drwxr-xr-x  8 sybase sybase  4096 Jan  9 12:14 jre32drwxr-xr-x  3 sybase sybase  4096 jan  9 12:17 jutils-3_0drwxr-xr-x  4 sybase sybase 4096  Jan  9 12:15 localesdrwxr-xr-x  2 sybase sybase 4096  Jan  9 12:42 logdrwxr-xr-x 16 sybase sybase 4096 jan  9  12:28 ocs-15_0drwxr-xr-x 10 sybase sybase 4096 jan  9 12:20  shared-rwxr-xr-x  1 sybase sybase 2037 Jan  9 12:25  sybase.csh-rw-r--r--  1 sybase sybase 1091 jan  9 12:25 sybase.envdrwxr-xr-x   2 sybase sybase 4096 jan  9 12:15 sybase_install_ registry-rwxr-xr-x  1 sybase sybase 1620 jan  9 12:25  sybase.shdrwxr-xr-x  3 sybase sybase 4096 jan  9 12:25  sybdiagdrwxr-xr-x  4 sybase sybase 4096 jan  9 12:15  sybuninstalldrwxr-xr-x  6 sybase sybase 4096 jan  9 12:26  Sysam-2_0drwxr-xr-x 13 sybase sybase 4096 jan  9 12:23 uaf-2_ 5drwxr-xr-x  8 sybase sybase 4096 jan  9 12:25 ws-15_0


At the sight of this scalp is blown up, this is not Sybase installation files! In particular, the individual directories are constantly flashing automatically

#multipath-ll No output

#service MULTIPATHD status does not start


Contact a development colleague to a background storage array a LUN is map to both database servers


can confirm that/SDA and/sdb is the same disk, the reason is clear, not much to say


But the database is still working normally, the files are still in, the Internet to see if the relevant data can repair the formatted file system, that is, rebuilding the Inode node, re-retrieve data, the results of the future is dark Ah, here the development of colleagues, when I showed him the situation, he is optimistic, nothing, data can not be lost, Did a raid1, mother almost I cry.


I asked a master, he said the probability of repair is very low, there is no specific method, it is recommended that professional data recovery company to do!


First of all, not the database is still able to read and write it! Make a decisive manual backup of the business database.


Also want to put Sybas database installation file also CP one copy, but do the operation:

#du-SM * Error, prompted to find the file #ll the entire installation file disappears


It's a big thing.


In the case of a slim opportunity to fix the file system, I decided to rebuild the Sybase database and then import the business database recovery, when the customer his soporific the phone and I let the developer tell the customer in advance At the same time transfer the data just backed up to the development colleagues to import the development test library to see if the data is complete (not sure if the data is valid after MKFS), otherwise you will have to use the previous backup data, which will lead to data loss, my side immediately redeploy the database.


Fortunately development colleague feedback backup data is valid, next i install the business database, import backup data, perform recovery operation, restore operation success, heart pressure finally put down, afterwards the whole person scared unceasingly.


The database recovery process also encountered the problem of character set, and the installation of database device files when the device files need to be the original library file size, all resolved.


Now leave a few questions, and ask everyone to give the answer:


1, after the file system format, the Linux system based on what mechanism makes the file will not be eliminated immediately?


2, du This command why will clear the data, the mechanism is what?


3. What is the way to repair the file system after MKFS?




This article from "Xiao Chen" blog, declined reprint!

Linux MKFS error format file system clears Sybase database recovery records

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.