MariaDB에서 대용량 ibd 파일에 대해 테이블 최적화

MariaDB에서 대용량 ibd 파일에 대해 테이블 최적화

우리는 MariaDB를 사용하는 WP_options 테이블이 수천 개의 레코드를 테이블에 쓰는 악성 플러그인으로 인해 계속 증가하는 WP_options 테이블을 사용하는 WordPress 웹사이트가 있습니다.플러그인 유지 관리자가 아직 문제를 해결하지 못했고, DELETE 문을 통해 이러한 '일시적'(템프) 레코드를 수동으로 제거해야 합니다.문제는 ibd 파일이 계속 증가하여 현재 35GB의 크기를 가지고 있다는 것입니다.이 문제가 해결되면 테이블 위에 Optimize TABLE을 하여 정리할 계획입니다.그것이 그 모든 공간을 다시 확보하는 최선의 방법입니까?이 작업을 수행하려면 최대 40GB의 여유 공간이 필요할 것으로 예상되며 최적화 테이블에 걸리는 시간은 얼마나 됩니까?이 표는 워드프레스에서 꽤 많이 사용하기 때문에, 잠금을 방지하기 위해 최적화하면서 웹사이트를 오프라인으로 전환하는 것이 가장 좋을 것 같습니다.해결할 수 있는 가장 빠른 방법을 찾아보겠습니다.

적어도 이런 불량 기록들이 성장의 원인이라고 생각합니다.다음은 표에서 상위 10개 유형의 항목 목록입니다.

MariaDB [wmnf_www]> SELECT    substr(`wp_options`.`option_name`, 1, 18) AS `option_name`,   count(`wp_options`.`option_value`) AS `cnt` FROM   `wp_options` GROUP BY   substr(`wp_options`.`option_name`, 1, 18) ORDER BY   `cnt` DESC LIMIT 10;
+--------------------+-------+
| option_name        | cnt   |
+--------------------+-------+
| _transient_timeout | 21186 |
| _transient_ee_ssn_ | 12628 |
| _transient_jpp_li_ |   222 |
| _transient_externa |   125 |
| _transient_wc_rela |    63 |
| jpsq_sync-14716436 |    50 |
| wpmf_current_folde |    35 |
| _wc_session_expire |    34 |
| jpsq_sync-14716465 |    29 |
| jpsq_sync-14716417 |    25 |
+--------------------+-------+
10 rows in set (0.17 sec)

_transient_ee_ssn_ 및 _transient_timeout_ee_는 문제가 되고 있으며 계속 증가하고 있습니다. 위의 세트에서 유일하게 어젯밤 이후로 성장했으며 초기에는 800K 레코드로 발견되었습니다.플러그인 관리자가 안전하다고 해서 계속 기록을 삭제하고 있습니다.그런데 이게 ibd 파일이 커지는 원인인가요?

---UPDATE--- 이상하게도 문제가 해결되지 않고 수천 개의 일시적인 레코드가 계속 생성되고 있지만 이 ibd 인덱스 파일은 현재 성장을 멈추고 있습니다.주말 동안 20GB에서 현재 39GB로 꾸준히 증가했지만 몇 시간 만에 성장하지 못했습니다.혹시 한계가 있거나 다른 이유로 파일이 증가하고 있는 것은 아닐까요?

Perconapt-online-schema-change tool을 사용하여 테이블을 다시 만드는 것이 더 나은 해결책이 될 것 같습니다.그러면 테이블이 다시 생성되고 모든 데이터가 새 테이블로 이동한 다음 이전 테이블이 삭제됩니다.이렇게 하면 데이터베이스가 오랫동안 잠기지 않습니다.

언급URL : https://stackoverflow.com/questions/47261076/optimize-table-in-mariadb-for-large-ibd-file