As the hosting operator, help your customer plan a deliberate restart of their running database using the service’s power controls. A reboot interrupts connections and does not replace application diagnosis or repair deleted data.

Prepare the application interruption

Confirm the intended service and the current database state. Let dependent application operators prepare for reconnecting, and choose a suitable window. If a snapshot or another change is running, inspect that operation before adding more requests.

Customer steps: request a reboot once

1. Open the database service’s Overview controls.
2. Choose Reboot.
3. Read the connection-interruption confirmation and submit once.
4. Follow the request under Activity.
5. Wait for the actual database status to return to an available state.
6. Verify the application reconnects using its current settings.

The request can be queued before the provider starts it. An accepted request can precede the actual provider restart; verify the resulting database and application state.

Check uncertain results

If the request fails or times out, compare the original Activity result with the current database state before clicking Reboot again. A provider can accept work even when a later page update fails.

Use Start or Stop for those separate intentions, rather than rebooting a database that is intentionally stopped. A billing-suspended service may refuse customer mutations even when a control would otherwise be supported.

See the PD AWS MySQL Blesta guide for related tasks, or explore PD AWS MySQL.