Error 1030 hy000 at line



скрипт переустановки mysql — ошибка storage engine : УКМ-4

Попробовал этот скрипт, он скачал с сервера установочные файлы, но при создании БД ругается

ERROR 1030 (HY000) at line 1: Got error -1 from storage engine

Если автор или кто-то, в нем копавшийся, заглянет, подскажите, пожалуйста, в чем дело. Может, он уже доработан, и новая версия есть, я просто давно не проверял.

Вложения

create_mysql.zip (4.3 Кб, 60 просмотров)

Еще на одной кассе попробовал, теперь прочитал внимательнее.

Видно, что ukm.sql отработал, и ошибка возникает на setver.sql. Пропустил его. База создалась, ukmclient запустился и пишет «КОД НЕИЗВЕСТЕН НЕИЗВЕСТНАЯ ОШИБКА Can not convert » to j».

Видимо, осталось разобраться, что неверно в setver.sql, и дальше уже просить совета у разработчика.

Гм. После перезагрузки кассы ошибка изменилась.

КОД НЕИЗВЕСТЕН НЕИЗВЕСТНАЯ ОШИБКА Query failed: Error(1146) Table ‘ukmclient.ukm_ukmversion’ doesn’t exist: SQL SELECT MAX(version) FROM ukm_ukmversion

Захожу в mysql, не пойму, что за глюк.

Переставил еще раз. Уже нет этого глюка.

Осталось понять, что за проблема вставить строчку в таблицу.

На другой рабочей кассе смотрю.

mysql > select * from ukm_ukmversion ;
+———+—————+———————+———————+
| version | full_version | moment | cli_updates_version |
+———+—————+———————+———————+
| 74000 | | 2017 — 01 — 13 19 : 55 : 00 | 74000 |
| 75000 | | 2017 — 05 — 14 11 : 34 : 36 | 75000 |
| 75001 | | 2017 — 05 — 14 11 : 34 : 47 | 75001 |
| 78000 | | 2018 — 02 — 06 11 : 35 : 32 | 78000 |
| 78001 | | 2018 — 02 — 06 11 : 35 : 33 | 78001 |
| 78002 | | 2018 — 02 — 06 11 : 35 : 43 | 78002 |
| 83000 | | 2018 — 12 — 18 15 : 12 : 57 | 83000 |
| 83001 | | 2018 — 12 — 18 15 : 12 : 58 | 83001 |
| 83002 | | 2018 — 12 — 18 15 : 12 : 58 | 83002 |
| 83003 | | 2018 — 12 — 18 15 : 13 : 12 | 83003 |
+———+—————+———————+———————+
10 rows in set ( 0 , 00 sec )

На этой не хочет.

mysql > insert into ukm_ukmversion values ( 83000 , ‘83000’ , NOW (), 83000 );
ERROR 1030 ( HY000 ): Got error — 1 from storage engine
mysql > CREATE TABLE ukm_test (
-> version int ( 10 ) unsigned NOT NULL default ‘0’ , — Идентификатор версии
-> full_version varchar ( 15 ) NOT NULL default » , — Полный номер версии
-> moment datetime NOT NULL default ‘0000-00-00 00:00:00’ , — Дата установки версии
-> cli_updates_version int ( 10 ) unsigned NOT NULL default ‘0’ — Версия клиентских обновлений
-> );
Query OK , 0 rows affected ( 0 , 07 sec )

mysql >
mysql > insert into ukm_test values ( 83000 , » , NOW (), 83000 );
Query OK , 1 row affected ( 0 , 00 sec )

mysql > insert into ukm_ukmversion select * from ukm_test ;
ERROR 1030 ( HY000 ): Got error — 1 from storage engine
mysql > select * from ukm_test ;
+———+—————+———————+———————+
| version | full_version | moment | cli_updates_version |
+———+—————+———————+———————+
| 83000 | | 2019 — 06 — 16 11 : 54 : 18 | 83000 |
+———+—————+———————+———————+
1 row in set ( 0 , 00 sec )

mysql > drop table ukm_ukmversion ;
Query OK , 0 rows affected ( 0 , 13 sec )

mysql > rename table ukm_test to ukm_ukmversion ;
Query OK , 0 rows affected ( 0 , 00 sec )

Источник

Восстанавливаем поврежденные таблицы Innodb

Восстанавливаем поврежденные таблицы Innodb

Предположим, вы работаете с MySQL таблицами Innodb, и в один прекрасный не самый хороший момент подводит глючное железо, драйвер, бажит ядро, отключается электричество или случается одна из редких ошибок в среде MySQL. На выходе получаем повреждение некоторых страниц в табличной области Innodb.

Так вот, сейчас речь о ситуации вроде этой:

Что делать для восстановления таблицы? В принципе, типов повреждений может быть несколько, ниже мы рассмотрим один из наиболее распространенных моментов. А именно — когда повреждена страница в кластеризованном первичном ключе.

В примере рассматривается файл test.idb, где заменено несколько байтов, так что повреждение достаточно умеренное.

При этом операция CHECK TABLE в INNODB практически бесполезна. Для текущего поврежденного файла мы получаем:

Первый запуск — проверка таблицы в обычном режиме, в этом случае innodb просто падает, если есть ошибка в контрольной сумме (даже, если мы выполняем CHECK). Во втором случае запускаем innodb_force_recovery=1. И даже здесь мы получаем в логах запись о несовпадении контрольной суммы, при этом CHECK TABLE говорит нам, что с таблицей все ок. Как видим, CHECK TABLE доверять можно далеко не всегда.

Читайте также:  Event id 1002 error

В примере «повреждение» совсем небольшое, поэтому, если запускаем innodb_force_recovery=1, получаем следующее:

Теперь мы получили все данные в таблице MyISAM, так что все, что остается сделать — дропнуть старую таблицу, и конвертировать новую в innodb после рестарта без опции innodb_force_recovery. Если старая таблица будет нужна в дальнейшем, ее можно просто переименовать. Вторая альтернатива — сделать дамп с MySQLDump и загрузить таблицу обратно. В принципе, это почти одно и то же. MyISAM используется по причине, описанной ниже.

Почему бы просто не воспользоваться OPTIMIZE TABLE? Все потому, что работа в режимер innodb_force_recovery проводится в режиме чтения для операций с данными, поэтому нельзя вставлять или стирать данные (при этом можно создавать или удалять таблицы Innodb):

Это было просто, правда?

После этого можно пойти еще дальше, и отредактировать наш файл test.ibd, полностью удалив один из заголовков страницы. Теперь CHECK TABLE будет падать даже при использовании innodb_force_recovery=1

Если мы видим нечто подобное, то innodb_force_recovery нам не поможет, поскольку работать с этим можно тлько в случаях повреждения данных в различных системных местах. Но в нашем случае это не помогает.

Получаем такую ошибку:

Попытки использования автоматических процессов восстановления поврежденных данных не приводят к положительному результату. Поэтому стоит использовать серию команд с LIMIT для режима ручного восстановления:

Здесь строки из таблицы переводятся в новую таблицу, пока мы не добираемся до строки, которая и вызывает падение MySQL. Мы можем ожидать этого в строке между 200 и 300, так что стоит использовать серию схожих действий для решения проблемы.

Теперь мы обнаружили поврежденные данные в таблице, при этом стоит использовать max PK, и проверить иные значения:

Так, мы пробуем пропустить 30 строк, но это оказывается недостаточным. Пропускаем 80 строк, и теперь все хорошо. Используя «двоичный поиск» мы можем понять, сколько строк нужно пропустить, для восстановления максимального количества поврежденных данных. Размер строки при этом может помочь. Так, у нас есть 280 байт на строку, поэтому мы получаем около 50 строк на страницу. И здесь 30 строк недостаточно — если таблица страниц повреждена, нужно пропустить минимум всю страницу. Если повреждена страница на более высоком уровне BTREE, нужно пропустить больше страниц, для использования этого метода восстановления.

В некоторых случаях, например, когда повреждена root page для кластеризованного индекса, этот метод не будет нормально работать. В этом случае стоит использовать Innodb Recovery Toolkit.

Стоит упомянуть innodb_force_recovery может принимать значения от 1 до 6: dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
При значениях 4 и более — может привести к дальшему коррапту базы.

Отдельно стоит расмотреть вариант утрачен или побит файлик ibdata, при этом innodb_file_per_table выключен

Recovering an InnoDB table from only an .ibd file.

Sometime you may need to recover a table when all you have is the .ibd file. In this case, if you try to load it into a new instance, your likely to encounter some errors about the table id not matching. And there is not really a way around this.

However, I’ve found two work-arounds for this:

Note: You will need the .ibd file and the CREATE TABLE statement for each table you want to recover using these methods.

  1. Simulate the internal InnoDB table counter. That is, create work tables (with innodb_file_per_table enabled) until you have the internal pointer of table id equal to (1 – id_of_ibd_table_you_need_to_restore). (See Method #1)
  2. Manually hex edit the .ibd file, changing the table id. (See Method #2)

*Note: There are some internal structures with this meta information, so you’ll need to dump/import that data after you get it loaded, so you avoid unpleasantries that will inevitably show their face.

Читайте также:  Windows 11 wsl error

Method #1 – Create work tables

1. Start up clean/fresh instance of MySQL with innodb_file_per_table enabled.

2. Now, we need to find the table id that MySQL is currently set at, as well as the table id for the table we need to recover.

Note:
Step 2 (2a – 2f) is simply to find the table id that is stored inside of the .ibd file. I’ve written a PHP script to determine this, so using the script can save a bunch of time. See the bottom of this page (under “Associated Files”) for the exact script.

2a. Create a test database:

2b. Issue the create table command for the table:

2c. Discard the tablespace, which will delete the newly created .ibd file:

2d. Copy the pre-existing .ibd file to the datadir/test1 folder

2e. Import this tablespace:

This should produce the following error (at least this is most likely). The only way it would not is if MySQL’s current table id matched that of the preexisting ibd table id. In which case, you can now dump your table.

2f. So, now to check the error log (manually). Look for the following entry:

So, now we know the internal table id is at 1, and that of the ibd table is 1193.

3. Clean up working database:

3a. Manually move the ibd file from the $datadir to a safe location (as you will need this file again).

3b. Drop this table.

Note this does not re-set the internal table counter.

4. You’ll need to create the number of tables you need to increase the internal table id value.

In this case, you’d create 1191 test InnoDB tables (already at 1, and need to leave 1 for the actual table, so 1193-2=1191). Run below in a loop.

I accomplished this via a simple php script. See the bottom of this page (under «Associated Files») for the exact script.

5. After these are created, go ahead and drop this database and all tables (as they are not needed).

6. Now, re-perform steps 2a through 2e.

7. Now, dump the table using mysqldump, and then you can import this to any MySQL instance. Note, you must dump this and re-import it, or you’ll run into problems.

However, it’s possible to encounter crashes and/or reports of corruption in the logs.

If this happens, try to force innodb recovery (which is most likely), and then dump the table.

Start by setting innodb_force_recovery=1 (and try 2,3,4,5,6) until the dump works.

For this example table, I had to set innodb_force_recovery=5 before the dump would succeed.

The # in the output file name is the value I had innodb_force_recovery set to when trying to perform the dump:

In fact, in this case, I could have simply started with 5. This is because the error log stated this:

So, I knew there was a problem trying to look at the undo logs, and from the manual, a setting of 5 says this:

«Do not look at undo logs when starting the database: InnoDB treats even incomplete transactions as committed»

However, it’s best to start at 1 and work your way forward so as to prevent as much data loss as possible.

Method #2 — Hex Edit .ibd file

First of all, you’ll need to backup everything (ibdata files, ib_logfile(s), data). I’d also perform a mysqldump of everything you currently have, just so you have a mysqldump of it in the event that you need it.

Also, very important, be sure to make a copy of the .ibd file for the specific table in question.

Lastly, get a copy of the CREATE TABLE statement that will recreate this table.

Then, you’ll follow the steps #1-5 (but do not perform step #6 yet) outlined on the following page:

Читайте также:  Mysql workbench ssl connection error

Let me post them here for completeness, however:

  1. Use mysqldump to dump all your InnoDB tables.
  2. Stop the server.
  3. Remove all the existing tablespace files, including the ibdata and ib_log files. If you want to keep a backup copy of the information, then copy all the ib* files to another location before the removing the files in your MySQL installation.
  4. Remove any .frm files for InnoDB tables.
  5. Configure a new tablespace.
  6. Restart the server.
  7. Import the dump files.

At this point, MySQL should be running fine with an empty slate (and should have just re-created your new ibdata and log files).

Now, you’ll want to recreate the table (just using the CREATE TABLE output from above), and its database to hold it.

Then, you’ll basically be following the steps #1-3 outlined on the following page:

1. Issue this ALTER TABLE statement:

Caution: This statement deletes the current .ibd file.

2. Put the backup .ibd file back in the proper database directory (the one that you copied above).

3. Issue this ALTER TABLE statement:

Everything should go smoothly until step #3 (above). More than likely, this will produce an error like the following on your console:

Now, if you look in the error log, you’ll see something like:

It would not produce the above error and would work fine if the existing table already had a tablespace id of 1. However, this is unlikely.

So, assuming you see the above errors, then you can modify the tablespace id actual ibd file using a hex editor. I would do this on a different copy of the ibd file (other than the original, just in case).

Note that I used «Freeware Hex Editor XVI32» for Windows for this step. Start the program, and then open the .ibd file. You’ll see each byte in it’s own cell. You can then click on a cell, click edit, and then edit that byte. (http://www.chmaas.handshake.de/delphi/freeware/xvi32/xvi32.htm)

Now, in this file, there are 2 places where this tablespace id is located.

For me, and I assume it should be the same for you, but just look at the values to be sure, I see the tablespace id values listed at position 37 and 41 (positions 25 and 29 in hex). In the actual hex column, if you’re previous tablespace id was 2, then in positions 37 and 41, you’d see 02 and 02.

(Note these positions can change. For instance, I tested on a table with an internal id of 1193. This in hex is 04A9. However, when searching the file, for the first instance of the table id, I found the ’04’ in position 39 and ‘A9′ in position 40. Then, for the second instance of the table id, the ’04’ was at position 43 and the ‘A9’ was at position 44. So, you’ll have to convert the table id to hex, and then search for that value, near the beginning of the file.)

Note that this value (02) may vary depending on what your actual tablespace id is.

Then, simply modify both of those fields to 01, and save the file.

Then, re-do the following 3 steps:

This time, step #3 works fine.

It is at this point you should dump/import the data. At least, get a good mysqldump of this table now. You may find that this causes corruption in InnoDB, and you may need to start MySQL using —force-innodb-recovery.

Associated Files :: PHP Scripts

Simple PHP script — Used to create a number of InnoDB tables (to increase internal table id counter):

PHP Internal Table ID Finder — Used to determine the internal Table ID from the binary .ibd file:

Источник

Оцените статью
toolgir.ru
Adblock
detector