DROP Table을 취소하는 방법?

실수로 모든 테이블을 떨어 뜨 렸습니다. 다시 복원 할 수 있습니까? 백업 사본이 없습니다.

말 그대로 백업이 없다면 99 %가 운이 없다고 확신합니다.

오래된 형태의 백업이있는 경우 log-bin 옵션을 통해 MySQL 구성 파일 (my.ini)에 바이너리 로깅이 설정되어 있습니까? 그렇다면 마지막 백업 이후에 복구 할 수 있습니다.

일주일 친구를 시작하는 나쁜 방법, 죄송합니다.

질문은 다소 오래되었지만 긍정적 인 답변은 하나도 없으므로 추가하겠습니다.

MySQL이 테이블을 삭제 한 후에도 데이터는 여전히 미디어에 있습니다. 따라서 레코드를 가져오고 테이블을 다시 작성할 수 있습니다. 나중에 나는 그것에 대해 블로그 할 것이지만 지금은 빠른 스케치입니다.

테이블 구조 (CREATE TABLE 문)가 있어야합니다.

innodb_file_per_table이 ON이면 삭제 된 테이블이 디스크 파티션에 있습니다. MySQL을 중지하고 읽기 전용 ASAP로 다시 마운트하십시오. MySQL이 루트 파티션 (btw가 아닌 ​​경우)에 있다면 이미지를 가져 오거나 디스크를 꺼내 다른 서버에 연결하십시오. 다시 말해 모든 쓰기를 중지하십시오.

innodb_file_per_table이 OFF이면 MySQL을 중지하십시오.

그런 다음 https://github.com/twindb/undrop-for-innodb/ 에서 InnoDB 용 드롭 해제 도구를 다운로드하여 컴파일 하십시오 . "확인 컴파일 TwinDB 복구 툴킷 자세한 내용은"게시물을.

그런 다음 stream_parser로 디스크 파티션 또는 ibdata1 (innodb_file_per_table 설정에 따라 다름)을 구문 분석하십시오.

./stream_parser -f /path/to/diskimage_or_ibdata1

그런 다음 삭제 된 테이블이 어느 index_id인지 알기 위해 InnoDB 사전을 복구하십시오.

그런 다음 테이블 구조를 취하고 레코드를 가져옵니다.

./c_parser -f pages-diskimage_or_ibdata1/FIL_PAGE_INDEX/00000<index_id>.page

stdout에 레코드를, stderr에 LOAD DATA 명령을 출력합니다.

여기 내가 한 일이 있습니다. mysql 디렉토리 (Ubuntu의 경우 / var / lib / mysql, Homebrew를 사용하는 Mac의 경우 / usr / local / var / mysql)에서 일부 파일을 찾았습니다. 먼저 특정 스키마를 포함하는 myapp_development / 디렉토리를 로컬 mysql 디렉토리에 복사했습니다. 그런 다음 로컬 ibdata1을 백업하고 서버의 ibdata1을 mysql 디렉토리에 복사했습니다. mysqld를 죽였다. ( ps auxPID를 찾은 다음 kill PID). mysql을 다시 시작하면 응급 복구 모드에서 시작되었습니다. 그런 다음 로컬 mysql 클라이언트를 시작하고 필요한 테이블의 전체 덤프를 생성했습니다.

그리고 우리가 영원히 사라 졌다고 생각한 메타 데이터를 입력하는 몇 주 간의 작업을 나타내는 15,000 개의 행이 저장됩니다 !!

이것이 누군가를 돕기를 바랍니다.

좋은 백업 계획의 필요성에 대한 귀중한 교훈을 빼앗는 것 외에는 불행히도 할 수있는 일이 거의 없습니다.

테이블 유형에 따라 디스크에 남은 데이터에서 데이터를 다시 수집 할 수있는 전문가를 찾을 수 있지만 이러한 법 의학적 분석은 매우 비싸고 (비교적 드문 기술이 필요하므로) 전혀 보장되지는 않습니다. 정말 유용합니다.

이것이 MyISAM 테이블 인 경우, / var / log / mysql 또는 데이터 디렉토리의 테이블 파일을 삭제 취소하면됩니다. 예를 들어 ext3grep 유틸리티를 사용할 수 있습니다 .

"실행 취소"할 수 없습니다 DROP TABLE.

MySQL에 바이너리 로깅이 활성화 되어 있는지 확인하고 거기에서 일부 데이터를 추출 할 수 있습니다.

그외에, 당신은 MySQL을 잊을 수 있고 "우연히 파일 시스템에서 일부 파일을 삭제했습니다"와 같은 종류의 문제에 처해 있습니다. 거기에는 파일을 복구하려고하는 몇 가지 도구가 있으며, 전문적으로이를 수행하는 회사도 있습니다.

이진 로깅을 설정 한 경우 스키마가있는 경우 먼저 테이블을 다시 만들 수 있습니다. binlogs를 해제 한 상태에서 스키마를 작성하십시오. 또는 세션을 건너 뛸 수 있습니다. 그런 다음 테이블 삭제 자체 인 마지막 명령문까지 binlog를 재생할 수 있습니다.

그렇지 않은 경우 백업 덤프 (있는 경우)를 사용하여 복원 할 수 있습니다. csv 파일이있는 경우 데이터를 불러 오기 위해 데이터 인파 일 방법을로드 할 수 있습니다. mysqldump에서 복구하는 경우 전체 데이터베이스를 복원하는 대신 덤프 파일에서 단일 테이블을 복원하는 것이 좋습니다. 데이터 크기가 너무 큰 경우로드하기 전에 키를 비활성화하면 복원 프로세스가 크게 증가합니다.

앞으로 10-24 시간 정도 지연된 슬레이브를 원할 수도 있습니다. percona 툴킷 (pt-slave-delay)을 사용하여 지연된 슬레이브를 만들 수 있습니다