Change Details

Civicrm's database uses log_% tables to store each change to corresponding tables. The log_% are populated by triggers that copy each write to a table to the corresponding log table. Row compression is in use. They grow without expiration, and with about four years of historical data they account for about 50% of the total disk footprint of the civicrm database. We've talked about expiration timelines and it sounds as though FR tech agrees that 1 year may be an acceptable max age for data in log_% tables. This task is to address that question and to develop a process to purge old data that can be automated. There are also several log tables that are not useful, which we should be able to disable altogether. Tables with low historical value: * log_civicrm_financial_item * log_civicrm_financial_trxn

Civicrm's database uses log_% tables to store each change to corresponding tables. The log_% are populated by triggers that copy each write to a table to the corresponding log table. Row compression is in use. They grow without expiration, and with about four years of historical data they account for about 50% of the total disk footprint of the civicrm database. Extrapolating from testing with log_civicrm_activity, if we were to trim these tables to records newer than 1 year, we would recover about 308GB or 37% the overall civicrm database footprint. We've talked about expiration timelines and it sounds as though FR tech agrees that 1 year may be an acceptable max age for data in log_% tables. This task is to address that question and to develop a process to purge old data that can be automated. There are also several log tables that are not useful, which we should be able to disable altogether. Tables with low historical value: * log_civicrm_financial_item * log_civicrm_entity_financial_trxn * log_civicrm_financial_trxn * log_civicrm_line_item * log_civicrm_mailing * log_civicrm_subscription_history * log_civicrm_mailing_job

Civicrm's database uses log_% tables to store each change to corresponding tables. The log_% are populated by triggers that copy each write to a table to the corresponding log table. Row compression is in use. They grow without expiration, and with about four years of historical data they account for about 50% of the total disk footprint of the civicrm database. Extrapolating from testing with log_civicrm_activity, if we were to trim these tables to records newer than 1 year, we would recover about 308GB or 37% the overall civicrm database footprint. We've talked about expiration timelines and it sounds as though FR tech agrees that 1 year may be an acceptable max age for data in log_% tables. This task is to address that question and to develop a process to purge old data that can be automated. There are also several log tables that are not useful, which we should be able to disable altogether. Tables with low historical value: * log_civicrm_financial_item * log_civicrm_entity_financial_trxn * log_civicrm_financial_trxn * log_civicrm_line_item * log_civicrm_mailing * log_civicrm_subscription_history * log_civicrm_mailing_job