MySQL recovery and UTF file BOM mark reading problems

The day before yesterday, the customer called and said that the background database of the GPS inspection system had crashed because the space allocated to the image storage disk was insufficient and he adjusted the partition. I asked him to back up the entire MySQL directory file (how important it was later found), and then reload the database. The reinstallation fails. So I sent a data directory file under MySQL to me, and a data backup file backed up by background software in March was also sent.

Online query found that MySQL data is stored in the ibdata1 file under the data Directory, use UE to open the file, found that all are 0, obviously cannot contain data, compared to the MySQL server used for internal testing, confirm that the file is used to store database data. It seems that only backup data of March can be used.

When I opened the backup data in January, I found that the character set of the database was binary. This was not clear about how to set the character set and was inherited from others. I tried to reinstall MySQL and set it to binary, so there was still an error in restoration. In the MySQL command line, manually execute the restore operation, and the prompt is that the database field width is not enough. manually adjust the database field size to successfully complete the restoration process, but the restored data is garbled.

Open the backup file with UE, and find that the front is the FEFF, UTF Encoding mark, followed by a regular byte data, one byte zero, manually extract byte data, it is readable when it is restored, so we want to use the program to extract non-zero data and then restore it. As a result, it is found that the program cannot read the mark byte FEFF. I think VC2008 + Win7 may automatically process FEFF for you. So I went to VMWare + DOS622 + TC2 and found an article on the internet, How NOT to skip BOM info (FF FE) when using fread or ifstream? This phenomenon is the same. There is no answer.

In the morning, I thought of another method. I used file transmission to get all the codes out. So I connected the serial port. One serial port opened the serial port debugging software, and the other serial port copied, and found that the received data was incorrect, when the MODE command is set, we find that the received data is still different from the UE data. Compared with files opened using EMEditor binary, www.bkjia.com finds that the serial port receives the same information as EMEditor. Compare the number of EMEditor bytes with the number of file attribute bytes. Verify the C program. Use EMEditor to add the UTF Encoding mark to the file. The C program can read the BOM data. Finally, I tried to verify the UE. Oh, my God. Ah, I believe in UE too much.

These are useless in the final restoration of MySQL. Today, the customer called again and asked me how I was doing. After I talked about it, I found that he backed up all the MySQL installation directories as I said, he mentioned that there was an ibdata1 file on other disks. It took a long time and I forgot that I put the data file in another partition for data security. Now, I have analyzed all the information sent by the customer, clarified the original structure of the original MySQL installation, and found that the MySQL automatic backup of the original MySQL configuration file exists in the MySQL directory. So it's super simple. Stop the MySQL service, remove the MySQL-related directories, decompress the data sent by the customer to the MySQL installation directory, modify the configuration file, place ibdata1 in the corresponding path, restart the service, OK, everything works.

Think about Linux software.