Как бихте искали да обедините "топ" процес за всичките си 5 възела на базата данни и да сортирате по използване на процесора само с едноредова команда? Да, правилно прочетохте! Какво ще кажете за показване на интерактивни графики в интерфейса на терминала? Въведохме CLI клиента за ClusterControl, наречен s9s преди около година, и той беше чудесно допълнение към уеб интерфейса. Освен това е с отворен код...
В тази публикация в блога ще ви покажем как можете да наблюдавате базите си с помощта на терминала и s9s CLI.
Въведение в s9s, ClusterControl CLI
ClusterControl CLI (или s9s или s9s CLI) е проект с отворен код и незадължителен пакет, въведен с ClusterControl версия 1.4.1. Това е инструмент на командния ред за взаимодействие, контрол и управление на вашата инфраструктура на базата данни с помощта на ClusterControl. Проектът на командния ред s9s е с отворен код и може да бъде намерен в GitHub.
Започвайки от версия 1.4.1, скриптът за инсталиране автоматично ще инсталира пакета (s9s-tools) на възела ClusterControl.
Някои предпоставки. За да можете да стартирате s9s-tools CLI, следното трябва да е вярно:
- Изпълняващ се ClusterControl контролер (cmon).
- s9s клиент, инсталирайте като отделен пакет.
- Порт 9501 трябва да бъде достъпен от клиента s9s.
Инсталирането на s9s CLI е лесно, ако го инсталирате на самия хост на ClusterControl Controller:$ rm
$ rm -Rf ~/.s9s
$ wget http://repo.severalnines.com/s9s-tools/install-s9s-tools.sh
$ ./install-s9s-tools.shМожете да инсталирате s9s-tools извън сървъра на ClusterControl (лаптоп на вашата работна станция или хост на бастион), стига интерфейсът на ClusterControl Controller RPC (TLS) да е изложен на публичната мрежа (по подразбиране 127.0.0.1:9501). Можете да намерите повече подробности за това как да конфигурирате това в страницата с документация.
За да проверите дали можете да се свържете правилно с интерфейса на ClusterControl RPC, трябва да получите отговора OK, когато изпълнявате следната команда:
$ s9s cluster --ping
PING OK 2.000 msКато странична забележка, разгледайте и ограниченията, когато използвате този инструмент.
Примерно внедряване
Нашето примерно разгръщане се състои от 8 възела в 3 клъстера:
- Поточно репликация на PostgreSQL – 1 главен, 2 подчинени
- Репликация на MySQL – 1 главен, 1 подчинен
- Набор реплики на MongoDB – 1 първичен, 2 вторични възела
Всички клъстери на базата данни бяха разгърнати от ClusterControl с помощта на съветника за внедряване на "Deploy Database Cluster" и от гледна точка на потребителския интерфейс, това ще видим в таблото за управление на клъстера:
Наблюдение на клъстерите
Ще започнем с изброяване на клъстерите:
$ s9s cluster --list --long
ID STATE TYPE OWNER GROUP NAME COMMENT
23 STARTED postgresql_single system admins PostgreSQL 10 All nodes are operational.
24 STARTED replication system admins Oracle 5.7 Replication All nodes are operational.
25 STARTED mongodb system admins MongoDB 3.6 All nodes are operational.Виждаме същите клъстери като потребителския интерфейс. Можем да получим повече подробности за конкретния клъстер, като използваме флага --stat. Множество клъстери и възли също могат да бъдат наблюдавани по този начин, опциите на командния ред могат дори да използват заместващи знаци в имената на възлите и клъстерите:
$ s9s cluster --stat *Replication
Oracle 5.7 Replication Name: Oracle 5.7 Replication Owner: system/admins
ID: 24 State: STARTED
Type: REPLICATION Vendor: oracle 5.7
Status: All nodes are operational.
Alarms: 0 crit 1 warn
Jobs: 0 abort 0 defnd 0 dequd 0 faild 7 finsd 0 runng
Config: '/etc/cmon.d/cmon_24.cnf'
LogFile: '/var/log/cmon_24.log'
HOSTNAME CPU MEMORY SWAP DISK NICs
10.0.0.104 1 6% 992M 120M 0B 0B 19G 13G 10K/s 54K/s
10.0.0.168 1 6% 992M 116M 0B 0B 19G 13G 11K/s 66K/s
10.0.0.156 2 39% 3.6G 2.4G 0B 0B 19G 3.3G 338K/s 79K/sРезултатът по-горе дава обобщение на нашата MySQL репликация заедно със състоянието на клъстера, състоянието, доставчика, конфигурационния файл и така нататък. Надолу можете да видите списъка с възли, които попадат под този идентификатор на клъстер с обобщен изглед на системните ресурси за всеки хост като брой процесори, обща памет, използване на паметта, суап диск и мрежови интерфейси. Цялата показана информация се извлича от базата данни CMON, а не директно от действителните възли.
Можете също така да получите обобщен изглед на всички бази данни във всички клъстери:
$ s9s cluster --list-databases --long
SIZE #TBL #ROWS OWNER GROUP CLUSTER DATABASE
7,340,032 0 0 system admins PostgreSQL 10 postgres
7,340,032 0 0 system admins PostgreSQL 10 template1
7,340,032 0 0 system admins PostgreSQL 10 template0
765,460,480 24 2,399,611 system admins PostgreSQL 10 sbtest
0 101 - system admins Oracle 5.7 Replication sys
Total: 5 databases, 789,577,728, 125 tables.Последният ред обобщава, че имаме общо 5 бази данни със 125 таблици, 4 от които са в нашия PostgreSQL клъстер.
За пълен пример за използване на опциите на командния ред s9s cluster, вижте документацията на s9s cluster.
Наблюдение на възли
За наблюдение на възли, s9s CLI има подобни функции с опцията за клъстер. За да получите обобщен изглед на всички възли, можете просто да направите:
$ s9s node --list --long
STAT VERSION CID CLUSTER HOST PORT COMMENT
coC- 1.6.2.2662 23 PostgreSQL 10 10.0.0.156 9500 Up and running
poM- 10.4 23 PostgreSQL 10 10.0.0.44 5432 Up and running
poS- 10.4 23 PostgreSQL 10 10.0.0.58 5432 Up and running
poS- 10.4 23 PostgreSQL 10 10.0.0.60 5432 Up and running
soS- 5.7.23-log 24 Oracle 5.7 Replication 10.0.0.104 3306 Up and running.
coC- 1.6.2.2662 24 Oracle 5.7 Replication 10.0.0.156 9500 Up and running
soM- 5.7.23-log 24 Oracle 5.7 Replication 10.0.0.168 3306 Up and running.
mo-- 3.2.20 25 MongoDB 3.6 10.0.0.125 27017 Up and Running
mo-- 3.2.20 25 MongoDB 3.6 10.0.0.131 27017 Up and Running
coC- 1.6.2.2662 25 MongoDB 3.6 10.0.0.156 9500 Up and running
mo-- 3.2.20 25 MongoDB 3.6 10.0.0.35 27017 Up and Running
Total: 11Най-лявата колона определя типа на възела. За това разгръщане "c" представлява ClusterControl Controller, "p" за PostgreSQL, "m" за MongoDB, "e" за Memcached и s за общи възли на MySQL. Следващият е състоянието на хоста - "o" за онлайн, " l" за off-line, "f" за неуспешни възли и т.н. Следващата е ролята на възела в клъстера. Може да бъде M за master, S за slave, C за контролер и - за всичко останало. Останалите колони са доста разбираеми.
Можете да получите целия списък, като погледнете man страницата на този компонент:
$ man s9s-nodeОттам можем да преминем към по-подробна статистика за всички възли с флага --stats:
$ s9s node --stat --cluster-id=24
10.0.0.104:3306
Name: 10.0.0.104 Cluster: Oracle 5.7 Replication (24)
IP: 10.0.0.104 Port: 3306
Alias: - Owner: system/admins
Class: CmonMySqlHost Type: mysql
Status: CmonHostOnline Role: slave
OS: centos 7.0.1406 core Access: read-only
VM ID: -
Version: 5.7.23-log
Message: Up and running.
LastSeen: Just now SSH: 0 fail(s)
Connect: y Maintenance: n Managed: n Recovery: n Skip DNS: y SuperReadOnly: n
Pid: 16592 Uptime: 01:44:38
Config: '/etc/my.cnf'
LogFile: '/var/log/mysql/mysqld.log'
PidFile: '/var/lib/mysql/mysql.pid'
DataDir: '/var/lib/mysql/'
10.0.0.168:3306
Name: 10.0.0.168 Cluster: Oracle 5.7 Replication (24)
IP: 10.0.0.168 Port: 3306
Alias: - Owner: system/admins
Class: CmonMySqlHost Type: mysql
Status: CmonHostOnline Role: master
OS: centos 7.0.1406 core Access: read-write
VM ID: -
Version: 5.7.23-log
Message: Up and running.
Slaves: 10.0.0.104:3306
LastSeen: Just now SSH: 0 fail(s)
Connect: n Maintenance: n Managed: n Recovery: n Skip DNS: y SuperReadOnly: n
Pid: 975 Uptime: 01:52:53
Config: '/etc/my.cnf'
LogFile: '/var/log/mysql/mysqld.log'
PidFile: '/var/lib/mysql/mysql.pid'
DataDir: '/var/lib/mysql/'
10.0.0.156:9500
Name: 10.0.0.156 Cluster: Oracle 5.7 Replication (24)
IP: 10.0.0.156 Port: 9500
Alias: - Owner: system/admins
Class: CmonHost Type: controller
Status: CmonHostOnline Role: controller
OS: centos 7.0.1406 core Access: read-write
VM ID: -
Version: 1.6.2.2662
Message: Up and running
LastSeen: 28 seconds ago SSH: 0 fail(s)
Connect: n Maintenance: n Managed: n Recovery: n Skip DNS: n SuperReadOnly: n
Pid: 12746 Uptime: 01:10:05
Config: ''
LogFile: '/var/log/cmon_24.log'
PidFile: ''
DataDir: ''Отпечатването на графики с клиента s9s също може да бъде много информативно. Това представя данните, събрани от контролера в различни графики. Има почти 30 графики, поддържани от този инструмент, както е изброено тук, и s9s-node ги изброява всички. По-долу е показана хистограма за натоварване на сървъра на всички възли за клъстер ID 1, събрана от CMON, направо от вашия терминал:
Възможно е да зададете начална и крайна дата и час. Можете да видите кратки периоди (като последния час) или по-дълги периоди (като седмица или месец). Следва пример за преглед на използването на диска за последния час:
С помощта на опцията --density може да се отпечата различен изглед за всяка графика. Тази графика на плътността показва не времевия ред, а колко често са били виждани дадените стойности (ос X представлява стойността на плътността):
Ако терминалът не поддържа Unicode символи, опцията --only-ascii може да ги изключи:
Графиките имат цветове, където опасно високите стойности например са показани в червено. Списъкът с възли може да се филтрира с опцията --nodes, където можете да посочите имената на възлите или да използвате заместващи знаци, ако е удобно.
Наблюдение на процеса
Друго страхотно нещо за s9s CLI е, че предоставя списък с процеси на целия клъстер - „отгоре“ за всички възли, всички процеси, обединени в един. Следната команда изпълнява командата "top" на всички възли на базата данни за идентификатор на клъстер 24, сортирана по най-голямо потребление на процесора и актуализирана непрекъснато:
$ s9s process --top --cluster-id=24
Oracle 5.7 Replication - 04:39:17 All nodes are operational.
3 hosts, 4 cores, 10.6 us, 4.2 sy, 84.6 id, 0.1 wa, 0.3 st,
GiB Mem : 5.5 total, 1.7 free, 2.6 used, 0.1 buffers, 1.1 cached
GiB Swap: 0 total, 0 used, 0 free,
PID USER HOST PR VIRT RES S %CPU %MEM COMMAND
12746 root 10.0.0.156 20 1359348 58976 S 25.25 1.56 cmon
1587 apache 10.0.0.156 20 462572 21632 S 1.38 0.57 httpd
390 root 10.0.0.156 20 4356 584 S 1.32 0.02 rngd
975 mysql 10.0.0.168 20 1144260 71936 S 1.11 7.08 mysqld
16592 mysql 10.0.0.104 20 1144808 75976 S 1.11 7.48 mysqld
22983 root 10.0.0.104 20 127368 5308 S 0.92 0.52 sshd
22548 root 10.0.0.168 20 127368 5304 S 0.83 0.52 sshd
1632 mysql 10.0.0.156 20 3578232 1803336 S 0.50 47.65 mysqld
470 proxysql 10.0.0.156 20 167956 35300 S 0.44 0.93 proxysql
338 root 10.0.0.104 20 4304 600 S 0.37 0.06 rngd
351 root 10.0.0.168 20 4304 600 R 0.28 0.06 rngd
24 root 10.0.0.156 20 0 0 S 0.19 0.00 rcu_sched
785 root 10.0.0.156 20 454112 11092 S 0.13 0.29 httpd
26 root 10.0.0.156 20 0 0 S 0.13 0.00 rcuos/1
25 root 10.0.0.156 20 0 0 S 0.13 0.00 rcuos/0
22498 root 10.0.0.168 20 127368 5200 S 0.09 0.51 sshd
14538 root 10.0.0.104 20 0 0 S 0.09 0.00 kworker/0:1
22933 root 10.0.0.104 20 127368 5200 S 0.09 0.51 sshd
28295 root 10.0.0.156 20 127452 5016 S 0.06 0.13 sshd
2238 root 10.0.0.156 20 197520 10444 S 0.06 0.28 vc-agent-007
419 root 10.0.0.156 20 34764 1660 S 0.06 0.04 systemd-logind
1 root 10.0.0.156 20 47628 3560 S 0.06 0.09 systemd
27992 proxysql 10.0.0.156 20 11688 872 S 0.00 0.02 proxysql_galera
28036 proxysql 10.0.0.156 20 11688 876 S 0.00 0.02 proxysql_galeraИма също флаг --list, който връща подобен резултат без непрекъсната актуализация (подобно на командата "ps"):
$ s9s process --list --cluster-id=25Наблюдение на работата
Задачите са задачи, изпълнявани от контролера във фонов режим, така че клиентското приложение не трябва да чака, докато цялата работа приключи. ClusterControl изпълнява задачи за управление, като присвоява идентификатор за всяка задача и позволява на вътрешния планировчик да реши дали две или повече задачи могат да се изпълняват паралелно. Например, повече от едно внедряване на клъстер може да се изпълни едновременно, както и други продължителни операции, като архивиране и автоматично качване на архиви в облачно хранилище.
При всяка операция за управление би било полезно, ако можем да наблюдаваме напредъка и състоянието на конкретна работа, като например мащабиране на нов подчинен за нашата MySQL репликация. Следната команда добавя нов подчинен, 10.0.0.77, за да мащабира нашата MySQL репликация:
$ s9s cluster --add-node --nodes="10.0.0.77" --cluster-id=24
Job with ID 66992 registered.След това можем да наблюдаваме идентификатора на заданието 66992, като използваме опцията за работа:
$ s9s job --log --job-id=66992
addNode: Verifying job parameters.
10.0.0.77:3306: Adding host to cluster.
10.0.0.77:3306: Testing SSH to host.
10.0.0.77:3306: Installing node.
10.0.0.77:3306: Setup new node (installSoftware = true).
10.0.0.77:3306: Setting SELinux in permissive mode.
10.0.0.77:3306: Disabling firewall.
10.0.0.77:3306: Setting vm.swappiness = 1
10.0.0.77:3306: Installing software.
10.0.0.77:3306: Setting up repositories.
10.0.0.77:3306: Installing helper packages.
10.0.0.77: Upgrading nss.
10.0.0.77: Upgrading ca-certificates.
10.0.0.77: Installing socat.
...
10.0.0.77: Installing pigz.
10.0.0.77: Installing bzip2.
10.0.0.77: Installing iproute2.
10.0.0.77: Installing tar.
10.0.0.77: Installing openssl.
10.0.0.77: Upgrading openssl openssl-libs.
10.0.0.77: Finished with helper packages.
10.0.0.77:3306: Verifying helper packages (checking if socat is installed successfully).
10.0.0.77:3306: Uninstalling existing MySQL packages.
10.0.0.77:3306: Installing replication software, vendor oracle, version 5.7.
10.0.0.77:3306: Installing software.
...Или можем да използваме флага --wait и да получим индикатор с лента за напредък:
$ s9s job --wait --job-id=66992
Add Node to Cluster
- Job 66992 RUNNING [ █] ---% Add New Node to ClusterТова е всичко за днешната добавка за наблюдение. Надяваме се, че ще опитате CLI и ще извлечете полза от него. Приятно групиране
