doc:appunti:linux:sa:mysql
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
doc:appunti:linux:sa:mysql [2017/10/31 12:51] – [Log delle query] niccolo | doc:appunti:linux:sa:mysql [2025/03/12 14:55] (current) – [Restore selettivo di un database] niccolo | ||
---|---|---|---|
Line 18: | Line 18: | ||
Il server MySQL sta in ascolto sulla porta **TCP 3306**, nell' | Il server MySQL sta in ascolto sulla porta **TCP 3306**, nell' | ||
+ | |||
+ | Con Debian più recenti, ad esempio **Debian 11 Bullseye**, è installato il motore MariaDB ed è possibile utilizzare uno snippet di configurazione a parte, ad esempio creando il file **/ | ||
+ | |||
+ | < | ||
+ | [mysqld] | ||
+ | bind-address = 0.0.0.0 | ||
+ | </ | ||
===== Speciale Debian ===== | ===== Speciale Debian ===== | ||
Line 94: | Line 101: | ||
La prima GRANT crea un utente con accesso solo da // | La prima GRANT crea un utente con accesso solo da // | ||
- | Per vedere chi può accedere ad un database: | + | Per vedere i grant concessi ad un utente: |
+ | |||
+ | <code sql> | ||
+ | SHOW GRANTS FOR ' | ||
+ | </ | ||
+ | |||
+ | Altrimenti per vedere chi può accedere ad un database: | ||
<code sql> | <code sql> | ||
Line 115: | Line 128: | ||
</ | </ | ||
- | È possibile anche manipolare direttamente la tabella interna degli utenti: | + | Sarebbe |
<code sql> | <code sql> | ||
Line 136: | Line 149: | ||
SET PASSWORD FOR root=PASSWORD(' | SET PASSWORD FOR root=PASSWORD(' | ||
SET PASSWORD FOR dbuser@10.0.1.2=PASSWORD(' | SET PASSWORD FOR dbuser@10.0.1.2=PASSWORD(' | ||
+ | </ | ||
+ | |||
+ | La password è memorizzata storicamente nel campo **Password** della tabella **user**, ma versioni più recenti del motore MySQL (ad esempio **MariaDB 10**) possono usare plugin aggiuntivi e le informazioni staranno nei campi **plugin** e **authentication_string**: | ||
+ | |||
+ | < | ||
+ | SELECT Host, User, Password, plugin, authentication_string FROM user; | ||
+ | +-----------+-----------+----------------+-----------------------+-----------------------+ | ||
+ | | Host | User | Password | ||
+ | +-----------+-----------+----------------+-----------------------+-----------------------+ | ||
+ | | localhost | root | *CAE6919BF3... | | ||
+ | | localhost | user1 | ||
+ | | localhost | user2 | *B4C990D89F... | | ||
+ | +-----------+-----------+----------------+-----------------------+-----------------------+ | ||
</ | </ | ||
Line 153: | Line 179: | ||
</ | </ | ||
+ | |||
+ | ===== Restore selettivo di un database ===== | ||
+ | |||
+ | Se si ha un dump generato con **%%mysqldump --all-databases%%** potrebbe essere necessario fare il restore selettivo di un solo database. Una ricetta che si trova diffusamente in rete, ma che è davvero poco efficiente, consiste nel filtrare l' | ||
+ | |||
+ | Questo comando estrae dal dump compresso il singolo database e lo scrive in un dump SQL non compresso: | ||
+ | |||
+ | <code bash> | ||
+ | zcat mysql-dump.sql.gz \ | ||
+ | | sed -n '/^-- Current Database: `dbname`/,/ | ||
+ | > dbname-dump.sql | ||
+ | </ | ||
===== Visualizzare gli errori ===== | ===== Visualizzare gli errori ===== | ||
Line 221: | Line 259: | ||
password=MySecret | password=MySecret | ||
</ | </ | ||
+ | |||
+ | ===== Accesso root senza password ===== | ||
+ | |||
+ | Debian 9 Stretch installa il motore MariaDB 10.1.37 con una speciale configurazione, | ||
+ | |||
+ | Con questa query si verifica che l' | ||
+ | |||
+ | < | ||
+ | MariaDB [(none)]> | ||
+ | MariaDB [mysql]> SELECT user, host, password, plugin FROM user; | ||
+ | +--------------+-----------+-------------------------------------------+-------------+ | ||
+ | | user | host | password | ||
+ | +--------------+-----------+-------------------------------------------+-------------+ | ||
+ | | root | localhost | | unix_socket | | ||
+ | | oneuser | ||
+ | | anotheruser | ||
+ | </ | ||
+ | |||
+ | Per ripristinare il funzionamento con richiesta di password è necessario impostarla e rimuovere il plugin: | ||
+ | |||
+ | < | ||
+ | USE mysql; | ||
+ | SET PASSWORD FOR ' | ||
+ | UPDATE user SET plugin='' | ||
+ | FLUSH PRIVILEGES; | ||
+ | </ | ||
===== Log delle query ===== | ===== Log delle query ===== | ||
Line 236: | Line 300: | ||
SET GLOBAL general_log_file = '/ | SET GLOBAL general_log_file = '/ | ||
SET GLOBAL general_log = 1; | SET GLOBAL general_log = 1; | ||
+ | </ | ||
+ | |||
+ | Abilitare il logging solo per lo stretto necessario, per evitare consumo di risorse. Impostare **general_log = 0** per fermare il logging. | ||
+ | |||
+ | Per vedere le impostazini correnti: | ||
+ | |||
+ | <code sql> | ||
+ | SHOW GLOBAL VARIABLES LIKE ' | ||
</ | </ | ||
Line 269: | Line 341: | ||
mysqlrepair mysql help_topic | mysqlrepair mysql help_topic | ||
</ | </ | ||
+ | |||
+ | ===== Event Scheduler were found damaged ===== | ||
+ | |||
+ | È capitato un caso in cui un **mysqldump** generava il seguente errore (MariaDB 5.5.64 su CentOS 7.7): | ||
+ | |||
+ | < | ||
+ | mysqldump: Couldn' | ||
+ | Cannot proceed because system tables used by Event | ||
+ | Scheduler were found damaged at server start | ||
+ | </ | ||
+ | |||
+ | In effetti dal prompt SQL si riscontrava lo stesso problema: | ||
+ | |||
+ | < | ||
+ | CONNECT mysql; | ||
+ | SHOW EVENTS; | ||
+ | ERROR 1577 (HY000): Cannot proceed because system tables used | ||
+ | by Event Scheduler were found damaged at server start | ||
+ | </ | ||
+ | |||
+ | Dalla shell Unix sono stati eseguiti i seguenti comandi che hanno risolto il problema (non si sa se sono tutti e tre necessari, ma fino all' | ||
+ | |||
+ | < | ||
+ | mysqlcheck --all-databases --check-upgrade --auto-repair | ||
+ | mysql_upgrade | ||
+ | systemctl restart mariadb.service | ||
+ | </ | ||
+ | ===== Utenti e privilegi ===== | ||
+ | |||
+ | Queste sono le **tabelle mysql** che contengono informazioni circa i GRANT: | ||
+ | |||
+ | * **user** User accounts, global privileges, and other non-privilege columns. | ||
+ | * **db** Database-level privileges. | ||
+ | * **tables_priv** Table-level privileges. | ||
+ | * **columns_priv** Column-level privileges. | ||
+ | * **procs_priv** Stored procedure and function privileges. | ||
+ | |||
+ | ===== Encoding del database e delle tabelle ===== | ||
+ | |||
+ | Pare che ancora nel 2020 MySQL (MariaDB 10.3) crei le tabelle con encoding **Latin1**. Ecco come verificare l' | ||
+ | |||
+ | < | ||
+ | SELECT default_character_set_name FROM information_schema.SCHEMATA | ||
+ | WHERE schema_name = ' | ||
+ | |||
+ | +----------------------------+ | ||
+ | | default_character_set_name | | ||
+ | +----------------------------+ | ||
+ | | utf8mb4 | ||
+ | +----------------------------+ | ||
+ | </ | ||
+ | |||
+ | < | ||
+ | SELECT CCSA.character_set_name FROM information_schema.TABLES T, | ||
+ | information_schema.COLLATION_CHARACTER_SET_APPLICABILITY CCSA | ||
+ | WHERE CCSA.collation_name = T.table_collation AND T.table_schema = ' | ||
+ | AND T.table_name = ' | ||
+ | |||
+ | +--------------------+ | ||
+ | | character_set_name | | ||
+ | +--------------------+ | ||
+ | | latin1 | ||
+ | +--------------------+ | ||
+ | </ | ||
+ | |||
+ | ===== Errore " | ||
+ | |||
+ | Può capitare con l' | ||
+ | |||
+ | Ovviamente i dati contenuti nella tabella sono persi, ma dovrebbe essere possibile ricostruire la struttura dal file **frm**. Nella pagina **[[https:// | ||
+ |
doc/appunti/linux/sa/mysql.1509450677.txt.gz · Last modified: 2017/10/31 12:51 by niccolo