Mario Mahovlić wrote: > However, our issue is not with primary cloning, but with database startup after > clone/basebackup is done. > Startup of standby database is successful but it takes around 6 hours, during > which time all we get from DB is: FATAL: the database system is starting up. > We have noticed that this startup process uses only 1 cpu core on our machine > which has 8. > > Our database size is around 570GB, and we are using schema per tenant data > distribution, so we have separate schemas for each of the users of our > application, as it suits our needs well. > Because of this our database has about 40000 schemas with 5 tables per each > schema. > We suspect the reason behind this long startup is amount of data and/or large > number of schemas/tables on database, however we would like to confirm that somehow. > > So our questions are following: > What could be possible reasons for startup as long as this? > How can we figure out what exactly does postgres startup process do all this time, > is there any documentation on what exactly does postgres database do on startup as > we have not found any info on this? > Is there any way to speed up this startup process? > Can we mitigate this startup time in cases when we do planned switchover for > maintenance by using pg_rewind instead of pulling all data from primary again? > So if we shut down the database gracefully and use pg_rewind will startup process > be faster? You could use "perf top" to see where the time is spent or have a look at the PostgeSQL log file. pg_basebackup creates a checkpoint when it starts, so checkpoints that happen too rarely cannot be the problem. Did you use "pg_basebackup -X stream" to copy the WAL files along with the data? If yes, is there a lot of them? If no, how do you restore the required WAL files? Yours, Laurenz Albe -- Cybertec | https://www.cybertec-postgresql.com
