gc: randomie the next checkpoint time also after a manual box.snapsho…

…t().

Before this patch, snapshot interval was set randomly within
checkpoint_interval period. However, after box.snapshot(), the next
snapshot was scheduled exactly checkpoint_interval from the current time.
Many orchestration scripts snapshot entire cluster right after deployment,
to take a backup. This kills randomness, since all instances begin to
count the next checkpoint time from the current time.

Randomize the next checkpoint time after a manual snapshot as well.

Fixes gh-4432

(cherry picked from commit 6277f48)

src/box/gc.c

@@ -404,11 +404,18 @@ gc_checkpoint(void)
 	}
 
 	/*
-	 * Reset the schedule and wake up the checkpoint daemon
-	 * so that it can readjust.
+	 * Since a user invoked a snapshot manually, this may be
+	 * because he may be not happy with the current randomized
+	 * schedule. Randomize the schedule again and wake up the
+	 * checkpoint daemon so that it * can readjust.
+	 * It is also a good idea to randomize the interval, since
+	 * otherwise many instances running on the same host will
+	 * no longer run their checkpoints randomly after
+	 * a sweeping box.snapshot() (gh-4432).
 	 */
-	checkpoint_schedule_reset(&gc.checkpoint_schedule,
-				  ev_monotonic_now(loop()));
+	checkpoint_schedule_cfg(&gc.checkpoint_schedule,
+				ev_monotonic_now(loop()),
+				gc.checkpoint_schedule.interval);
 	fiber_wakeup(gc.checkpoint_fiber);
 
 	if (gc_do_checkpoint() != 0)

src/box/gc.h

@@ -240,7 +240,9 @@ void
 gc_add_checkpoint(const struct vclock *vclock);
 
 /**
- * Make a checkpoint.
+ * Make a *manual* checkpoint.
+ * This is entry point for box.snapshot() and SIGUSR1 signal
+ * handler.
  *
  * This function runs engine/WAL callbacks to create a checkpoint
  * on disk, then tracks the new checkpoint in the garbage collector