아 급하네요...,마리아DB 관련입니다. 도와주세요.
본문
마리아 DB가 어떤 이유에서인지 start가 되지 않아 구글링 하던중
ibdata1
ib_logfile0
ib_logfile1
이 3개의 파일을 삭제한후 start 해보라는 정보를 보고 3개의 파일을 삭제했더니...정말
maria DB 데몬이 start가 되네요..
헌데 테이블의 내용을 select 하면
ERROR 1932 (42S02): Table 'jamakjoa_DB.g5_write_free' doesn't exist in engine
이와같은 메시지가 뜨네요.... 어떤 작업을 해줘야 하나요?
밤새 삽질하다 올려봅니다. 도와주세요
답변 11
아직 복구를 못했네요. 테이블파일이 per table로 저장 되 있다는게 무슨 뜻인지요?
==> 각 테이블 데이타는 저장이 되어 있다는 의미입니다. frm, ibd 파일이 있는거죠.
문제는 스키마와 메타데이타와 그외 몇몇 데이타가 ibdata.ibd에 저장되는데 이걸 삭제했으니, 복구가 어려운것입니다.
삭제된 테이블 스키마를 알면 복구는 가능합니다.(물론 ibdata.ibd가 지워질 당시의 스키마)
스키마를 몰라도 그누보드나 아미나는 솔루션이 설치될 당시의 스키마와 비슷하기 때문에 이를 기준으로 추정하여 복구할수 있습니다.
말은 복구할수 있다고 썼지만, 번거롭고 복잡한 작업을 해야 합니다. 전체과정을 설명해드리긴 어렵고
전문가를 찾으시거나, 마지막에 백업된 데이타로 복구하시는걸 추천드립니다.
누가 복구 메뉴얼을 저따위로 써둔거에요?
실제 데이타 파일을 지우라고 써두었네요.
다행이 테이블 파일이 per table로 저장이 되어 있어서 시도해볼 방법글이 있을것 같네요. 지금 파일들을 백업해둔 상태에서 시도해봐야 할것 같네요.
아직 복구를 못했네요. 테이블파일이 per table로 저장 되 있다는게 무슨 뜻인지요?
g5_write_free 테이블 존재하는지 확인 후,
없으면 다시 만들어주시면 될 듯..
ibd랑frm파일만 현재 있어요. 헌데 이러한 테이블이 그누보드,아미나,기타 추가한 계시판,플러그인....인덱스까지 283개나 되네요.ㅜㅜ
innodb 엔진으로 이용하시는중이면. ibdata화일이 db 데이터 저장화일일텐데.. 백업해놓으신거 아니면 자료가 날아가실거예요..
ibdata1
이건 InnoDB에서 사용하는 파일입니다.
삭제하셨다면 백업본으로 복구를 하셔야할것같네요
아니면 빠른대안을 찾으셔야 합니다.
그럼 해당 데이타베이스 폴더안에 있는 tablename.ibd , tablename,frm은 innodb에서는 사용하지 않는건가요? 데이타베이스name 폴더는 그대로 있거든요
mysql 이 계속 start하다 에러나서 구글링중 이문서를 참조했는데 이렇게 됬네요.
https://idchowto.com/?p=11107
InnoDB라고 해서 ibdata 관련만 사용하는것은 아니더군요
테이블이 Isam으로 생성되면 frm 도 사용합니다.
ibd
ibdata
frm
다 중요한 mysql파일들입니다.
백업을 찾으시는게 가장 빠른 복구방법으로 보여집니다.
호스팅 업체에 백업 내용이 존재하는지 먼저 확인 후 있다면 백섭.
없다면 백업해둔 DB 가 존재 하는지 확인
없다면..망..
차라리 지우라고 서버가 알려준 파일 3개를 지우지 마시고 이름을 rename 해버리시지..
보통 서버관리자가 아닌 이상 가급적 서버내에서 특정 파일은 삭제 하지 않는것이 좋은것으로 알고있습니다.
머리가 너무 아프네요.
아직 포기하지 않고 진행중입니다.
명량페인님의 삭제된 테이블 스키마를 알면 귀챦고,힘들고,일이많다는 말을 참고해 가장 최근에 mysqldump로 백업받아둔(2019년9월)파일에서 스키마만 빼내서 이후에 추가된 테이블,수정된 테이블등을 소스를 보면서 최대한 마지막 스키마와 비슷하게 만들어 가고 있습니다. 이 기간에 한 작업중 가장 많은게
1. 238개 테이블의 엔진을 2개만 제외하고 236개 테이블의 엔진을 MyIsamDB에서 InnoDB 로 바꾼거
2. 슬로우쿼리를 2초-->1초 로 줄여가면서 쿼리떄문에 index추가및 변경하거나 쿼리문을 수정한거
3. 데이타의 양이 100만건 이상이면 문장검색이(INSTR,LIKE)검색이 현격히 느려 FULLTEXT로 인덱싱을 변경하여 MATCH AGAINST로 변경하거
4. 특별한 기능을 위해 테이블 추가하거나 수정한거..
5.l FULLTEXT검색시 검색하는 단어앞에 공백이나 특수문자가 없으면 검색이 안되는 문제와 2글자 이하를 검색하게 세팅하면 mysql restart시 가끔 3글짜로 복구되서 FULLTEXT를 전부 재생성전까지는 검색자체가 안되는점등으로 검색엔진(Sphinx)을 테스트하기 위해 몇개 테이블을 수정한점..
!!!
참 많기도 하네요.
*참고로 해외 호스팅업체의 자문도 받고 있습니다.
--- 살릴수 있을지????? 두두둥???????
호스팅업체는 해외라 일단 티켓발행했구요. 근데 한가지 희망이 보이고 있습니다.
일단 mysql을 정지시키고 .ibd .frm파일이 있는 데이타베이스 폴더를 백업받아놓고
my.cnf에 innodb_force_recovery=1 이노디비 리커버리옵션을 1로 설정하고
mysql 을 다시 올렸습니다. 그랬더니 ...........두두둥...............잘되면 다시 쓸꼐요
테이블마다 데이타가 100만 200만이 많아 좀 오래 걸릴거 같아요
잘되길바랍니다.
이방식은 innodb_force_recovery 1부터 3까지 진행했으나 실패했습니다.
레벨4,5,6은 복구한다해도 원본 데이타가 많이 손실되 의미가 없을거 같아 진행을 3에서 멈추었습니다.
사용하지 않거나 없어도 되는 테이블들 제외시키니 150개정도중 100개는 4개월전에 받아둔 덤프백업에서 스트럭쳐를 뺴내어 일단 복구를 했습니다. 아직 50개정도 남았는데 이놈들은 테이블 구조가 바뀌었거나 스크래치가 많이나서 복구가 아직 안되고 있는 놈들이면서도 중요도가 높은 것들이네요. 이번에 느낀점은 테이블 스키마만이라도 정확히 백업받아놓았으면 하는 아쉬움이 많이 남네요. 헌데 검색엔진 스피니쉬 최신버젼(3.x)을 깔았는데 혹시 mysql과 인과관계가 있나 하는 생각도 듭니다. 복구가 정말 만만치 않네요. 바둑알을 한개씩 포개서 100개를 쌓는 기분???? 무너지면 한개부터 다시 쌓아야 되죠 ㅠㅠ ^^
무너지면 mysql stop시키고 ibdata1,ib_logfil0,ib_lofile1,ibtmp등등 전부 삭제하고 다시 mysql stat하면
drop database 명령으로 디비를 날릴수가 있습니다.물론 drop table로 한개씩 정보를 삭제할수도 있지만 어차피 다시해야하는거 database를 날려버리는게 빠르겠죠. 그래야만 합니다. 복구중인 database 중에 특정 테이블 하나 떄문에 database가 통째로 꺠지면서 mysql이 온갖 에러를 내밷으면서 자동으로 restart됩니다. 이미 꺠진상태에서 restart되는거라 계속 반복될 뿐입니다. 꼭 mysql을 stop 시키고 ibdata1관련파일 전부 삭제하고 mysql start시켜서 drop database로 무너진 탑 청소하고 create database명령을 바닥공사 다시한뒤 다시 1번 바둑알부터 쌓기 시작합니다..100개를 쌓을떄까지 견딜수 있을까요?
이런일 한번씩 겪으면서 데이타 백업의 중요성을 깨닭게 되는거죠.
저도 데이타 날려본 경험이 꽤 됩니다. 정말 전혀 예상하지 못한 지점에서.. 데이타가 분실되더군요.
하드디스크 갈아끼는데 스파크 튀어서 하드가 날아간적도 있죠.(백업할려고 갈아낀 건데..-_-)
의지가 있으시니 복구는 가능할것 같네요. 화이팅하세요.
