# Reschedule automatic midnight cluster sync?

**URL:** https://discuss.aerospike.com/t/reschedule-automatic-midnight-cluster-sync/4650
**Category:** Tuning
**Created:** [September 25, 2017, 5:06pm UTC](https://discuss.aerospike.com/t/reschedule-automatic-midnight-cluster-sync/4650 "2017-09-25T17:06:58Z")
**Posts on this page:** 5
**Page:** 1

<div class="post-metadata">

### Author: ![muriani](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.aerospike.com/muriani/32/904_2.png) [@muriani](https://discuss.aerospike.com/u/muriani)
#### Post date: [September 25, 2017, 5:06pm UTC](https://discuss.aerospike.com/t/reschedule-automatic-midnight-cluster-sync/4650/1 "2017-09-25T17:06:58Z")

</div>

We have multiple deployments of 3-node Aerospike clusters. In one particular instance, the resync at midnight UTC is taking place at 6pm local time, during heavy load, and causing the cluster to splinter. This, in turn, causes high CPU load as the cluster continues trying to resync, impacting application performance for a time.

Is there a way to reschedule this sync so it runs at say, 6am UTC instead of midnight? Perusing the documentation, I’ve found no such configuration options or way to internally list or adjust built-in database tasks.

Thanks!

---

<div class="post-metadata">

### Author: ![kporter](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.aerospike.com/kporter/32/515_2.png) [@kporter](https://discuss.aerospike.com/u/kporter)
#### Post date: [September 25, 2017, 5:23pm UTC](https://discuss.aerospike.com/t/reschedule-automatic-midnight-cluster-sync/4650/2 "2017-09-25T17:23:38Z")

</div>

> [@muriani](#):
>
> Is there a way to reschedule this sync so it runs at say, 6am UTC instead of midnight?

Aerospike doesn’t have a scheduled resync task at all.

Could you provide more information? Such as aerospike version, and what type of environment it is running in?

---

<div class="post-metadata">

### Author: ![muriani](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.aerospike.com/muriani/32/904_2.png) [@muriani](https://discuss.aerospike.com/u/muriani)
#### Post date: [September 25, 2017, 5:37pm UTC](https://discuss.aerospike.com/t/reschedule-automatic-midnight-cluster-sync/4650/3 "2017-09-25T17:37:36Z")

</div>

3.6.3 is the version included with this particular software stack, running on CentOS 6.5. 4GB RAM, 2GB currently assigned to Aerospike. Hm, we were informed that at midnight UTC, it will check and resync the cluster, causing a brief spike in CPU load.

Rebooting the principal server helped for a couple of days as described [here](https://discuss.aerospike.com/t/aerospike-replica-err-and-asadm-strange-output-on-cluster-status/4172), but after that the cluster splintered and couldn’t recover for nearly three hours due to suddenly high CPU load as seen when resyncing.

---

<div class="post-metadata">

### Author: ![muriani](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.aerospike.com/muriani/32/904_2.png) [@muriani](https://discuss.aerospike.com/u/muriani)
#### Post date: [September 25, 2017, 5:44pm UTC](https://discuss.aerospike.com/t/reschedule-automatic-midnight-cluster-sync/4650/4 "2017-09-25T17:44:07Z")

</div>

One of the details is that this CPU load spike occurs at 00:01:57 UTC, followed immediately by the cluster exploding, which is why it seemed to be a scheduled task within Aerospike.

---

<div class="post-metadata">

### Author: ![kporter](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.aerospike.com/kporter/32/515_2.png) [@kporter](https://discuss.aerospike.com/u/kporter)
#### Post date: [September 26, 2017, 10:48pm UTC](https://discuss.aerospike.com/t/reschedule-automatic-midnight-cluster-sync/4650/5 "2017-09-26T22:48:00Z")

</div>

1. Could you share your `aerospike.conf`?

2. Could you also provide the log lines containing “nsup-start” or “nsup-done”.

There isn’t any task scheduled at midnight UTC but that time may happen coincide with an nsup start (though this isn’t supposed to cause a rebalance). Rebalances occur when there has been a network disruption, these include adding/removing a node as well as one or more nodes becoming unavailable for a heartbeat timeout period.

BTW, the latency during rebalance was significantly improved with [Aerospike 3.11.1](http://www.aerospike.com/download/server/notes.html#3.11.1.1) and the clustering algorithms became more robust with [Aerospike 3.13.0.1](http://www.aerospike.com/download/server/notes.html#3.13.0.1) after switching to `paxos-protocol v5`.
