2012-06-27 17 views
9

Tôi có MySQL nàyCách tốt nhất để giữ cho TYPO3 sys_log đẹp và sạch sẽ?

DELETE FROM sys_log 
WHERE sys_log.tstamp < UNIX_TIMESTAMP(ADDDATE(NOW(), INTERVAL -2 MONTH)) 
ORDER BY sys_log.tstamp ASC 
LIMIT 10000 

Đây có phải là tốt cho việc giữ sys_log nhỏ, nếu tôi cronjob nó?

+1

Thực tế là cronjob là động từ? – HerrSerker

+0

Không, đó là danh từ. Cronjob này. Một cronjob. Mặc dù cá nhân tôi không quan tâm đến sự sáng tạo từ sáng tạo ở đây. Nếu bạn quan tâm, hãy cẩn thận để chỉnh sửa? – wirap

Trả lời

8

Có và Không

KHÔNG PHẢI LÀ nếu bạn quan tâm đến lịch sử hồ sơ của bạn. Bạn có thể hoàn nguyên các thay đổi đối với hồ sơ (nội dung, trang, v.v.) bằng cách sử dụng bảng sys_history. Các bảng sys_history và sys_log có liên quan. Khi bạn cắt bớt sys_log, bạn cũng mất khả năng khôi phục bất kỳ thay đổi nào đối với hệ thống. Khách hàng của bạn có thể không thích điều đó.

IS nếu bạn chỉ quan tâm đến kích thước sys_log. Cắt ngắn bảng thông qua cron là tốt.

Trong TYPO3 4.6 trở lên, bạn có thể sử dụng tác vụ lên lịch thu thập rác của Bảng als pgampe nói. Đối với phiên bản TYPO3 dưới 4.5, bạn có thể sử dụng tiện ích mở rộng tablecleaner. Nếu bạn xóa tất cả các bản ghi khỏi sys_log cũ hơn [N] ngày, bạn cũng sẽ giữ lại lịch sử bản ghi của mình trong [N] ngày. Đó có vẻ là giải pháp tốt nhất cho tôi.

Và hãy cố gắng sửa chữa những gì được điền sys_log của bạn ở nơi đầu tiên ;-)

+0

Nhận xét nhanh - IIRC có một công việc lên lịch, vì vậy bạn có thể giữ nhà vệ sinh "bên trong" cài đặt TYPO3 của bạn và không có các công việc cli bên ngoài khác đang chạy –

6

Có một task scheduler cho việc này.

Nó được gọi là Table garbage collection (scheduler).

Trong TYPO3 4.7, nó chỉ có thể làm sạch bảng sys_log. Bắt đầu từ TYPO3 6.0, nó cũng có thể làm sạch bảng sys_history. Bạn có thể định cấu hình số ngày và các bảng cần làm sạch.

Tiện ích mở rộng có thể đăng ký thêm các bảng để làm sạch.

+0

Nó được gọi là gì? – HerrSerker

+0

Tôi đã thêm tên và một vài từ khác vào câu trả lời. – pgampe

+0

trong typo3 4.7.8 nhiệm vụ này không thể được lên lịch từ bên trong backend vì các lỗi khác nhau trong phần mở rộng của trình lên lịch.Xem lỗi http://forge.typo3.org/issues/48022, khác: http://forge.typo3.org/projects/typo3v4-core/repository/revisions/f3f892ee2d3915b1934a7ce62cc921a3555cf8be/diff/typo3/sysext/scheduler/class. tx_scheduler_module.php – knb

1

Một nguyên nhân phổ biến đối với sys_log bảng lớn là những vấn đề/lỗi trong một trong các phần mở rộng được sử dụng trong quá trình cài đặt Typo3.

Một ví dụ phổ biến khi một phiên bản cũ của tx_solr được sử dụng:

Core: Error handler (FE): PHP Warning: Invalid argument supplied for foreach() in typo3conf/ext/solr/classes/class.tx_solr_util.php 
Core: Error handler (FE): PHP Warning: array_reverse() expects parameter 1 to be array, null given in typo3conf/ext/solr/classes/class.tx_solr_util.php line 280 

Tập hợp các hồ sơ sẽ bật lên trong sys_log mỗi phút hoặc lâu hơn dẫn đến hàng triệu bản ghi trong một khoảng thời gian ngắn.

May thay, các loại bản ghi này không có bất kỳ ảnh hưởng nào đối với lịch sử bản ghi trong sys_history và chức năng cuộn lại được liên kết, vì vậy sẽ an toàn khi xóa chúng.

Nếu bạn có một lượng lớn sys_log này có thể sẽ gây ra vấn đề với LOCK timeout, vì vậy bạn sẽ phải giới hạn truy vấn xóa:

delete from sys_log where details LIKE 'Core:%' LIMIT 200000;

1

Câu trả lời ngắn:

Không, nó chắc chắn không phải là một ý tưởng hay. Nếu bạn thực sự muốn xóa nội dung khỏi sys_log, hãy nhớ rằng sys_history vẫn đang tham chiếu đến nó. Bạn cũng nên làm tương tự cho sys_history.

Hoặc, chỉ cần làm như sau:

DELETE FROM sys_log WHERE NOT EXISTS 
(SELECT * FROM sys_history WHERE sys_history.sys_log_uid=sys_log.uid) 
AND recuid=0 AND tstamp < $timestamp LIMIT $limit 

Hãy thoải mái để tối ưu hóa này cho các yêu cầu của bạn.

gì bạn cũng có thể làm một cách an toàn (mà không ảnh hưởng sys_history) được xóa hồ sơ với sys_log.error = 0.

Câu trả lời rõ ràng:

  • Làm thử nghiệm của bạn trong việc phát triển, chứ không phải sản xuất . Loại bỏ lỗi của bạn trong phát triển. Đào tạo và khoan các nhà phát triển của bạn để theo dõi sát vấn đề này.
  • Thiết lập mức độ gỡ lỗi của bạn là Verbose (cảnh báo) về phát triển nhưng lỗi chỉ trong sản xuất
  • Giám sát sys_log chặt chẽ, bởi kịch bản hay bằng tay

Một số có thêm gợi ý:

  • Thường xuyên xem nhật ký nhật ký và loại bỏ các vấn đề. Bạn có thể xóa lỗi cụ thể từ sys_log khi bạn đã xử lý vấn đề (xem sys_log.error! = 0, sys_log.details). Bạn có thể làm điều này với một lệnh cơ sở dữ liệu hoặc trên các phiên bản Typo3 mới hơn sử dụng "HỆ THỐNG: log" nút trong backend và sử dụng "Delete lỗi tương tự":

enter image description here

  • Trên mỗi bản cập nhật lớn , chúng tôi thực hiện truncate sys_logtruncate sys_history, cùng với việc sử dụng trình dọn dẹp lowlevel (ví dụ: xóa các bản ghi đã xóa = 1). Trước tiên, hãy nhớ nói chuyện với ai đó trong số gần với người chỉnh sửa, vì điều này sẽ xóa toàn bộ lịch sử. Chúng tôi làm tốt với việc giữ phiên bản cũ hơn của cá thể TYPO3 trực tuyến chỉ với quyền truy cập nội bộ. Chúng tôi muốn giữ mọi thứ sạch sẽ :)

Trên các phiên bản TYPO3 mới hơn, sẽ không còn vấn đề liên quan giữa sys_log và sys_history nữa. Nhìn vào thay đổi Breaking #55298 trong TYPO3 9.

Các vấn đề liên quan