Start and Stop Databases

In the SynxDB database management system, the database server instances (including the Coordinator and all Segments) are started, stopped, and run on all system hosts, so that the instances can work together to form a unified database management system.

Because a SynxDB system is distributed across multiple machines, the process for starting and stopping the system is different from that of a regular PostgreSQL database system.

The command-line utilities gpstart and gpstop are used to start and stop SynxDB, respectively. They are located in the $GPHOME/bin directory on the coordinator host.

Tip

Do not use the kill command to terminate Postgres processes, as using kill -9 or kill -11 can corrupt the database and hinder failure analysis. To terminate a Postgres process, use the database function pg_cancel_backend().

Start SynxDB

To start an initialized SynxDB, execute gpstart on the coordinator instance.

If the database system has been initialized with gpinitsystem and stopped with gpstop, you can restart it with gpstart. gpstart starts all the postgres instances in the SynxDB cluster, thus completing the startup of the entire database. During startup, gpstart coordinates and executes all necessary steps in parallel.

Execute gpstart on the coordinator host to start SynxDB:

$ gpstart

Restart SynxDB

To restart SynxDB, execute the gpstop command with the -r option on the coordinator host:

$ gpstop -r

Reload configuration file changes

You can reload changes to the SynxDB configuration files without interrupting the system.

gpstop supports reloading the pg_hba.conf configuration file and runtime parameters in postgresql.conf without service interruption. Active sessions will apply the changes in the configuration files when clients reconnect to the database. However, many server configuration parameters only take effect after a full system restart (gpstop -r).

Use gpstop -u to reload configuration file changes without shutting down the SynxDB system:

$ gpstop -u

Start the coordinator in maintenance mode

If you need to perform maintenance or administrative tasks without affecting the data on the segments, you can start only the coordinator. For example, in maintenance mode, you can connect only to the coordinator instance of the database and edit system catalog settings.

Use the -m option in gpstart to enter maintenance mode:
```
$ gpstart -m
```
Connect to the coordinator in maintenance mode for catalog maintenance. For example:
```
$ PGOPTIONS='-c gp_role=utility' psql postgres
```
After completing the maintenance tasks, stop the coordinator in maintenance mode. Then, restart it in production mode.
```
$ gpstop -m
$ gpstart
```

Warning

It is recommended that this operation be performed by technical support.

Stop SynxDB

gpstop stops or restarts the SynxDB system on the coordinator host. When executed, gpstop stops all postgres processes in the system, including the coordinator and all segment instances. By default, gpstop uses multiple parallel worker threads to shut down the Postgres instances that make up the SynxDB cluster. To stop SynxDB immediately, use fast mode.

Tip

This mode stops all database processes without allowing the database server to complete transactions or clean up any temporary or in-process work files.

Stop SynxDB:
```
$ gpstop
```
Stop SynxDB in fast mode:
```
$ gpstop -M fast
```

By default, shutting down SynxDB is not allowed if there are client connections to the database. Use the -M fast option to roll back all in-progress transactions and terminate any connections before shutting down.

Stop client processes

SynxDB starts a new backend process for each client connection. A SynxDB user with SUPERUSER privileges can cancel and terminate these client backend processes.

Canceling a backend process with the pg_cancel_backend() function ends a client query that is queued or in progress. Terminating a backend process with the pg_terminate_backend() function terminates the client connection to the database.

The pg_cancel_backend() function has two signatures:

pg_cancel_backend( pid int4 )
pg_cancel_backend( pid int4, msg text )

The pg_terminate_backend() function has two similar signatures:

pg_terminate_backend( pid int4 )
pg_terminate_backend( pid int4, msg text )

If you provide a msg, SynxDB includes the msg text in the cancellation message returned to the client. The msg is limited to 128 bytes, and SynxDB will truncate anything longer.

The pg_cancel_backend() and pg_terminate_backend() functions return true if successful, and false otherwise.

To cancel or terminate a backend process, you must first obtain its process ID. You can get the process ID from the pid column of the pg_stat_activity view. For example, to view the process information for all executing and queued queries:

SELECT usename, pid, state, query, datname
     FROM pg_stat_activity;

Example of partial query output:

usename |  pid     | state  |         query          | datname
-----------+-------------------+--------+------------------------+---------
  sammy  |   31861  | idle   | SELECT * FROM testtbl; | testdb
  billy  |   31905  | active | SELECT * FROM topten;  | testdb

You can identify the process ID (pid) of a query or client connection from the query output.

After identifying the process ID for a query, you can cancel the waiting query. For example, to cancel the waiting query identified in the example output above and include Admin canceled long-running query. as the message returned to the client:

=# SELECT pg_cancel_backend(31905 ,'Admin canceled long-running query.');

ERROR:  canceling statement due to user request: "Admin canceled lon