NDB MySQL & Distributed Privileges
Diesen Beitrag schrieb ich 11 Jahre und 5 Monate zuvor; die nachfolgenden Ausführungen müssen heute weder genau so nach wie vor funktionieren, noch meiner heutigen Meinung entsprechen. Behalte das beim Lesen (und vor allem: beim Nachmachen!) bitte stets im Hinterkopf.
Weitere Beiträge der Artikelserie „MySQL NDB Cluster“ findest du an dieser Stelle.
In dem frisch eingerichteten MySQL-NDB-Cluster werden die Benutzerdaten und Zugriffsrechte nicht auf den Data Nodes verteilt. Im Klartext bedeutet das: per default muss jeder neue User auf jedem Data Node eingerichtet werden. Für das von mir bezweckte Setup ist das aber nicht so günstig; ich möchte, dass auch die User Credentials verteilt werden. Glücklicherweise ist das recht einfach zu realisieren – man muss es halt manuell tun (distributed privileges, siehe auch hier). Mit ndb_dist_priv.sql in /usr/local/mysql/share bringt unsere Installation bereits ein Script mit, das genau für diesen Zweck gedacht ist – das müssen wir auf einem der Data Nodes einfüttern, ich entscheide mich für datanode1:
root@datanode1:~# mysql -u root -p --prompt 'datanode1> '
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 421
Server version: 5.6.24-ndb-7.4.6-cluster-gpl MySQL Cluster Community Server (GPL)
...
datanode1> SOURCE /usr/local/mysql/share/ndb_dist_priv.sql;
Durch diesen Aufruf werden die in der Datei enthaltenen Routinen importiert, was sich anschließend überprüfen lässt:
datanode1> SELECT ROUTINE_NAME, ROUTINE_SCHEMA, ROUTINE_TYPE FROM INFORMATION_SCHEMA.ROUTINES WHERE ROUTINE_NAME LIKE 'mysql_cluster%' ORDER BY ROUTINE_TYPE;
+---------------------------------------------+----------------+--------------+
| ROUTINE_NAME | ROUTINE_SCHEMA | ROUTINE_TYPE |
+---------------------------------------------+----------------+--------------+
| mysql_cluster_privileges_are_distributed | mysql | FUNCTION |
| mysql_cluster_backup_privileges | mysql | PROCEDURE |
| mysql_cluster_move_grant_tables | mysql | PROCEDURE |
| mysql_cluster_move_privileges | mysql | PROCEDURE |
| mysql_cluster_restore_local_privileges | mysql | PROCEDURE |
| mysql_cluster_restore_privileges | mysql | PROCEDURE |
| mysql_cluster_restore_privileges_from_local | mysql | PROCEDURE |
+---------------------------------------------+----------------+--------------+
7 rows in set (0.01 sec)
Relevant für uns ist eigentlich gerade nur die Prozedur mysql_cluster_move_privileges – sie erzeugt Backups der bestehenden privilege tables (MyISAM) und führt anschließend die Umwandlung zu ENGINE=ndbcluster durch.
datanode1> CALL mysql.mysql_cluster_move_privileges();
Query OK, 2 rows affected (4.32 sec)
War die Umwandlung wirklich erfolgreich? Das Ergebnis können wir uns in der Tat abrufen:
datanode1> SELECT CONCAT( 'Conversion ', IF(mysql.mysql_cluster_privileges_are_distributed(), 'succeeded', 'failed'), '.') AS Result;
+-----------------------+
| Result |
+-----------------------+
| Conversion succeeded. |
+-----------------------+
1 row in set (0.00 sec)
datanode1> datanode1> SHOW CREATE TABLE mysql.user;
...
PRIMARY KEY (`Host`,`User`)
) ENGINE=ndbcluster DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT='Users and global privileges'
Möchten wir prüfen, ob auch die MyISAM-Backups angelegt wurden, so genügt auch hierfür ein Aufruf:
datanode1> SELECT TABLE_NAME, ENGINE FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'mysql' AND TABLE_NAME LIKE '%backup' ORDER BY ENGINE;
+-------------------------+------------+
| TABLE_NAME | ENGINE |
+-------------------------+------------+
| db_backup | MyISAM |
| user_backup | MyISAM |
| columns_priv_backup | MyISAM |
| tables_priv_backup | MyISAM |
| proxies_priv_backup | MyISAM |
| procs_priv_backup | MyISAM |
| ndb_user_backup | ndbcluster |
| ndb_tables_priv_backup | ndbcluster |
| ndb_proxies_priv_backup | ndbcluster |
| ndb_procs_priv_backup | ndbcluster |
| ndb_db_backup | ndbcluster |
| ndb_columns_priv_backup | ndbcluster |
+-------------------------+------------+
12 rows in set (0.00 sec)
Bereits verbundene Clients müssen sich erneut verbinden, um die Änderungen zu sehen. Auf den anderen data nodes sind keine Änderungen nötig; auch nachträglich hinzugefügte Data Nodes müssen nicht mehr extra konfiguriert werden. Wird ein User auf einem Data Node angelegt, verändert, gelöscht – so ist das sofort auch auf allen anderen Knoten sichtbar. Für meine Einsatzzwecke optimal – so dass ich mich im nächsten Schritt mit einer einfachen Lastverteilung und Hochverfügbarkeit beschäftigen kann…
Hinterlasse einen Kommentar
Ich freue mich über jeden Kommentar, es sei denn, er ist blöd.
Deshalb sind die Kommentare auf dieser Seite auch generell moderiert.