Mysql
 sql >> база данни >  >> RDS >> Mysql

MAMP PRO се срива; MySQL няма да стартира при рестартиране

ПРЕДГОВОР: Това звучи лошо, но моля, не забравяйте да прочетете всичко в този отговор, преди да действате. Не можете да разрушите нещата по-лошо, като отделите време. Прочетете всяка стъпка и се надяваме, че това ще бъде достатъчно ясно, за да следвате и да пуснете своя MySQL сървър на база данни в MAMP Pro и да работи отново.

Така че изглежда, че вашите InnoDB бази данни се сринаха. Не самото приложение. Ключът е тук в дневника:

140527 15:06:58 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 791075520
140527 15:06:58  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 791076717
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 8402.
InnoDB: You may have to recover from a backup.

И изглежда, че използвате MAMP PRO тук:

/Library/Application Support/appsolute/MAMP PRO/db/mysql

Въпросът е дали имате резервно копие на базите данни на MAMP Pro? Или чрез mysqldump или нещо друго? Имате ли други бази данни InnoDB във вашата инсталация на MAMP?

Освен това казвате, че сте успели да стартирате mysqldump , но наистина не е възможно базата данни да се срине. Така че предполагам, че сте изпълнили mysqldump това беше друга, отделна инсталация на MySQL във вашата система. MySQL двоични файлове като mysqldump в MAMP или MAMP Pro не са същите като mysqldump в цялата система . Те са две 100% различни инсталации. Можете да проверите кой mysqldump се използва чрез въвеждане на тази команда:

which mysqldump

За да видите пълния път на това, което вярвате, че сте използвали. Инсталирането на MAMP на mysqldump — и други свързани двоични файлове — се намира тук:

/Applications/MAMP/Library/bin/

И да го стартирате директно, без да променяте вашия $PATH стойност (съвсем друго нещо) е да го стартирате така:

/Applications/MAMP/Library/bin/mysqldump

МОЛЯ, ПРОЧЕТЕТЕ ВНИМАТЕЛНО: Моля, имайте предвид, че съветът, който ви давам по-долу, е, че представям всички начини, по които бих се справил с подобна ситуация. Ако базата данни InnoDB не е важна, просто направете първото ми предложение за изхвърляне на специфичните за InnoDB DB файлове. Ако имате mysqldump архивиране, направете същото, но възстановите mysqldump резервно копие.

Също така InnoDB не двигател за съхранение по подразбиране. Трябва да положите всички усилия, за да настроите това. По подразбиране е MyISAM. Всяка нова БД, създадена в MySQL, ще бъде MyISAM. Така че това ще ви помогне. Трябва да сложите капачка за мислене, за да разберете кои бази данни имат зададени InnoDB механизми за съхранение. Ако кажете, че имате 25, но само 1 има InnoDB, лесно решение. Но също така, ако имате 25 бази данни, трябва да придобиете навика да правите редовно mysqldump резервни копия. Ако имахте резервни копия, това би било главоболие, но просто нещо за решаване.

ЕДНА ОПЦИЯ:Изтрийте повредените неща на InnoDB и възстановете от mysqldump резервно копие.

Първото нещо, което бих направил на ваше място, е архивиране на mysql директория в /Library/Application Support/appsolute/MAMP PRO/db/ така че можете поне да направите резервно копие на повредените файлове за всеки случай.

След това бих изтрил следните файлове:

/Library/Application Support/appsolute/MAMP PRO/db/mysql/ib_logfile0
/Library/Application Support/appsolute/MAMP PRO/db/mysql/ib_logfile1
/Library/Application Support/appsolute/MAMP PRO/db/mysql/ibdata1

Това са специфични за InnoDB файлове. Изтрийте ги и след това опитайте да стартирате MAMP отново. Трябва да се появи. Но всяка база данни InnoDB в MAMP ще бъде в някакво „зомби“ състояние. Трябва да изтриете тези бази данни и да ги създадете отново от архивиране. Или от нулата, ако можете.

ДРУГА ОПЦИЯ:Опитайте да стартирате MySQL сървъра и да работи отново с innodb_force_recovery .

Сега при случайния шанс, който трябва да възстановите тази DB, можете да стартирате опит за задаване на innodb_force_recovery както е описано тук.

За MAMP Pro изглежда, че можете да редактирате своя конфигурационен файл на MySQL според тези инструкции:

  1. Стартирайте MAMP Pro.
  2. Спрете сървъра MAMP Pro, ако работи.
  3. Изберете Файл -> Редактиране на шаблон -> MySQL my.cnf
  4. Появява се прозорец на редактор.
  5. Ако се появи предупредително съобщение, потвърдете с OK.
  6. Намерете секцията „[mysqld]“
  7. Под последния ред на този раздел добавете този ред:innodb_force_recovery = 1

И както обяснява документацията на MySQL , това е стриктно за да стартирате базата данни, за да можете да направите резервно копие чрез mysqldump :

Сега има около 6 различни стойности за innodb_force_recovery но наистина трябва да опитате само с 1 за сега. Ако искате да опитате всеки от 6-те, ето разбивка:

Ако случайно стартирате базата данни и след това можете да направите mysqldump тогава честито! Вие сте на ясно! Най-добрите следващи стъпки са да

  1. Спрете сървъра на базата данни MySQL
  2. Премахнете innodb_force_recovery опция от конфигурацията на MySQL, така че сървърът на базата данни да може да работи нормално.
  3. Рестартирайте сървъра на базата данни MySQL.
  4. Изтрийте повредената база данни MySQL от сървъра (Не изтривайте дъмп файла! Това е вашето резервно копие!)
  5. Създайте нова база данни, която искате да възстановите.
  6. Импортирайте mysqldump архивиране в новата база данни.

И трябва да свършите.



  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Извличане на уникални стойности и бройки за всяка

  2. Spark JoinWithCassandraTable на ключа на дяла TimeStamp ЗАПЯНА

  3. Най-добри практики за меко изтриване (PHP/MySQL)

  4. Как да съхраня UTC ISO8601 дата в MySQL база данни?

  5. Правилен начин за преминаване между 5 000 до 100 000 стойности в mysql WHERE клауза