itsource

MariaDB가 있는 데이터베이스 손상: 엔진에 테이블이 없습니다.

mycopycode 2022. 9. 13. 22:14
반응형

MariaDB가 있는 데이터베이스 손상: 엔진에 테이블이 없습니다.

환경설정에 있으며 OSX를 실행하고 있다.MariaDB 10.0.12-MariaDB Homebrew

설치를 망쳤기 때문에 설정에서 MySQL과 MariaDB를 완전히 삭제하고 다시 시작했습니다.

MariaDB 설치 완료 후 데이터베이스를 다시 Import했습니다(innoDB)를 통해 운영 서버에서 DB Dump을 실행합니다.그것은 잘 작동했다.재부팅 후 다음 날 데이터베이스에 액세스할 수 없습니다.

Table 'my.table' doesn't exist in engine

원인 및 해결방법은 무엇입니까?데이터베이스 구조는 표시되지만 접근하려고 하면 이 오류 메시지가 나타납니다.

노력했어mysql-upgrade --force및 삭제rm ib_logfile1 ib_logfile0

여기서 데이터 손실은 문제가 아닙니다.문제는 재부팅할 때마다 각 데이터베이스를 재설치하는 데 30분을 할애할 수 없다는 것입니다.

로그는 다음과 같습니다.

140730  9:24:13 [Note] Server socket created on IP: '127.0.0.1'.
140730  9:24:14 [Note] Event Scheduler: Loaded 0 events
140730  9:24:14 [Warning] InnoDB: Cannot open table mysql/gtid_slave_pos from the internal data dictionary of InnoDB though the .frm file for the table exists. See http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting.html for how you can resolve the problem.
140730  9:24:14 [Warning] Failed to load slave replication state from table mysql.gtid_slave_pos: 1932: Table 'mysql.gtid_slave_pos' doesn't exist in engine
140730  9:24:14 [Note] /usr/local/Cellar/mariadb/10.0.12/bin/mysqld: ready for connections.
Version: '10.0.12-MariaDB'  socket: '/tmp/mysql.sock'  port: 3306  Homebrew
140730 16:26:28 [Warning] InnoDB: Cannot open table db/site from the internal data dictionary of InnoDB though the .frm file for the table exists. See http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting.html for how you can resolve the problem.

InnoDB가 사전을 보관하고 있는 ibdata1 파일이 삭제되었습니다.MySQL은 절대 아닙니다.

네, 여러분, 이번 주말에 OpenStack 환경이 다운되었을 때 이 문제에 부딪혔습니다.회복 방법에 대한 또 다른 게시물이 곧 나옵니다.

Fedora 25 Server를 호스트로 하는 Ver 15.1 Distributed 10.1.21-MariaDB에서 실행되는 SQL Server 인스턴스에서 사용할 수 있는 솔루션을 찾았습니다.이전 mariadb-server의 /var/lib/mysql 디렉토리를 완전히 복사하고 복사 중인 데이터베이스가 아직 손상되지 않은 경우 데이터베이스가 손상되었다는 다른 모든 게시물은 듣지 마십시오. 이 프로세스는 OS가 손상되었지만 파일에 액세스할있는 시스템을 기반으로 합니다.

다음은 제가 수행한 단계입니다.

  1. 새 서버에서만 현재 버전의 SQL을 완전히 제거했는지 확인하십시오.또한 다음 작업을 수행하여 새 서버와 오래된 서버의 모든 mysql-server 또는 mariadb-server 프로세스가 중지되었는지 확인합니다.

    서비스 misqld stop 또는 서비스 mariadb stop.

  2. NEW SQL Server에서 /var/lib/mysql 디렉토리로 이동하여 이 디렉토리에 파일이 전혀 없는지 확인합니다.이 디렉토리에 파일이 있는 경우는, 새로운 머신으로부터 데이타베이스 서버를 삭제하는 프로세스가 동작하지 않고, 파손되었을 가능성이 있습니다.새로운 머신에서 완전히 언인스톨 되어 있는 것을 확인합니다.

  3. On the OLD SQL server:

    mkdir /OLDMYSQL-DIR cd /OLDMYSQL-DIR tar cvf mysql-olddirectory.tar /var/lib/mysql gzip mysql-olddirectory.tar

  4. Make sure you have sshd running on both the OLD and NEW servers. Make sure there is network connectivity between the two servers.

  5. On the NEW SQL server:

    mkdir /NEWMYSQL-DIR

  6. On the OLD SQL server:

    cd /OLDMYSQL-DIR scp mysql-olddirectory.tar.gz @:/NEWMYSQL-DIR

  7. On the NEW SQL server:

    cd /NEWMYSQL-DIR gunzip mysql-olddirectory.tar.gz OR tar zxvf mysql-olddirectory.tar.gz (if tar zxvf doesn't work) tar xvf mysql-olddirectory.tar.gz

  8. You should now have a "mysql" directory file sitting in the NEWMYSQL-DIR. Resist the urge to run a "cp" command alone with no switches. It will not work. Run the following "cp" command and ensure you use the same switches I did.

    cd mysql/ cp -rfp * /var/lib/mysql/

  9. Now you should have a copy of all of your old SQL server files on the NEW server with permissions in tact. On the NEW SQL server:

    cd /var/lib/mysql/

VERY IMPORTANT STEP. DO NOT SKIP

> rm -rfp ib_logfile*
  1. Now install mariadb-server or mysql-server on the NEW SQL server. If you already have it installed and/or running then you have not followed the directions and these steps will fail.

FOR MARIADB-SERVER and DNF:

> dnf install mariadb-server
> service mariadb restart

FOR MYSQL-SERVER and YUM:

> yum install mysql-server
> service mysqld restart

In my case, the error disappeared after I rebooted my OS and restarted MariaDB-server. Strange.

This one really sucked.

I tried all of the solutions suggested here but the only thing that worked was to

  • create a new database
  • run ALTER TABLE old_db.{table_name} RENAME new_db.{table_name} on all of the functioning tables
  • run DROP old_db
  • create old_db again
  • run ALTER TABLE new_db.{table_name} RENAME old_db.{table_name} on all the tables in new_db

Once you have done that you can finally just create the table again that you previously had.

You may try to:

  • backup your database folder from C:\xampp\mysql\data (.frm & .ibd files only corresponding your table names)
  • reinstall xampp and recopy DB folder at C:\xampp\mysql\data
  • modify my.ini add

    [mysqld]
    innodb_file_per_table = on
    
  • then open phpmyadmin (or any other DB viewer as Navicat or MYSQL Workbench) and run

    ALTER TABLE tbl_name IMPORT TABLESPACE 
    

    for each table

  • Once you can open your tables make a full mysql dump

  • delete everything and make a clean install

알아, 할 일이 많아서 필요 없어.

MariaDB/InnoDB에서 이 문제가 발생하여 다음 방법으로 해결할 수 있었습니다.

  • 다른 MySQL/MariaDB 인스턴스의 올바른 데이터베이스에 필요한 테이블을 만듭니다.
  • 양쪽 서버의 정지
  • .ibd, .frm 파일을 원래 서버에 복사
  • 두 서버 모두 시작
  • 양쪽 서버에서 문제 테이블을 삭제하다

이 테마는 결과와 이유를 찾는 데 다소 시간이 걸렸습니다.

MaiaDB 5.4 사용, SuSE-LINUX tumblweed 경유

  1. 지정된 디렉토리의 일부 파일은 mariadb와 직접적인 관련이 없습니다.예를 들어, mysql mariadb용으로 지정된 디렉토리 내에 힌트, 텍스트 파일, bakup-copy를 몇 개 배치했습니다.그 때문에, 에러 메세지가 끊이지 않고, 서버가 기동하지 않게 되었습니다.Mariadb는 데이터베이스 파일(댓글, 백업, 경험 파일 등)을 감시하지 않는 다른 파일의 존재에 대해 매우 합리적이고 적대적인 것으로 보입니다.

  2. libreoffice를 클라이언트로 사용했을 때 이미 데이터베이스 작성과 작업에 많은 문제가 발생했고 몇 가지 크래시가 발생했습니다.그 크래시는 결국 나쁜 테이블을 만들어 냈다.

  3. 그 이유일 수도 있고 아직 삭제되지 않았지만 사용할 수 없는 테이블이 존재하기 때문일 수도 있습니다!! mysql mariadb 서버가 크래쉬하여 시작도 하지 않았습니다.

오류 메시지는 항상 동일합니다: "테이블 'some.table'이 엔진에 존재하지 않습니다."

하지만 막상 시작해보니 테이블은 정상으로 나타났지만 작업하는 것은 불가능했습니다.

그럼 보다 정확한 오류 메시지가 없으면 어떻게 해야 할까요?사용할 수 없는 테이블은 "CHECK TABLE" 또는 "mysqlcheck"와 함께 시스템의 명령줄에 표시되었습니다.따라서 파일 매니저에 의해 삭제되거나 시스템 수준에서 루트 또는 사용자에게 허용된 모든 파일을 삭제하면 문제가 해결되었습니다.

제안: 에러 메시지는, 예를 들면 「CHECK TABLE」(CHECK TABLE에 의해서 검출되지만, 서버가 동작하고 있지 않은 경우만) 또는 mysqlcheck에 의해서 검출됩니다만, 여기에서는 힌트나 bakups a.s.o.와 같은 다른 문제가 되는 파일이 표시되지 않습니다.

어쨌든 원래 데이터베이스 파일의 백업 복사본을 백업 볼륨에 저장하는 것이 큰 도움이 되었습니다.이를 통해 솔루션을 찾을 때까지 몇 번이고 확인하고 테스트하는 데 도움이 되었습니다.

모두 행운을 빈다 - 허버트

이전 MySQL과 Centos OS(6버전)는 지원되지 않았습니다.
어느 날 Plesk에 접속할 수 없었습니다.
Filezilla를 사용하여 var/lib/mysql/databasename에서 데이터베이스 파일을 복사하고 새로운 Centos 8 OS와 MariaDB를 탑재한 새 서버를 구입했습니다.Plesk에서 이전 데이터베이스와 동일한 이름으로 새 데이터베이스를 만들었습니다.
그런 다음 Filezilla를 사용하여 오래된 데이터베이스 파일을 새로 만든 데이터베이스 폴더에 붙여넣었습니다.phpmyadmin에서 데이터를 볼 수 있었지만, 여기에 기재되어 있는 것과 같은 에러가 발생하고 있었습니다.우연히 오래된 SQL 백업 덤프 파일이 있었어요덤프 파일을 가져왔는데 그 파일들이 오버랩이 됐어요.그런 다음 오래된 파일을 var/lib/mysql/databasename/Plesk에서 복구해야 했습니다.깜짝이야.됐다.6개월 이상의 주문 데이터를 복구했지만 손실은 없었습니다.

제 경우 db는 완전히 동작하고 있었지만 데이터베이스에 접속했을 때 아무런 영향 없이 워크벤치에 에러가 표시되었습니다.엔진에 존재하지 않는 테이블이 db에서 삭제한 오래된 테이블이라는 것을 알게 되었습니다(더 이상 필요 없습니다).그런데 실수로 이 테이블의 백업 파일 몇 개를 데이터베이스 사전(.frm 및 .ibd 파일)에 복사한 후 오류가 사라졌습니다.

언급URL : https://stackoverflow.com/questions/25039927/database-corruption-with-mariadb-table-doesnt-exist-in-engine

반응형