log_civicrm needs backup like civicrm
(Killing this as they are all in one DB & triggers are covered elsewhere)
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Eileenmcnaughton | T77938 [epic] Dedupe CiviCRM | |||
| Resolved | None | T111702 [epic] Dedupe exact matches | |||
| Duplicate | None | T124695 Civi: can the Change Log be used to recover contribs that have been inadvertently deleted? | |||
| Resolved | Eileenmcnaughton | T117630 Dedupe merge failed to relink a contribution? | |||
| Resolved | None | T117466 Q3 GOALS! (January-March) Keep at top of Q3 column | |||
| Resolved | None | T111704 [epic] Make deduping reversible | |||
| Resolved | awight | T122411 Changing email address in Civi should be exported to Silverpop | |||
| Resolved | Eileenmcnaughton | T132056 Turn logging on on live | |||
| Resolved | Eileenmcnaughton | T130163 Finalise sql & process for turning logging on on live | |||
| Resolved | Eileenmcnaughton | T133745 Update trigger mysql in git to reflect latest change from upstream (connection_id) | |||
| Invalid | Jgreen | T133613 configure database backups for new log_civicrm database |
Event Timeline
Comment Actions
Hi Jeff,
Are we definitely going with the same DB? I think we are - in which case I need to tweak the mysql for Monday to that
Comment Actions
The tables are already backed up, included with the rest of the civicrm
database.
I'm not sure what to do about the triggers--since they're code and not
data I'm not sure of the additional value of backing them up over what's
already tracked in revision control.
Comment Actions
@awight any concerns with leaving backing them up in favour of relying on the git version / the fact that they can be regenerated at will
Comment Actions
@Eileenmcnaughton
The only benefit I can think of is that backups would give us a record of which triggers were actually deployed, but that seems pretty secondary.
Should we make another TODO, to generate the trigger SQL as part of any schema changes and be sure that it's always up to date?
Comment Actions
AFAIK a dump only provides the state of the database at dump time, so I
don't think it can be used to establish a cronology of queries vs which
triggers were in play at the time of the query.