백업에 있는 테이블 버전에 의존하는 수밖에 없다고 생각합니다. 복사된 .ibd 파일은 복원할 수 없습니다.
오류 메시지는 다음 두 가지 중 하나가 발생했음을 나타냅니다.
백업 이후 테이블 구조가 변경되었으므로 .ibd 파일이 더 이상 데이터 사전에 저장된 메타데이터와 일치하지 않습니다. InnoDB는 테이블스페이스 파일의 내용이 메타데이터와 일치하지 않을 때 여러분과 같은 입장입니다. "어떻게 해야 할지 모르겠습니다."
테이블 구조가 변경되지 않았더라도 .ibd 파일이 물리적으로 손상되면 InnoDB에서 읽을 수 없게 될 정도입니다.
어쨌든 InnoDB는 테이블스페이스 파일을 읽을 수 없습니다.
다른 모든 테이블을 성공적으로 복원하면 분명히 문제가 발생할 것입니다. 이제 오래된 테이블인 마지막 테이블을 제외하고 대부분의 테이블에 최신 데이터가 있습니다. 이러한 테이블에 서로를 참조하는 행이 있는 경우 고아 레코드(예: 사용자가 제품을 구매했지만 해당 사용자가 Users 테이블에 없음을 표시하는 레코드)가 있을 수 있습니다.
이 문제는 안타깝고 수정하기 어렵습니다.
일반적으로 .ibd 파일을 복사하는 것은 InnoDB 데이터베이스를 백업하는 안정적인 방법이 아닙니다. mysqldump 또는 Percona XtraBackup과 같은 적절한 백업 도구를 사용해야 합니다.
마지막 백업 후 데이터를 복구하는 또 다른 솔루션은 특정 시점 복구를 위해 바이너리 로그 파일을 사용하는 것입니다. 그러나 이를 위해서는 가장 최근 백업 이후의 모든 바이너리 로그 파일이 필요하며, 백업에는 백업이 수행된 당시의 바이너리 로그 위치에 대한 정보가 필요합니다.
백업에 있는 테이블 버전에 의존하는 수밖에 없다고 생각합니다. 복사된
.ibd
파일은 복원할 수 없습니다.오류 메시지는 다음 두 가지 중 하나가 발생했음을 나타냅니다.
백업 이후 테이블 구조가 변경되었으므로
.ibd
파일이 더 이상 데이터 사전에 저장된 메타데이터와 일치하지 않습니다. InnoDB는 테이블스페이스 파일의 내용이 메타데이터와 일치하지 않을 때 여러분과 같은 입장입니다. "어떻게 해야 할지 모르겠습니다."다른 모든 테이블을 성공적으로 복원하면 분명히 문제가 발생할 것입니다. 이제 오래된 테이블인 마지막 테이블을 제외하고 대부분의 테이블에 최신 데이터가 있습니다. 이러한 테이블에 서로를 참조하는 행이 있는 경우 고아 레코드(예: 사용자가 제품을 구매했지만 해당 사용자가 Users 테이블에 없음을 표시하는 레코드)가 있을 수 있습니다.
이 문제는 안타깝고 수정하기 어렵습니다.
일반적으로 .ibd 파일을 복사하는 것은 InnoDB 데이터베이스를 백업하는 안정적인 방법이 아닙니다. mysqldump 또는 Percona XtraBackup과 같은 적절한 백업 도구를 사용해야 합니다.
마지막 백업 후 데이터를 복구하는 또 다른 솔루션은 특정 시점 복구를 위해 바이너리 로그 파일을 사용하는 것입니다. 그러나 이를 위해서는 가장 최근 백업 이후의 모든 바이너리 로그 파일이 필요하며, 백업에는 백업이 수행된 당시의 바이너리 로그 위치에 대한 정보가 필요합니다.
https://dev.mysql.com/doc /refman/en/point-in-time-recovery.html을 참고하세요.