Export daily 24h data in addition to the full pg_dump to allow
downstream replicas to stay in sync without requiring full PG
replication.
We call this "incremental" in some places because perhaps later we will
decide on a different level of granularity, e.g. hourly or weekly.
Signed-off-by: Michael Winters <fedora@mwinters.net>
This uses the upstream template which runs a bunch of SQL to query the
DB via a monitoring user.
Scoped to db01.stg for testing at the moment.
Signed-off-by: Greg Sutcliffe <fedora@emeraldreverie.org>
This will unify all the handlers to use first uppercase letter for
ansible-lint to stop complaining.
I went through all `notify:` occurrences and fixed them by running
```
set TEXT "text_to_replace"; set REPLACEMENT "replacement_text"; git grep
-rlz "$TEXT" . | xargs -0 sed -i "s/$TEXT/$REPLACEMENT/g"
```
Then I went through all the changes and removed the ones that wasn't
expected to be changed.
Fixes https://pagure.io/fedora-infrastructure/issue/12391
Signed-off-by: Michal Konecny <mkonecny@redhat.com>
fix 1900 failures of the following case issue:
`name[casing]: All names should start with an uppercase letter.`
Signed-off-by: Ryan Lerch <rlerch@redhat.com>
* The password was being set to the prod one
* The allowed ip in the database was the phx2 one. ;(
* The sequences were too low, prod already passed those, so increase
them.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
It seems sometimes now db-datanommer is taking more than 24hours to
backup, and currently that means it starts another one while the
previous one is running. Thats no good for anyone, so lets put in a lock
wrapper to avoid that.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
Currently backups are taking 17-18 hours with 4 threads.
Now that we have 16 cpus defined there, lets bump that up to 8 and see
if that lowers things much. If not we can look at moving to another
compression, but the database is very large so lots of compression is
good to save disk space.
Also filter out another output of the backup job that causes cron
emails.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
This will log an explain for any query that takes more than 30s.
We likely will need to lower it to get the slow heavy queries that are
hitting koji's db.
This does require a restart, but after this we can change the min
duration with just a reload. If there are too many logs, we can set this
to -1 to never log.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
Using the 'fix outage' clause in freeze here. ;)
Basically adjust db-koji01 to use more memory and avoid
saturating i/o. With these settings, page loads look faster
and i/o is not saturated. We should try adding more cpus and such,
but that will require a reboot, so avoiding for now.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
db-koji01 is our only postgresql 15 install so far, but split out the
config from the 12 one we are using on RHEL8 to avoid making changes
there.
Also, lets try tweaking things:
- I am bumping cpus up to 88
- Tweak max workers/etc
- Try a higher i/o level since this db server is running on a virthost
with ssds.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
