NDB MySQL & Distributed Privileges
Diesen Beitrag schrieb ich 8 Jahre und 6 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…
Hintergrundbild: Bild genauer anschauen – © Marianne Spiller – Alle Rechte vorbehalten
