OmniDB es una herramienta de gestión de bases de datos gráficas de código abierto desarrollada por 2ndQuadrant, líder mundial en tecnologías y servicios de PostgreSQL. OmniDB es una herramienta de cliente universal basada en navegador que puede administrar los principales motores de bases de datos como PostgreSQL, MariaDB, MySQL y Oracle. Otros motores que pronto serán compatibles incluyen SQLite, Firebird, MS SQL Server e IBM DB2.
Al igual que cualquier excelente software de cliente de base de datos, OmniDB también brinda a los usuarios algunas funciones excelentes. Estos incluyen la capacidad de crear y personalizar tableros de monitoreo del rendimiento de la base de datos. En esta serie de artículos de dos partes, aprenderemos cómo usar las unidades de monitoreo integradas de OmniDB, comúnmente conocidas como "widgets" en términos de tablero, para crear tableros de control de estado del rendimiento para un clúster de replicación de PostgreSQL 12.
El entorno de prueba
Nuestro entorno de prueba es un clúster PostgreSQL 12 de dos nodos, que se ejecuta en una VPC de AWS en la región us-east-1. La VPC abarca tres zonas de disponibilidad y tiene tres subredes. Cada subred está en una zona de disponibilidad (AZ) separada. El nodo principal y el de reserva están ubicados en dos de estas subredes. Ambos nodos son del tipo de instancia t2.large EC2 y ejecutarán PostgreSQL 12 de código abierto. El nodo principal se replicará en el nodo en espera.
También habrá un "nodo de monitoreo" que ejecutará la última versión de la herramienta de administración de base de datos OmniDB de 2ndQuadrant. Este nodo no formará parte del clúster de PostgreSQL, sino que se alojará en la tercera subred de la VPC, en otra AZ. OmniDB podrá conectarse tanto al maestro como al nodo en espera y comprobar su rendimiento. El nodo OmniDB será una instancia EC2 t2.medium.
Los tres nodos ejecutarán Red Hat Enterprise Linux (RHEL) 8. La siguiente imagen muestra la arquitectura simplificada:
El escenario de prueba
Una vez que tengamos configurado el clúster y OmniDB, registraremos ambos nodos de PostgreSQL en OmniDB. Luego nos familiarizaremos con algunas de las unidades de monitoreo estándar en OmniDB y veremos las métricas de rendimiento de ambos nodos del clúster. Luego ejecutaremos una prueba de carga en el nodo principal usando pgbench. Idealmente, la prueba de carga debe iniciarse desde una máquina separada, pero en este caso, la ejecutaremos localmente. Luego veremos cómo el panel de monitoreo de OmniDB muestra los cambios en varios contadores de rendimiento a medida que cambia la carga.
Configuración del entorno
Paso 1:Instalación de un clúster de replicación de PostgreSQL 12
Para crear un clúster de PostgreSQL de dos nodos, estamos siguiendo los pasos descritos en un blog de 2ndQuadrant publicado anteriormente. El lector puede consultar este artículo para ver cómo instalamos un clúster de tres nodos con un nodo testigo utilizando otro producto de 2ndQuadrant llamado repmgr . Para nuestra configuración actual, estamos siguiendo los mismos pasos usando repmgr para crear un clúster de dos nodos en lugar de uno de tres nodos. Además, el clúster de replicación no tendrá ningún nodo testigo. Para simplificar las cosas, este artículo no muestra los pasos detallados de instalación y configuración.
Una vez que nuestro clúster esté configurado, podemos confirmar que está funcionando consultando la vista pg_stat_replication desde el nodo principal:
SELECT usename, client_addr, application_name, state, sent_lsn, write_lsn,replay_lsn FROM pg_stat_replication;
Paso 2:Instalación y configuración de un servidor OmniDB
Se accede a OmniDB mediante una URL, lo que significa que, en segundo plano, ejecuta un servidor web propio. Hay dos versiones de OmniDB:
- Aplicación OmniDB :normalmente se ejecuta desde una estación de trabajo y se comporta como una aplicación de escritorio normal. OmniDB ejecuta el servidor web en un puerto aleatorio y no es necesaria ninguna configuración adicional.
- Servidor OmniDB :Esto es para instalar OmniDB en un servidor de red para un modo multiusuario. En el modo de servidor, podemos especificar el número de puerto para acceder a la URL, el cifrado SSL de la URL, el equilibrio de carga y el proxy inverso, el acceso de paso SSH a los nodos de la base de datos y la creación de cuentas de usuario para el acceso.
Para nuestro escenario de prueba, instalaremos un servidor OmniDB en el nodo OmniDB EC2. Primero, estamos descargando el paquete más reciente del sitio de OmniDB:
# wget https://www.omnidb.org/dist/2.17.0/omnidb-server_2.17.0-centos7-amd64.rpm
A continuación, comenzamos la instalación. Aquí, estamos instalando OmniDB como usuario raíz, pero puede usar cualquier otro usuario siempre que tenga los derechos correctos:
# rpm -ivh omnidb-server_2.17.0-centos7-amd64.rpm Verifying... ################################# [100%] Preparing... ################################# [100%] Updating / installing... 1:omnidb-server-2.17.0-0 ################################# [100%]
Una vez que el paquete está instalado, podemos iniciar OmniDB desde el símbolo del sistema:
# omnidb-server
Esto muestra el inicio del servidor:
Starting OmniDB websocket... Checking port availability... Starting websocket server at port 25482. Starting OmniDB server... Checking port availability... Starting server OmniDB 2.17.0 at 127.0.0.1:8000. Starting migration of user database from version 0.0.0 to version 2.17.0... OmniDB successfully migrated user database from version 0.0.0 to version 2.17.0 Open OmniDB in your favorite browser Press Ctrl+C to exit
Podemos ver que OmniDB ha elegido un puerto de servidor web predeterminado de 8000 y un servidor websocket predeterminado en el puerto 25482.
Presionamos Ctrl+C para detener el proceso del servidor y navegar hasta el directorio de inicio del usuario raíz. Podemos ver que hay una carpeta oculta llamada .omnidb . Debajo de esta carpeta, hay un subdirectorio llamado omnidb-server . Dentro del subdirectorio omnidb-server, hay algunos archivos:
# ls -la ~ … drwxr-xr-x. 3 root root 27 Jun 13 02:49 .omnidb … … # ls -la ~/.omnidb … drwxr-xr-x. 2 root root 106 Jun 13 02:49 omnidb-server # ls -la ~/.omnidb/omnidb-server/ … -rw-r--r--. 1 root root 131072 Jun 13 02:49 db.sqlite3 -rw-r--r--. 1 root root 1209 Jun 13 02:49 omnidb.conf -rw-r--r--. 1 root root 116736 Jun 13 02:49 omnidb.db -rw-r--r--. 1 root root 0 Jun 13 02:49 omnidb.db.bak_2.17.0 -rw-r--r--. 1 root root 579 Jun 13 02:49 omnidb.log
Una vez que se inicia el proceso del servidor, OmniDB inicializa estos archivos. La base de datos de metadatos OmniDB se llama omnidb.db . Esta es una base de datos SQLite y contiene información sobre las conexiones de la base de datos, los usuarios de OmniDB, etc. El omnidb.conf El archivo contiene opciones de configuración para el servidor OmniDB. Si abrimos este archivo en un editor, se verá así:
# OmniDB Server configuration file [webserver] # What address the webserver listens to, 0.0.0.0 listens to all addresses bound to the machine listening_address = 127.0.0.1 # Webserver port, if port is in use another random port will be selected listening_port = 8000 # Websocket port, if port is in use another random port will be selected websocket_port = 25482 # External Websocket port, use this parameter if OmniDB isn't directly visible by the client # external_websocket_port = 25482 # Security parameters # is_ssl = True requires ssl_certificate_file and ssl_key_file parameters # This is highly recommended to protect information is_ssl = False ssl_certificate_file = /path/to/cert_file ssl_key_file = /path/to/key_file # Trusted origins, use this parameter if OmniDB is configured with SSL and is being accessed by another domain csrf_trusted_origins = origin1,origin2,origin3 # Url path to access OmniDB, default is empty path = [queryserver] # Max number of threads that can used by each advanced object search request thread_pool_max_workers = 2 # Number of seconds between each prompt password request. Default: 30 minutes pwd_timeout_total = 1800
OmniDB ejecuta dos procesos de servidor. Uno es un servidor web que muestra la interfaz de usuario, el otro es el servidor websocket. Varias funciones de la aplicación utilizan el servidor websocket, como consulta, consola y depuración.
Desde el archivo de configuración, podemos ver que, de manera predeterminada, el servidor OmniDB acepta tráfico local (127.0.0.1) en el puerto del servidor web 8000. Cambiaremos esto a TODAS las direcciones IP. A menos que la máquina esté detrás de un proxy inverso, se recomienda encarecidamente utilizar el cifrado SSL para las conexiones HTTP al servidor. Sin embargo, en nuestro ejemplo, dejaremos el is_ssl parámetro a "Falso" porque desarmaremos esta máquina una vez que terminemos nuestras pruebas. También cambiaremos el puerto del servidor web a 8080 y mantendremos el puerto del servidor websocket en su valor predeterminado de 25482.
Una vez realizados los cambios, el archivo de configuración debería verse así:
[webserver] listening_address = 0.0.0.0 listening_port = 8080 websocket_port = 25482 is_ssl = False ssl_certificate_file = /path/to/cert_file ssl_key_file = /path/to/key_file csrf_trusted_origins = origin1,origin2,origin3 path = [queryserver] thread_pool_max_workers = 2 pwd_timeout_total = 1800
Con los cambios realizados y guardados, ejecutamos otra aplicación llamada omnidb-config-server . Esta herramienta se puede utilizar para realizar alguna configuración extra como:
- Vacío de la base de datos SQLite Base de datos OmniDB
- Restablezca la base de datos anterior y cree una nueva
- Eliminar archivos temporales
- Cree un nuevo directorio de inicio para la base de datos y el archivo de configuración
- Cree un superusuario para iniciar sesión en OmniDB
Aunque iniciaremos sesión en OmniDB con la cuenta de usuario administrador que se crea de forma predeterminada, crearemos otro superusuario aquí. Esto puede ser útil si queremos crear cuentas de DBA individuales en OmniDB. El siguiente fragmento muestra esto:
# omnidb-config-server --createsuperuser=dba [email protected]$$w0rd123 Creating superuser... Superuser created.
Con el superusuario creado, comenzamos de nuevo el proceso omnidb-server:
# omnidb-server Starting OmniDB websocket... Checking port availability... Starting websocket server at port 25482. Starting OmniDB server... Checking port availability... Starting server OmniDB 2.17.0 at 0.0.0.0:8080. User database version 2.17.0 is already matching server version. Open OmniDB in your favorite browser Press Ctrl+C to exit
Antes de acceder a la interfaz OmniDB, también agregamos el puerto 8080 y el puerto 25482 al grupo de seguridad de la instancia EC2:
Paso 3:Acceso a la interfaz de OmniDB
Navegar a la dirección pública y al nodo OmniDB ahora muestra la pantalla de inicio de sesión:
Especificamos el nombre de usuario predeterminado de "admin" y su contraseña, "admin". Esto nos permite iniciar sesión en la interfaz principal de OmniDB. La primera pantalla se muestra a continuación:
A continuación, hacemos clic en el icono “Administrar usuarios” en la esquina superior derecha de la pantalla:
Y cambie la contraseña predeterminada del usuario administrador:
Una vez hecho esto, hacemos clic en el botón “Guardar datos” para actualizar la contraseña. Como puede ver, también podemos crear nuevos usuarios desde esta pantalla.
Desde la esquina superior izquierda de la pantalla, hacemos clic en el enlace "Conexiones", y luego desde el cuadro de diálogo resultante, hacemos clic en el botón "Nueva conexión":
Luego especificamos los detalles de conexión para el nodo principal de PostgreSQL y hacemos clic en el botón "Guardar datos":
Una vez guardada la conexión, hacemos clic en el icono de conexión (marca de verificación verde) de la columna "Acciones".
Esto abre una nueva pestaña que muestra la conexión de la base de datos. Como se muestra aquí, estamos conectados al nodo principal de PostgreSQL aquí:
Seguimos el mismo proceso para registrar el nodo standby:
Paso 4:Restaurar una base de datos de muestra
Ahora estamos restaurando una base de datos de muestra en la instancia principal de PostgreSQL. Esta base de datos se llama "DVDRental" y se puede descargar gratuitamente desde el sitio Tutorial de PostgreSQL. Descomprimimos el archivo descargado y extrajimos los archivos de origen en un subdirectorio en la carpeta /tmp del nodo principal:
[[email protected] dvdrental] # ls -la total 2796 drwxr-xr-x. 2 root root 280 Jun 16 11:32 . drwxrwxrwt. 9 root root 257 Jun 16 11:31 .. -rw-------. 1 postgres postgres 57147 May 12 2019 3055.dat -rw-------. 1 postgres postgres 8004 May 12 2019 3057.dat -rw-------. 1 postgres postgres 483 May 12 2019 3059.dat -rw-------. 1 postgres postgres 333094 May 12 2019 3061.dat -rw-------. 1 postgres postgres 149469 May 12 2019 3062.dat -rw-------. 1 postgres postgres 26321 May 12 2019 3063.dat -rw-------. 1 postgres postgres 46786 May 12 2019 3065.dat -rw-------. 1 postgres postgres 21762 May 12 2019 3067.dat -rw-------. 1 postgres postgres 3596 May 12 2019 3069.dat -rw-------. 1 postgres postgres 140422 May 12 2019 3071.dat -rw-------. 1 postgres postgres 263 May 12 2019 3073.dat -rw-------. 1 postgres postgres 718644 May 12 2019 3075.dat -rw-------. 1 postgres postgres 1214420 May 12 2019 3077.dat -rw-------. 1 postgres postgres 271 May 12 2019 3079.dat -rw-------. 1 postgres postgres 57 May 12 2019 3081.dat -rw-------. 1 postgres postgres 45872 May 12 2019 restore.sql -rw-------. 1 postgres postgres 55111 May 12 2019 toc.dat
A continuación, ejecutamos los siguientes comandos de shell en la instancia principal de PostgreSQL (PG-Node1). Estos comandos realizan algunos cambios en el archivo restore.sql:
- Elimine todas las apariciones de “$$PATH$$/”. Esto asegura que el script pueda encontrar todos los archivos de datos en el mismo directorio
- Cambie todas las apariciones de "English_United States.1252" a "en_US.UTF-8". Esto garantiza que no haya errores debido a que falta una configuración regional cuando se ejecuta el script.
- Cambie el comando "DROP DATBASE dvdrental" a "DROP DATBASE IF EXISTS dvdrental", para que no aparezca ningún error de base de datos no válida.
# sed -i 's/$$PATH$$\//\/tmp\/dvdrental\//g' /tmp/dvdrental/restore.sql # sed -i 's/English_United States.1252/en_US.UTF-8/g' /tmp/dvdrental/restore.sql # sed -i 's/DROP DATABASE dvdrental;/DROP DATABASE IF EXISTS dvdrental;/g' /tmp/dvdrental/restore.sql
A continuación, cambiamos al usuario de postgres y ejecutamos el siguiente comando desde el indicador de shell:
$ psql -U postgres -d postgres -f /tmp/dvdrental/restore.sql
Esto restaura la base de datos de ejemplo en el nodo principal. Si revisamos desde OmniDB, podemos ver que la base de datos está creada:
Conclusión
Ahora tenemos un clúster de PostgreSQL en pleno funcionamiento y una instancia de OmniDB que se ejecuta en AWS. OmniDB puede conectarse a ambos nodos del clúster. También hemos restaurado una base de datos en el nodo principal que se está replicando en el nodo de reserva.
La configuración del entorno ya está completa. En la segunda parte de este artículo, comenzaremos a crear un panel de control de rendimiento para la instancia principal.
