listopad 2024

Rozszerzanie Przestrzeni Dyskowej w Linux: Przewodnik Krok po Kroku z Użyciem LVM i fdisk

Posted on 13 listopada, 202413 listopada, 2024 by soban

Poszerzanie przestrzeni dyskowej w wirtualnych maszynach Linux to kluczowy element zarządzania systemami serwerowymi. W tym artykule pokazujemy, jak efektywnie zwiększyć przestrzeń dyskową używając narzędzi LVM i fdisk, bazując na rzeczywistych danych z systemu.

Wstępne przygotowania

Przed przystąpieniem do zmian w partycjach i woluminach, ważne jest, aby sprawdzić aktualny stan dysków w systemie. Użyjemy polecenia lsblk, aby zidentyfikować dostępne dyski i partycje.

lsblk

lsblk

Oto przykład wyniku polecenia lsblk na maszynie:

NAME                      MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
loop0                       7:0    0 55.7M  1 loop /snap/core18/2829
sda                         8:0    0   42G  0 disk
├─sda1                      8:1    0  512M  0 part /boot/efi
├─sda2                      8:2    0    1G  0 part /boot
└─sda3                      8:3    0 40.5G  0 part
  └─ubuntu--vg-ubuntu--lv 253:0    0 78.5G  0 lvm  /
sdb                         8:16   0  350G  0 disk
└─sdb1                      8:17   0   60G  0 part
  └─ubuntu--vg-ubuntu--lv 253:0    0 78.5G  0 lvm  /
sr0                        11:0    1 1024M  0 rom

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT

loop0 7:0 0 55.7M 1 loop /snap/core18/2829

sda 8:0 0 42G 0 disk

├─sda1 8:1 0 512M 0 part /boot/efi

├─sda2 8:2 0 1G 0 part /boot

└─sda3 8:3 0 40.5G 0 part

└─ubuntu--vg-ubuntu--lv 253:0 0 78.5G 0 lvm /

sdb 8:16 0 350G 0 disk

└─sdb1 8:17 0 60G 0 part

└─ubuntu--vg-ubuntu--lv 253:0 0 78.5G 0 lvm /

sr0 11:0 1 1024M 0 rom

Tworzenie snapshotów

Zanim przystąpimy do zmian w konfiguracji dysków, zaleca się wykonanie snapshotu woluminów LVM, aby zapewnić możliwość przywrócenia danych w przypadku nieoczekiwanych problemów.

lvcreate -L 20G -s -n my_snapshot /dev/ubuntu-vg/ubuntu-lv

1	lvcreate -L 20G -s -n my_snapshot /dev/ubuntu-vg/ubuntu-lv

Modyfikacja partycji

Następnie, przystępujemy do modyfikacji partycji, korzystając z fdisk. Usuwamy istniejącą partycję, a potem tworzymy nową, która wykorzysta całą dostępną przestrzeń na dysku sdb.

fdisk /dev/sdb

1	fdisk /dev/sdb

Zapis zmian

Po prawidłowym skonfigurowaniu partycji, korzystamy z komendy w w fdisk, aby zapisać zmiany i zaktualizować tabelę partycji.

Command (m for help): w

1	Command (m for help): w

Wykonanie pvscan

Po modyfikacji partycji, wykonujemy polecenie pvscan, aby system mógł zaktualizować informacje o dostępnych fizycznych woluminach.

pvscan

pvscan

Konfiguracja LVM

Po zapisaniu zmian w tabeli partycji, musimy zaktualizować konfigurację LVM, aby uwzględnić nową przestrzeń dyskową. Używamy polecenia lvextend z automatycznym rozszerzaniem systemu plików.

lvextend -l +100%FREE /dev/ubuntu-vg/ubuntu-lv -r

1	lvextend -l +100%FREE /dev/ubuntu-vg/ubuntu-lv -r

Podsumowanie

Rozszerzenie przestrzeni dyskowej na wirtualnej maszynie Linux poprawia wydajność i dostępność przestrzeni do przechowywania danych. Dzięki opisanym krokom, zarządzanie przestrzenią dyskową w systemach wykorzystujących LVM staje się prostsze i bardziej efektywne.

Rozwiązywanie problemów z klastrami Proxmox i przywracanie kontenera LXC

Posted on 13 listopada, 202413 listopada, 2024 by soban

Podczas zarządzania klastrami Proxmox można napotkać różne trudności techniczne, takie jak niespójności w konfiguracji klastra lub problemy z przywracaniem kontenerów LXC. Znalezienie i rozwiązanie tych problemów jest kluczowe dla utrzymania stabilności i wydajności środowiska wirtualizacji. W tym artykule przedstawiam szczegółowy przewodnik, jak zdiagnozować i rozwiązać problem z nieosiągalnym węzłem oraz jak pomyślnie przywrócić kontener LXC.

Zanim przystąpisz do jakichkolwiek działań, upewnij się, że masz aktualny backup systemu.

Diagnostyka stanu klastra Proxmox

pvecm delnode up-page-02
Node/IP: up-page-02 is not a known host of the cluster.

1 2	pvecm delnode up-page-02 Node/IP: up-page-02 is not a known host of the cluster.

oraz:

pct restore 107 vzdump-lxc-107-2024_11_12-03_00_01.tar.zst --storage local
CT 107 already exists on node 'up-page-02'

1 2	pct restore 107 vzdump-lxc-107-2024_11_12-03_00_01.tar.zst --storage local CT 107 already exists on node 'up-page-02'

Aby zrozumieć stan klastra, wykonaj na węźle node-up-page-04 polecenie:

pvecm nodes

1	pvecm nodes

Oczekiwany output:

Membership information
----------------------
    Nodeid      Votes Name
         1          1 node-up-page-01
         2          1 node-up-page-04 (local)

Membership information

----------------------

Nodeid Votes Name

1 1 node-up-page-01

2 1 node-up-page-04 (local)

Następnie sprawdź szczegółowe informacje o klastrze za pomocą polecenia:

pvecm status

1	pvecm status

Oczekiwany output:

Cluster information
-------------------
Name:             soban-proxmox
Config Version:   4
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Wed Nov 13 10:40:12 2024
Quorum provider:  corosync_votequorum
Nodes:            2
Node ID:          0x00000002
Ring ID:          1.e6
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   2
Highest expected: 2
Total votes:      2
Quorum:           2
Flags:            Quorate

Membership information
----------------------
    Nodeid      Votes Name
0x00000001          1 <masked IP>
0x00000002          1 <masked IP> (local)

Cluster information

-------------------

Name: soban-proxmox

Config Version: 4

Transport: knet

Secure auth: on

Quorum information

------------------

Date: Wed Nov 13 10:40:12 2024

Quorum provider: corosync_votequorum

Nodes: 2

Node ID: 0x00000002

Ring ID: 1.e6

Quorate: Yes

Votequorum information

----------------------

Expected votes: 2

Highest expected: 2

Total votes: 2

Quorum: 2

Flags: Quorate

Membership information

----------------------

Nodeid Votes Name

0x00000001 1 <masked IP>

0x00000002 1 <masked IP> (local)

Usuwanie pliku konfiguracyjnego kontenera i czyszczenie danych

Odkryłem, że plik konfiguracyjny kontenera 107 wciąż istnieje na systemie plików klastra w ścieżce:

ls -ltr /etc/pve/nodes/node-up-page-02/lxc/107.conf

1	ls -ltr /etc/pve/nodes/node-up-page-02/lxc/107.conf

Output:

-rw-r----- 1 root www-data 235 Nov 12 21:35 /etc/pve/nodes/node-up-page-02/lxc/107.conf

1	-rw-r----- 1 root www-data 235 Nov 12 21:35 /etc/pve/nodes/node-up-page-02/lxc/107.conf

Aby usunąć ten plik i wszelkie pozostałości danych związanych z odłączonym węzłem, wykonaj:

rm -rf /etc/pve/nodes/node-up-page-02/

1	rm -rf /etc/pve/nodes/node-up-page-02/

Przywracanie kontenera

Po usunięciu pliku konfiguracyjnego, przywróciłem kontener LXC na węźle node-up-page-04 za pomocą polecenia:

pct restore 107 /root/vzdump-lxc-107-2024_11_12-03_00_01.tar.zst --storage local

1	pct restore 107 /root/vzdump-lxc-107-2024_11_12-03_00_01.tar.zst --storage local

Output:

recovering backed-up configuration from '/root/vzdump-lxc-107-2024_11_12-03_00_01.tar.zst'
Formatting '/var/lib/vz/images/107/vm-107-disk-0.raw', fmt=raw size=59055800320 preallocation=off
Creating filesystem with 14417920 4k blocks and 3604480 inodes
Filesystem UUID: 8b707e55-5e14-4b20-8585-6cb09e0fa520
Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424
restoring '/root/vzdump-lxc-107-2024_11_12-03_00_01.tar.zst' now..
extracting archive '/root/vzdump-lxc-107-2024_11_12-03_00_01.tar.zst'

recovering backed-up configuration from '/root/vzdump-lxc-107-2024_11_12-03_00_01.tar.zst'

Formatting '/var/lib/vz/images/107/vm-107-disk-0.raw', fmt=raw size=59055800320 preallocation=off

Creating filesystem with 14417920 4k blocks and 3604480 inodes

Filesystem UUID: 8b707e55-5e14-4b20-8585-6cb09e0fa520

Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424

restoring '/root/vzdump-lxc-107-2024_11_12-03_00_01.tar.zst' now..

extracting archive '/root/vzdump-lxc-107-2024_11_12-03_00_01.tar.zst'

Proces przywracania zakończył się pomyślnie, a kontener był gotowy do użycia. Ten przypadek pokazuje, jak ważna jest dokładna diagnostyka i zarządzanie plikami konfiguracyjnymi w Proxmox podczas pracy z klastrami. Warto prowadzić regularne przeglądy konfiguracji, aby unikać niespójności i problemów operacyjnych w przyszłości.

Rozwiązywanie problemów związanych z performance_schema w MySQL

Posted on 7 listopada, 20247 listopada, 2024 by soban

Podczas codziennej pracy z bazami danych MySQL, mogą pojawić się specyficzne wyzwania, takie jak brakujące tabele lub błędy związane z nierozpoznaną bazą danych performance_schema. Te problemy mogą znacząco wpływać na wydajność i stabilność systemów bazodanowych, a ich diagnozowanie i rozwiązywanie bywa często skomplikowane i czasochłonne. Aby ułatwić to zadanie, stworzyłem ten przewodnik, który jest wynikiem moich doświadczeń oraz sprawdzonych praktyk. Zapewniam kompleksowe podejście do identyfikacji i naprawy problemów związanych z performance_schema. Jest to dosyć proste zaimportowanie schematu z nowo zbudowanej bazy danych.

Oczywiście przed całą operacją należy wykonać backup bazy najlepiej.

Początkowa diagnoza w MySQL

Zacznij od zidentyfikowania problemu w powłoce MySQL:

SHOW VARIABLES LIKE 'default_storage_engine';
ERROR 1146 (42S02): Table 'performance_schema.session_variables' doesn't exist
USE performance_schema;
ERROR 1049 (42000): Unknown database 'performance_schema';

SHOW VARIABLES LIKE 'default_storage_engine';

ERROR 1146 (42S02): Table 'performance_schema.session_variables' doesn't exist

USE performance_schema;

ERROR 1049 (42000): Unknown database 'performance_schema';

Utworzenie nowego schematu Performance Schema w MySQL

Tworzenie nowego schematu performance schema z linii komend MySQL:

CREATE DATABASE performance_schema;
shutdown;
\q

CREATE DATABASE performance_schema;

shutdown;

Operacje serwerowe do ustanowienia nowego środowiska MySQL

Wracamy do systemu, aby skonfigurować czyste środowisko MySQL:

systemctl stop mysql.service
mkdir /var/lib/mysql_new
mysqld --initialize --user=mysql --basedir=/usr --datadir=/var/lib/mysql_new
chown -R mysql:mysql /var/lib/mysql_new
cd /var/lib/mysql_new

systemctl stop mysql.service

mkdir /var/lib/mysql_new

mysqld --initialize --user=mysql --basedir=/usr --datadir=/var/lib/mysql_new

chown -R mysql:mysql /var/lib/mysql_new

cd /var/lib/mysql_new

Następnie, uruchom MySQL w trybie bezpiecznym, aby skonfigurować go – bez zewnętrznych przerwań sieciowych:

sudo -u mysql mysqld_safe --datadir=/var/lib/mysql_new --skip-grant-tables --skip-networking

1	sudo -u mysql mysqld_safe --datadir=/var/lib/mysql_new --skip-grant-tables --skip-networking

Konfiguracja i weryfikacja w MySQL

Powróć do linii komend MySQL, aby zweryfikować konfigurację i skonfigurować nową bazę danych:

mysql -u root
SHOW DATABASES;
USE performance_schema;
SHOW TABLES;

mysql -u root

SHOW DATABASES;

USE performance_schema;

SHOW TABLES;

Jak widać, tutaj performance_schema działa poprawnie.
Zaktualizuj hasło roota w środowisku MySQL, aby zabezpieczyć nową instalację:

USE mysql;
UPDATE user SET authentication_string=PASSWORD('NewSecurePassword');
FLUSH PRIVILEGES;
shutdown;
\q

USE mysql;

UPDATE user SET authentication_string=PASSWORD('NewSecurePassword');

FLUSH PRIVILEGES;

shutdown;

Uruchom ponownie MySQL w trybie bezpiecznym, aby upewnić się, że wszystkie konfiguracje zostały zastosowane:

sudo -u mysql mysqld_safe --datadir=/var/lib/mysql_new --skip-networking

1	sudo -u mysql mysqld_safe --datadir=/var/lib/mysql_new --skip-networking

Konfiguracji MySQL na serwerze w celu uruchomienia nowej bazy danych

Po zabezpieczeniu nowej konfiguracji MySQL, zaktualizuj konfigurację serwera, aby używać nowego katalogu danych:

vi /etc/mysql/my.cnf
# Zmień datadir na:
datadir=/var/lib/mysql_new

vi /etc/mysql/my.cnf

# Zmień datadir na:

datadir=/var/lib/mysql_new

Uruchom ponownie usługę MySQL, aby plik my.cnf został wczytany podczas startowania mysqla:

systemctl start mysql.service

1	systemctl start mysql.service

Eksportuj i przywróć schemat Performance Schema w MySQL

Z nową konfiguracją, eksportuj performance_schema za pomocą poleceń MySQL i przygotuj się do jego przywrócenia:

mysqldump -u root -p --no-data --skip-lock-tables performance_schema > /root/performance_schema.sql

1	mysqldump -u root -p --no-data --skip-lock-tables performance_schema > /root/performance_schema.sql

Należy wyłączyć mysqla:

shutdown;
\q

1 2	shutdown; \q

Przywróć oryginalny katalog danych MySQL na serwerze, uruchom ponownie usługę MySQL i zaimportuj wyeksportowany schemat:

vi /etc/mysql/my.cnf
# Zmień datadir z powrotem na:
datadir=/var/lib/mysql_old
systemctl start mysql.service
mysql -u root -p performance_schema < /root/performance_schema.sql
systemctl restart mysql.service

vi /etc/mysql/my.cnf

# Zmień datadir z powrotem na:

datadir=/var/lib/mysql_old

systemctl start mysql.service

mysql -u root -p performance_schema < /root/performance_schema.sql

systemctl restart mysql.service

Upewnij się, że domyślny silnik przechowywania działa, np:

SHOW VARIABLES LIKE 'default_storage_engine';
+------------------------+--------+
| Variable_name          | Value  |
+------------------------+--------+
| default_storage_engine | InnoDB |
+------------------------+--------+
1 row in set (0.00 sec)

SHOW VARIABLES LIKE 'default_storage_engine';

+------------------------+--------+

| Variable_name | Value |

+------------------------+--------+

| default_storage_engine | InnoDB |

+------------------------+--------+

1 row in set (0.00 sec)

Nie zapomnij usunąć śmieci:

rm -rf /var/lib/mysql_new/ /root/performance_schema.sql

1	rm -rf /var/lib/mysql_new/ /root/performance_schema.sql

Jeśli dotarłeś tutaj, pamiętaj o usunięciu backupu bazy danych – o ile wszystko działa. Bo wykonałeś takowy? 🙂