|
| 1 | += Data retention in server |
| 2 | +:page-platform: Server v4.8, Server Admin |
| 3 | +:page-description: Learn how to configure data retention policies for MongoDB, PostgreSQL, and object storage buckets in your CircleCI server installation. |
| 4 | +:experimental: |
| 5 | + |
| 6 | +[#background] |
| 7 | +== Background |
| 8 | + |
| 9 | +You can set up retention policies for both Mongo and PostgreSQL to clean up data older than *n* days. The following sections outline the step-by-step process for implementing these retention policies in your server environment. |
| 10 | + |
| 11 | +[#setting-postgres-retention] |
| 12 | +== Step 1: Setting a retention period for PostgreSQL |
| 13 | + |
| 14 | +. Connect to a REPL session in one of the frontend pods by running the following commands: |
| 15 | ++ |
| 16 | +[source,bash] |
| 17 | +---- |
| 18 | +kubectl exec -it <frontend-xxx> -- /bin/bash |
| 19 | +---- |
| 20 | ++ |
| 21 | +Then, connect to the REPL: |
| 22 | ++ |
| 23 | +[source,bash] |
| 24 | +---- |
| 25 | +lein repl :connect 6005 |
| 26 | +---- |
| 27 | + |
| 28 | +. Once connected, the current setting can be verified using the following command: |
| 29 | ++ |
| 30 | +[source,clojure] |
| 31 | +---- |
| 32 | +(circle.http.api.admin-commands/get-setting :wfc-workflow-deletion-retention-period) |
| 33 | +---- |
| 34 | + |
| 35 | +. The retention period can be set as needed (the example below sets it to 90 days): |
| 36 | ++ |
| 37 | +[source,clojure] |
| 38 | +---- |
| 39 | +(circle.http.api.admin-commands/set-setting :wfc-workflow-deletion-retention-period 90) |
| 40 | +---- |
| 41 | + |
| 42 | +. The deletion interval can be verified by running: |
| 43 | ++ |
| 44 | +[source,clojure] |
| 45 | +---- |
| 46 | +(circle.http.api.admin-commands/get-setting :wfc-workflow-deletion-interval) |
| 47 | +---- |
| 48 | ++ |
| 49 | +By default, the interval is set to `0`. This value must be updated to a number greater than `0` for WFC deletion to run every *n* seconds. For example, the following command sets it to 1000 seconds: |
| 50 | ++ |
| 51 | +[source,clojure] |
| 52 | +---- |
| 53 | +(circle.http.api.admin-commands/set-setting :wfc-workflow-deletion-interval 1000) |
| 54 | +---- |
| 55 | + |
| 56 | +. In instances with significant data volumes, additional `workflows_conductor_event_consumer` replicas may be required to ensure deletion progresses smoothly until it aligns with the configured retention period. |
| 57 | + |
| 58 | +. The WFC event consumer pod logs can be checked to verify that deletion is progressing without errors. |
| 59 | + |
| 60 | +. The oldest `created_at` date for a job can be verified to ensure alignment with the retention period using the following command: |
| 61 | ++ |
| 62 | +[source,bash] |
| 63 | +---- |
| 64 | +kubectl exec postgresql-0 -- sh -c 'PGPASSWORD=$POSTGRES_PASSWORD psql -U "postgres" -d "conductor_production" -c "SELECT * FROM public.jobs ORDER BY created_at ASC LIMIT 2;"' |
| 65 | +---- |
| 66 | + |
| 67 | +[#setting-mongodb-retention] |
| 68 | +== Step 2: Setting a retention period for MongoDB (action logs) |
| 69 | + |
| 70 | +Retention limits for action logs can be configured in the same REPL session using the following commands: |
| 71 | + |
| 72 | +[source,clojure] |
| 73 | +---- |
| 74 | +(circle.http.api.admin-commands/set-setting :delete-old-builds.retention-limit-days 180) |
| 75 | +(circle.http.api.admin-commands/set-setting :delete-old-action-logs.enabled true) |
| 76 | +---- |
| 77 | + |
| 78 | +[#setting-s3-lifecycle-policies] |
| 79 | +== Step 3: Set up lifecycle policies for the S3 Bucket |
| 80 | + |
| 81 | +WARNING: **Risk of Irreversible Data Loss** + |
| 82 | +Incorrect lifecycle settings may result in data being removed earlier than expected and without recovery options. CircleCI bears no responsibility or liability for any data loss resulting from lifecycle configurations applied to your object storage buckets. |
| 83 | + |
| 84 | +After configuring retention limits for your MongoDB and PostgresDB objects, you can also apply object expiry policies to your S3 or GCS buckets. These policies typically expire objects at n+1 days, where n is the retention period set for your databases. |
| 85 | + |
| 86 | +NOTE: **Object Storage Paths** + |
| 87 | +If a retention policy of `n` days is configured for both MongoDB and PostgreSQL data, you can set `n+1` for **all objects** in your S3/GCS buckets to expire at `n+1` days. This ensures alignment between database retention and object storage retention. |
| 88 | + |
| 89 | +CAUTION: **Audit Logs** + |
| 90 | +Be sure to configure exceptions for critical paths, such as `audit-logs/*`, in accordance with your organization's compliance or audit requirements. Objects under these paths should not be expired by default. |
0 commit comments