새로운 변경 로그 테이블의 역학 (예 : catalog_category_product_cat_cl)


15

방금 데이터베이스에서 언급 된 테이블을 발견했습니다. 나는 그들이 Magento EE 1.13에서 새로운 것 같아서 새로운 색인 생성과 관련이있을 수 있습니다.

+ ---------------------------------------- +
| catalog_category_flat_cl |
| catalog_category_product_cat_cl |
| catalog_category_product_index_cl |
| catalog_product_flat_cl |
| catalog_product_index_price_cl |
| cataloginventory_stock_status_cl |
| catalogsearch_fulltext_cl |
| enterprise_url_rewrite_category_cl |
| enterprise_url_rewrite_product_cl |
| enterprise_url_rewrite_redirect_cl |
+ ---------------------------------------- +

이 테이블은 어떻게 작동합니까? 목적은 무엇입니까?

시간이 지나면 자동으로 청소됩니까?

해당 테이블을 백업에 포함시키는 것이 합리적입니까?


답변:


15

이러한 변경 로그 (따라서 _cl접미사) 테이블은 특정 엔티티가 변경 될 때마다 MySQL 트리거를 통해 채워집니다.
그런 다음 인덱서 크론 작업 (1 분마다 실행)은 이러한 변경 로그를 Magento 인덱스의 증분 업데이트로 적용합니다.

MySQL 트리거를 사용하여 변경 로그 테이블을 작성하면 PHP를 사용하지 않고 일반 SQL을 사용하여 새 데이터를 추가하더라도 작동한다는 이점이 있습니다.
따라서 비표준 가져 오기 방법 (또는 Mage_ImportExport 모듈)을 사용하는 경우 전체 재 색인을 실행할 필요가 없습니다.


때때로 이러한 테이블을 자르는 것이 안전합니까? 현재 25m 기록.
Steve Robbins

확실하지 않다. 문제는 Magento가 해당 테이블에 저장된 버전에 따라 달라질 수 있다는 것입니다. 최신 버전을 제외한 모든 버전을 삭제하는 것이 안전하지만 위험을 감수하는 것이 좋습니다. 어쩌면 잘리는 것조차 안전 할 것입니다.
비나이

5
Enterprise_Mview 모듈에는 이미 이러한 테이블을 정리하는 기능이 있습니다. 각 테이블에서 최신 version_id를 가져와 enterprise_mview_metadataversion_id가 그보다 낮은 행을 삭제합니다. 시스템> 구성> (고급 섹션)> 인덱스 관리로 이동하고 인덱스 정리 스케줄에서 스케줄 정리 사용을 예로 설정하여 인덱스 정리를 사용할 수 있습니다.
Tyler V.
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.