https://github.com/pgedge/cli
pgEdge Command Line Interface
https://github.com/pgedge/cli
Last synced: 10 months ago
JSON representation
pgEdge Command Line Interface
- Host: GitHub
- URL: https://github.com/pgedge/cli
- Owner: pgEdge
- License: other
- Created: 2022-12-23T00:00:24.000Z (over 3 years ago)
- Default Branch: main
- Last Pushed: 2025-08-19T10:37:18.000Z (11 months ago)
- Last Synced: 2025-08-19T12:35:24.134Z (11 months ago)
- Language: Python
- Homepage: https://pgedge.com
- Size: 97.8 MB
- Stars: 29
- Watchers: 12
- Forks: 17
- Open Issues: 7
-
Metadata Files:
- Readme: README.md
- Changelog: CHANGELOG.md
- License: LICENSE.md
Awesome Lists containing this project
README
# pgEdge Command Line Interface (CLI)
The pgEdge Command Line Interface (CLI) for managing pgEdge Platform components.
[Release notes](https://docs.pgedge.com/platform/pgedge_rel_notes) and further documentation are available on [docs.pgedge.com](https://docs.pgedge.com)
## Table of Contents
- [Creating a Development Environment](README.md#creating-a-development-environment)
- [CLI Functions](docs/cli_functions.md)
### Prerequisites
On each machine that will host a replication node, you must:
* Open any firewalls that could obstruct access between your servers.
* Set SELinux to `permissive` or `disabled` mode on each host, followed by a system reboot.
* Configure [passwordless sudo access](#configuring-passwordless-sudo) for a non-root OS user on each host.
* Configure [passwordless ssh](#configuring-passwordless-ssh) access for the same non-root OS user on each host.
### Creating a Development Environment
After meeting the prerequisites:
1.) Clone this repository.
2.) Move into the setup directory: `cd cli/devel/setup`
3.) Run the setup scripts: `./10-toolset.sh` through `30-bashrc.sh`
4.) Source the `~/.bashrc` file.
5.) Run `40-awscli.sh` to install AWS in a virtual environment.
6.) Configure your `~/.aws/config` credentials.
7.) Run `50-pull-IN.sh` to retrieve the REPO files.
A [Docker Compose](devel/setup/compose/README.md) setup is also available for development and testing.
### Using the CLI
When using the CLI, you should ensure that you:
**Include a Primary Key in Each Table**
All tables must include a primary key; this allows pgEdge to replicate `INSERT`, `UPDATE`, and `DELETE` statements. If your table does not include a primary key, only `INSERT` statements will be replicated to the table.
**Use Snowflake Sequences instead of PostgreSQL sequences**
If you use a PostgreSQL sequence as part of your primary key, you should convert your sequences to [Snowflake sequences](https://github.com/pgEdge/snowflake). Snowflake sequences are composed of multiple data types that ensure a unique transaction sequence when processing your data in multiple regions. This helps accurately preserve the order in which globally distributed transactions are performed, and alleviates concerns that network lag could disrupt sequences in distributed transactions.
**Include the ENABLE ALWAYS clause in Triggers**
PostgreSQL triggers will fire only from the node on which they were invoked. If you have triggers that are related to the replication process, you should include the `ENABLE ALWAYS` clause when attaching a trigger to a table:
```
CREATE TRIGGER ins_trig AFTER INSERT ON my_table FOR EACH ROW EXECUTE PROCEDURE ins_history();
ALTER TABLE trans_history ENABLE ALWAYS TRIGGER ins_trig;
```
#### Configuring Passwordless SSH
You can use the following steps to configure passwordless SSH on each node of the replication cluster:
```sh
ssh-keygen -t rsa
cd ~/.ssh
cat id_rsa.pub >> authorized_keys
chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys
```
#### Configuring Passwordless sudo
To configure passwordless sudo, open the /etc/sudoers file, and add a line of the form:
%username ALL = (ALL) NOPASSWD: ALL
Where `username` specifies the name of your operating system user.