Bug #6828 | MySQL Administrator crashes and exits when I attempt to assign privileges | ||
---|---|---|---|
Submitted: | 25 Nov 2004 17:47 | Modified: | 27 Nov 2004 4:01 |
Reporter: | John McClenahan | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Administrator | Severity: | S2 (Serious) |
Version: | 1.0.14 | OS: | Linux (Fedora core 3 updated to 24 Nov) |
Assigned to: | Alfredo Kojima | CPU Architecture: | Any |
[25 Nov 2004 17:47]
John McClenahan
[25 Nov 2004 18:01]
John McClenahan
Later the same day... I have just discovered by accident how to add a schema - right click on an existing one! Not on Category, nor on Schema, where I had expected to find it. Simple, but not initially obvious. I've added a new schema now, but the initial problem is not affected - I still have both problems, even with the new schema highlighted. Intially, the replication privileges don't display, and the program still crashes and exits when I attempt to assign them to this user.
[27 Nov 2004 4:01]
Alfredo Kojima
To assign replication related privileges you need to have Global Privileges assignation enabled in Administrator. To enable it go to Edit->Preferences and toggle Show global privileges editor As for the crashing bug you found, it has been fixed and should be ok in the next release. Thank you for the bug report!
[28 Nov 2004 17:54]
John McClenahan
This suggestion helped considerably, but I found I still needed to download, install and use the command line client to complete the process. I also needed a lot of work (including reading the documentation) to understand how to limit the replication to one database. (The initial error logs, after I got any success at all, said there were problems in a 'user' table, which is in the mysql privileges etc database, not my actual data, so I guessed that the replication master and slave were both attempting to replicate the whole set of databases on the master server, including the default mysql and test databases). I tried to make a clean start again,in preparation for copying the original database contents, by deleting all the binary logs on both master and slave machines. Some complaints ensued about trying to continue replication from a now-non-existent position in a non-existent binary log, fixed by editing the master.info file. When I then tried to copy the starting data, using the LOAD DATA FROM MASTER command, I got 'OK. 0 rows updated' which suggested a problem in write permissions locally. I got round this, inelegantly, by giving all permissions except GRANT to the user I was connected as, via the command line, and trying the command again. THEN the data downloaded, I could restart binary logging on the master, and restart the slave. So finally it all came together and now seems to work fine.