일부 Magento 테이블은 InnoDB가 아닙니다. 모든 테이블을 InnoDB로 변환하는 것이 안전합니까?


16

AWS RDS 읽기 전용 복제본을 사용하고 있습니다. Magento의 메모리 엔진 테이블에 지속적으로 문제가 있습니다. 백업 및 읽기 전용 복제본의 경우 RDS는 InnoDB를 좋아합니다. 모든 테이블을 InnoDB로 안전하게 변경할 수 있습니까?

또한 AWS에서 다음과 같은 경고가 나타납니다.

DB 인스턴스 magento-monin-prod-db에는 InnoDB로 마이그레이션되지 않은 MyISAM 테이블이 포함되어 있습니다. 이 테이블은 특정 시점 복원을 수행하는 데 영향을 줄 수 있습니다. 이 테이블을 InnoDB로 변환 해보십시오. http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.CommonDBATasks.html#MySQL.CommonDBATasks.Tables 를 참조하십시오.

그럴듯한 대답

여전히 의견에 관심이 있습니다. 다음 24 시간 내에 문제가 발견되지 않으면 답변으로 추가하겠습니다. 아래에서 취한 단계는 지금까지 안전합니다. 가장 큰 관심사는 Magento의 메모리 엔진 테이블 (in_tmp로 끝나는 테이블)과 인덱싱에 미치는 영향이었습니다.

여기 내가 한 일이 있습니다.

  1. SELECT * FROM INFORMATION_SCHEMA.TABLES WHERE (ENGINE = 'Memory' OR ENGINE='MyIsam') AND TABLE_SCHEMA='magento_db'

    • 나에게 이것은 대부분 임시 인덱스 테이블과 마 젠토 모듈 테이블을 반환 했기 때문에 걱정할 중요한 코어 테이블이 많지 않고 물건이 팬에 부딪 칠 때 다른 테이블을 쉽게 실행할 수있는 테이블이 거의 없습니다.
  2. 반환 된 각 테이블에 대해 다음을 실행했습니다. Alter table {table-name} ENGINE=InnoDB;

InnoDB가 아닌 테이블이 없다면 이것을 시도하는 것이 긴장됩니다. 그러나 앞에서 말했듯이 내 인스턴스에는 수정해야 할 핵심 테이블이 거의 없었습니다.


이것을 프로덕션 환경에서 오랫동안 운영해 왔습니까? 그렇다면 어떻게 진행되고 있습니까? 문제가 발생 했습니까? 현재 MEMORY 엔진 인 * _tmp 인덱스 테이블에 대해 주로 생각하십시오.
— Michael Parkin

1
나는 이상한 것을 보지 못했습니다.
— TylersSN

확인해 주셔서 감사합니다.이 내용을 다시보고하도록하겠습니다.
— Michael Parkin

@michael parkin은 Solr 검색을 사용하고 있음을 명심하십시오. 이것이 잠재적으로 검색에 영향을 줄 수있는 다른 답변을 참조하십시오.
— TylersSN

1
우리는 대부분의 프로덕션 사이트 (MariaDB 10.0)에서 이것을 실행했으며 InnoDB로 실행되는 모든 테이블 (메모리 포함)은 훌륭하게 작동합니다
— Michael Parkin

답변:


11

다음 중 하나에 해당하면 데이터 유형을 InnoDB로 변경하는 것이 좋습니다.

  1. InnoDB 스토리지 엔진 이 전체 텍스트 검색을 지원 하는 MySQL 5.6.4 이상을 사용 하고 있습니다
  2. 기본 MyISAM 전체 텍스트 검색 기능을 사용하는 기본 Magento 검색 기능을 사용하지 않습니다. 이 기능은 시작하기가 까다 롭고 기본 Magento 검색에서 제공되는 기능 세트가 많이 남아 있기 때문에 Lucene 또는 Sphinx 또는 최고의 Algolia 호스팅 검색을 사용하는 것이 좋습니다 .

개인적으로 나는 위험을 최소화하고 다른 DB 구성 편차 또는 문제를 확인하기 위해 Magento DB 복구 도구 를 사용 하여이 작업을 수행하는 것이 좋습니다 . InnoDB는 이상적인 엔진이며, 그럼에도 불구하고 전체 텍스트 제한 사항 입니다.


1
우리는 태양 검색을 사용하고 있습니다. 따라서 검색에 관한 한 명확해야합니다.
— TylersSN

InnoDB를 이상적인 엔진으로 생각하지는 않습니다. 검색어가 많으면 MyISAM에 비해 속도가 매우 느립니다. 나는 종종 InnoDB가 업데이트를 더 빨리하고 대부분의 쿼리가 업데이트이므로 더 빠르다고 들었습니다. 나는 총 반대를 참조하십시오. 내가 가진 모든 사이트에 대해 쿼리를 업데이트 / 추가하는 훨씬 더 많은 검색어가 있습니다. 모든 테이블을 InnoDB로 전환하려고 시도했지만 페이지로드 시간이 기본적으로 지연되지 않고 (0.1 초) 10 초로 단축되었습니다! 속도에 이상적인 엔진이므로 전체 텍스트 검색을 지원하기 때문에 모든 것을 MyISAM으로 다시 변환했습니다.
— Tim Eckel

@ ben-lessani-sonassi는 평평한 것으로 입증되었으며 MySQL은 거의 모든 다른 성능을 가진 전체 성능에 대한 실제 드래그가 거의 없음을 시간과 시간을 보았 기 때문에 Tim은 동의 합니다. 로드시에도 800ms 미만의 응답에 대한 최적화가 필요합니다. InnoDB는 핵심 b / c입니다. Mage Core는 각 사용자의 "보기"작업을 기록하기 위해 DB ~ 10X에 작성하고 Solr은 검색 성능 및 품질에 가장 적합합니다. :)
— Bryan 'BJ'Hoffpauir 주니어

1
그렇다면 InnoDB로 변환하는 것은 외래 키 관계를 모두 처리하는 방법과 해당 fkey 관계에서 계단식 삭제에 의존하는 삭제는 얼마나 완전한가? 다시 말해, 관계를 유지하지 않고 남게 될 쓰레기를 어떻게 처리합니까?
— Fiasco Labs

@FiascoLabs이 주석 스레드를 확인한 지 오래되었지만 Q / A의 초점은 FROM MyISAM을 InnoDB로 변환하는 것입니다. 나는 당신의 언급이 이미 InnoDB라고하는 Relational 기능을 가진 것들을 추측하고 있습니다. MyISAM 은 MySQL 5.7에서 FK와 Transactions를 지원하지 않지만 InnoDB는 SQL 표준에서 약간 벗어
— Bryan 'BJ'Hoffpauir Jr.

2

Afaik은 모든 테이블을 InnoDB로 변환하지 않아야합니다.

catalogsearch_fulltext InnoDB는 적어도 MySQL 5.6 (iirc)까지는 전체 텍스트 검색을 지원하지 않기 때문에 MyISAM을 유지해야합니다.

그러나 다른 모든 테이블의 경우 안전해야합니다.



2

방금 MySQL 기본 엔진을 InnoDB로 변경했으며 대부분의 Magento 테이블이 기적적으로 InnoDB로 변환되었습니다 (일부는 여전히 MyISAM이고 일부는 메모리입니다).

내가 이걸 나눌 줄 알았는데 ...

당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.