# Startup of replicaset takes very long **URL:** \ **Category:** Percona Operator for MongoDB\ **Created:** [November 30, 2024, 12:17am UTC](https://forums.percona.com/t/startup-of-replicaset-takes-very-long/35360 "2024-11-30T00:17:07Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![jamoser](https://avatars.discourse-cdn.com/v4/letter/j/b2d939/32.png) [@jamoser](https://forums.percona.com/u/jamoser)\ **Post date:** [November 30, 2024, 12:17am UTC](https://forums.percona.com/t/startup-of-replicaset-takes-very-long/35360/1 "2024-11-30T00:17:07Z")
Hello I have replicas = 3 and during startup, why does one pod after the other get started? Lets say 1 pod takes 30min (after a “forced” shutdown), then you have to wait 3x30min. Any other options? Regards John ---
**Author:** ![Sergey\_Pronin](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/sergey_pronin/32/14887_2.png) [@Sergey\_Pronin](https://forums.percona.com/u/Sergey_Pronin)\ **Post date:** [December 2, 2024, 8:37am UTC](https://forums.percona.com/t/startup-of-replicaset-takes-very-long/35360/2 "2024-12-02T08:37:08Z")
Hey @jamoser . > why does one pod after the other get started It is the default behaviour of a StatefulSet. It uses [OrderedReady Pod Management](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#deployment-and-scaling-guarantees). It is possible to change it by setting .spec.podManagementPolicy. But: 1. I’m not sure that it is safe for replica set. I will need to consult with our experts. 2. I don’t see it being supported in the Operator right now (you can’t set this option in the custom resource). But also I’m curious - why it takes 30min to start a single Pod? What is the main driver there? ---
**Author:** ![jamoser](https://avatars.discourse-cdn.com/v4/letter/j/b2d939/32.png) [@jamoser](https://forums.percona.com/u/jamoser)\ **Post date:** [April 16, 2025, 2:53pm UTC](https://forums.percona.com/t/startup-of-replicaset-takes-very-long/35360/3 "2025-04-16T14:53:31Z")
Hello There is the functionality pause: true | false to shutdown the cluster / start the cluster. Sometimes (and very often) it just does not work. The only way how to “gracefully” shutdown is, to set the replicas on the kubernetes statefulset to → 0 I would assume that the newly introduced terminationGracePeriod (on Percona level) would be active and therefore wait until MongoDB is able to shut down - seems it’s not the case. Also it seems you do not do a flush before the MongoDB shutdown. This all results that the MongoDB in the new pod has first do a crash recovery. This can take in our case for ex. on a balanced disk with 100’000 collections, very very long. So imo something is not clean regarding shutdown of the replica pods. Regards John ---
**Author:** ![Slava\_Sarzhan](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/slava_sarzhan/32/3196_2.png) [@Slava\_Sarzhan](https://forums.percona.com/u/Slava_Sarzhan)\ **Post date:** [April 29, 2025, 6:43pm UTC](https://forums.percona.com/t/startup-of-replicaset-takes-very-long/35360/4 "2025-04-29T18:43:49Z")
> [@jamoser](#): > > terminationGracePeriod Hi @jamoser Do you use custom value for terminationGracePeriod or not? ---
**Author:** ![jamoser](https://avatars.discourse-cdn.com/v4/letter/j/b2d939/32.png) [@jamoser](https://forums.percona.com/u/jamoser)\ **Post date:** [April 30, 2025, 7:21am UTC](https://forums.percona.com/t/startup-of-replicaset-takes-very-long/35360/5 "2025-04-30T07:21:52Z")
I would assume that there is a default value (hopefully the same value as in kubernetes = 30 sec). And that is sufficient so that all pods resp. mongodb’s shutdown properly. I can see that in the logs. ---
**Author:** ![Slava\_Sarzhan](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/slava_sarzhan/32/3196_2.png) [@Slava\_Sarzhan](https://forums.percona.com/u/Slava_Sarzhan)\ **Post date:** [April 30, 2025, 9:49am UTC](https://forums.percona.com/t/startup-of-replicaset-takes-very-long/35360/6 "2025-04-30T09:49:24Z")
Hi, on one hand, you can see that MongoDB is shutting down properly, but at the same time, the database is going through crash recovery. Am I right? ---
**Author:** ![jamoser](https://avatars.discourse-cdn.com/v4/letter/j/b2d939/32.png) [@jamoser](https://forums.percona.com/u/jamoser)\ **Post date:** [April 30, 2025, 2:26pm UTC](https://forums.percona.com/t/startup-of-replicaset-takes-very-long/35360/7 "2025-04-30T14:26:03Z")
Yes - her an example of a cluster which was idle for more then 1 week. Shutdown sequence (rs 0): [I will provide a better example] ---
**Author:** ![Slava\_Sarzhan](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/slava_sarzhan/32/3196_2.png) [@Slava\_Sarzhan](https://forums.percona.com/u/Slava_Sarzhan)\ **Post date:** [May 15, 2025, 1:18pm UTC](https://forums.percona.com/t/startup-of-replicaset-takes-very-long/35360/8 "2025-05-15T13:18:15Z")
> [@jamoser](#): > > to shutdown the cluster / start the cluster. Sometimes (and very often) it just does not work. The only way how to “gracefully” shutdown is, to set the replicas on the kubernetes statefulset to → 0 Do you change sts directly or use cr for it? Using cr is right way, and that’s why we do not recommend manually changing the sts object when scaling down a cluster. We also need to understand why pause does not work. Maybe your cluster is in an error state, or maybe you have some errors in the operator log. ---
**Author:** ![jamoser](https://avatars.discourse-cdn.com/v4/letter/j/b2d939/32.png) [@jamoser](https://forums.percona.com/u/jamoser)\ **Post date:** [August 14, 2025, 7:52am UTC](https://forums.percona.com/t/startup-of-replicaset-takes-very-long/35360/9 "2025-08-14T07:52:42Z")
Hello ![image](https://us1.discourse-cdn.com/flex019/uploads/percona1/original/3X/d/7/d73b3c7ce19f38321ca8f42598db1a6c5c7f0644.png) This is a nice example, rs-2 does not startup because the disk is full. The cluster is not accepting any configuration changes via cr.yaml or kubectl cmds. I have to resize replicas to 0 and then back to 3 on Statefulset level. And then the cr.yaml changes are applied. So something is wrong how you manage the cluster. Regards, John