The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Стабильный релиз СУБД MySQL 8.0, opennews (??), 19-Апр-18, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


77. "Стабильный релиз СУБД MySQL 8.0"  +/
Сообщение от нах (?), 22-Апр-18, 18:16 
> Если лог транзакций физически повреждён, то на диске могут быть страницы которые ссылаются
> вникуда (потому что это более свежая версия страницы)

откатиться на несвежую или уж чорт с ним, потерять содержимое страницы целиком но сохранить остальные данные - не вариант?

Ответить | Правка | Наверх | Cообщить модератору

79. "Стабильный релиз СУБД MySQL 8.0"  +/
Сообщение от Аноним (-), 22-Апр-18, 21:49 
> откатиться на несвежую или уж чорт с ним, потерять содержимое страницы целиком но сохранить остальные данные - не вариант?

В каждой странице содержится ссылка на следующую и предыдущую. Если мы сделали сплит (одну страницу поменяли по месту и уже потеряли ссылку на старую следующую), а новую страницу потеряли при записи на диск, то всё пропало - потеряли связь со всеми последующими страницами.

У innodb нет версий страниц, страницы меняются по месту. Есть версии строк - (старые строчки пишутся в undo segment), но это не поможет если вместо следующей странички указатель ведёт на мусор.

Так что получается или втупую парсить, или пытаться по кускам делать select .. where из-под force recovery.
Ну и если словарь повреждён то пытаться делать ibdconnect.

Фатальный недостаток парсинга - все данные в csv виде на выходе и для терабайтной базы это всё надо ещё пару недель грузить.


Потенциально можно сделать поиск "потерянных деревьев" страниц, но будут левые данные и несогласованные данные в табличках и совершенно не ясно что делать, если у страницы неверная контрольная сумма, так что лучше делать бекапы и point-in-time с помощью binary log.

Ответить | Правка | Наверх | Cообщить модератору

80. "Стабильный релиз СУБД MySQL 8.0"  +/
Сообщение от нах (?), 23-Апр-18, 01:12 
ненене, фатальная проблема с парсингом непойми-чего в том, что мы получим не просто csv, а csv с не факт что нашими данными, а не похожим на них мусором с диска.

то о чем я спрашивал - это как потерять часть данных (часто это можно себе позволить) но восстановить функционал системы. (то есть не force recovery, а нормальный режим работы, если приложение обломится о неконсистентность связанных таблиц или просто select вернет пустое место - это уже можно как-то переварить самим приложением) Но, видимо, в борьбе за эффективность переэкономили - в результате рухнувшая innodb, получается, вовсе не подлежит оживлению, только выковыривать тем или иным способом данные и пересоздавать ее с нуля (привет от оракла с его ora006).

binary лог к сожалению не панацея - он-то может и быстро накатиться, да вот восстановление самой крупной базы займет неприлично много времени.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру