Archiwa MySQL

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? 🙂

Wprowadzenie

Pracując z MySQL, można napotkać różne błędy, które mogą zakłócić działanie systemu. Kod błędu 1114 jest jednym z nich i wskazuje na sytuację, gdy tabela, do której użytkownik próbuje zapisać dane, jest pełna. Ten problem jest szczególnie znaczący w systemie replikacji MySQL, gdzie jego rozwiązanie jest kluczowe dla zapewnienia ciągłości pracy.

Opis problemu

Błąd 1114 manifestuje się komunikatem: „Could not execute Write_rows event on table docs; The table 'docs’ is full”. Oznacza to, że nowe wiersze nie mogą zostać zapisane z powodu przekroczenia rozmiaru tabeli tymczasowej. Szczegółowy komunikat błędu może wyglądać tak:

Zaloguj się do MySQL:

# mysql -u root -p

1	# mysql -u root -p

Zmień wartości zmiennej:

SET GLOBAL tmp_table_size = 268435456;  -- Ustawienie na 256M
SET GLOBAL max_heap_table_size = 268435456;  -- Ustawienie na 256M

1 2	SET GLOBAL tmp_table_size = 268435456; -- Ustawienie na 256M SET GLOBAL max_heap_table_size = 268435456; -- Ustawienie na 256M

Po wprowadzeniu tych zmian, wszystkie nowe połączenia do serwera MySQL będą używać tych zaktualizowanych wartości. Możesz je sprawdzić, wykonując:

SHOW GLOBAL VARIABLES LIKE 'tmp_table_size';
SHOW GLOBAL VARIABLES LIKE 'max_heap_table_size';

1 2	SHOW GLOBAL VARIABLES LIKE 'tmp_table_size'; SHOW GLOBAL VARIABLES LIKE 'max_heap_table_size';

Albo

SELECT @@tmp_table_size, @@max_heap_table_size;

1	SELECT @@tmp_table_size, @@max_heap_table_size;

Teraz replikacje można wznowić i powinna lepiej działać. Jednak należy pamiętaj, o modyfikacji konfiguracji, aby po restarcie mysqla zmienne te zostały poprawnie ustawione. Może być koniecznie tutaj wznowienie np replikacji (jeśli wcześniej została zatrzymana):

START SLAVE;

1	START SLAVE;

Jeśli problem został rozwiązany, na tym etapie sprawdzenie stanu replikacji:

show slave status \G

1	show slave status \G

Nie powinien zwracać żadnych błędów.

Modyfikacja pliku konfiguracyjnego /etc/mysql/my.cnf:

# cat /etc/mysql/my.cnf
...
tmp_table_size=256M
max_heap_table_size=256M
...

# cat /etc/mysql/my.cnf

...

tmp_table_size=256M

max_heap_table_size=256M

...

Restart usługi MySQL:

# systemctl restart mysql

1	# systemctl restart mysql

Przed restartem usługi zalecane jest wykonanie SHUTDOWN; w kliencie MySQL.
Należy pamiętać o wznowieniu replikacji.

Ważne uwagi

Zasoby systemowe: Upewnij się, że serwer dysponuje wystarczającą ilością pamięci RAM do obsługi zwiększonych wartości zmiennych.
Monitoring wydajności: Po dokonaniu zmian monitoruj wydajność, aby sprawdzić, czy problem został rozwiązany.
Trwałość konfiguracji: Zmiany w pliku konfiguracyjnym powinny być trwałe, aby uniknąć resetowania wartości po restarcie.

Dodatkowe kroki sprawdzające

Sprawdzenie dostępnej przestrzeni dyskowej: Możliwe, że problem wynika również z braku dostępnej przestrzeni na dysku. Można to sprawdzić za pomocą poniższej komendy:

# df -h

# df -h

Podsumowanie

Rozwiązanie problemu związanego z kodem błędu 1114 w replikacji MySQL wymaga zrozumienia i dostosowania konfiguracji systemu. Opisane kroki pokazują, jak poprzez zwiększenie rozmiaru tabeli tymczasowej można zapobiec występowaniu tego błędu, co umożliwia sprawne działanie systemu replikacji.

Kategoria: MySQL

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

Początkowa diagnoza w MySQL

Utworzenie nowego schematu Performance Schema w MySQL

Operacje serwerowe do ustanowienia nowego środowiska MySQL

Konfiguracja i weryfikacja w MySQL

Konfiguracji MySQL na serwerze w celu uruchomienia nowej bazy danych

Eksportuj i przywróć schemat Performance Schema w MySQL

Rozwiązywanie Problemu MySQL – Error_code: 1114

Wprowadzenie

Opis problemu

Ważne uwagi

Dodatkowe kroki sprawdzające

Podsumowanie