I am new to databases, have done my basic "homework" regarding the theoretical part, and set about using MySQL Server through MySQL Workbench.
I have created four "connections" which appear on the Workbench homescreen dashboard, and I have also created some tables. But when I login through any connection (using user name and password), I can see all of the tables that I have created. So can anyone please tell me what is the point behind multiple connections then? What exactly is a "Connection" in MySQL Workbench?
I tried googling it, searched it on StackOverflow, and even referred the user manual of MySQL workbench, but got no answers.
Each MySQL connection contains its own set of definitions. For example, the connections might connect to different MySQL servers, or the same MySQL server with different usernames, or enable SSL for one, or you might set up a connection to a remote MySQL server using the SSH options, and so on.
As for multiple connections to the same local MySQL server, you might have one connection using "root" with another using a less privileged user. Depending on how you set up the users, they may (or may not) both have rights to see and use the same databases (information).
So to summarize, connections simply connect to the MySQL server. If two connections use the same exact information then the results will be identical. However, that is not a common use case.
Related
I accidentally deleted all users in MySQL including localhost. Now I can't even access my connections. How can I add localhost use to access my connections?
localhost is not a user, it's a special host, referring, well, to the local host. That means the host machine the software in question is running on.
So, when using a MySQL Client software like Navicat, localhost means that you want it to connect to a MySQL database that is running on the same machine as Navicat itself, instead of connecting over the network to a database running on some remote machine.
Now, regarding your question, if you deleted the user table (or its content) from the MySQL database running on your localhost, the only way I know of to bring the users back is restoring a backup of the database, if you have one.
You might be able to get access to the database again by recreating the user table using the mysql_install_db script as pointed out here, but this won't recover the previously existing users.
I was wondering whether there is a way to define a specific database in the connection setup of MySQL Workbench (I know this works with other database software). Sometimes I have a lot of different databases on one server and I only want to access one with one connection. Can I specify the database in the connection settings somehow?
YES, On the home tab Click the + in MySQL Connections. And put the database name in the Default Schema: when you fill in all the usual info about ip address etc
Now if you only want to see the one database, then create a new MySQL user account and only allow this new account access to this single database. Then change the connection to the database to use the newly created MySQL account.
I guess you are seeing all the databases because you are using the root account.
On my AWS RDS MySQL instance I have some databases I didn't explicitly create there (and have never seen on my local MySQL databases, or on other hosted databases I've worked with) and wonder what they are (and what I can do about them):
information_schema
mysql
performance_schema
innodb
The first three are filled with data that I don't understand (and are listed separately in my MySQL tools; e.g. I have no ability to control privileges for them separately), while the last is empty. Can I delete the innodb? What are the others (I assume I should leave them alone)?
Forgive what may turn out to be a naive MySQL or AWS question; I'm fairly new to both.
These are all normal.
Every MySQL installation has the mysql and information_schema databases. If you can't see them, then either you either don't have permission to see them, or whatever you're using to connect to the MySQL server is hiding them from you. Most newer MySQL installations also have performance_schema.
The innodb database on RDS isn't really a database, but it shows up in the list because of the way the design of RDS interacts with MySQL server's internal concept that each directory inside that datadir is assumed to be a database. Files that InnoDB uses internally are stored there, even though the "database" itself appears to be empty. Just disregard it.
The mysql database contains tables used internally by MySQL, including the grant tables and time zone tables, and some DBA tools in the form of stored procedures that are specific to RDS, which are required due to the restricted access that even the administrator account has to an RDS instance, when compared to a standalone MySQL server.
http://dev.mysql.com/doc/refman/5.6/en/information-schema.html
http://dev.mysql.com/doc/refman/5.6/en/performance-schema.html
http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.CommonDBATasks.html
I recently installed the XAMPP stack on a desktop and connected via a laptop on the local network. To my surprise, I was able to access phpmyadmin and delete update all mysql tables. Though I understand that I shouldn't use xampp for production (and I'm not), I would still like to learn how to manage these types of obvious security flaws. I know that I can block access to directories via .htacces (http://forum.directadmin.com/showthread.php?t=29089), but I would like something that is a little more comprehensive. How would you restrict running of mysql queries from anywhere except localhost? Is there a way without .htaccess? I thought this was partially the purpose of the root user.
MySQL defined users with domains. If you look at your user_privileges table in the information_schema database you will see that they all have domains. If all your users are defined strictly as localhost, there will be no remote access.
Also, you can edit my.cnf to turn off tcp access to the database, forcing all connections to be by socket. under [mysqld], include the line skip-networking. You will have to configure all your apps to use the socket connection, but I like the socket better anyway.
This will do nothing to protect your data from someone using phpMyAdmin, if phpMyAdmin is installed on the same machine as the database. The safest thing to do is get rid of that app. That's often not practical, however, as it's a useful tool, and so you need to configure phpMyAdmin to require that users authenticate themselves. That means NOT putting the password in the config file. You will need to think about how long sessions are before reauthentication, and things like that.
phpMyAdmin fills me with a rage hotter than a thousand suns whenever I try to configure it, but it is definitely possible to set things up so a password is required each time you connect to the database through phpMyAdmin. You can further limit the damage phpMyAdmin abusers can do my making sure it only connects as a user with limited privileges (for instance, only able to modify the database you're working on at the moment).
I'm trying to link in MS Access to the tables in a MySQL database on a remote computer. I'm using a system DSN (ODBC), but when I try to link to the tables (Link Tables dialog) the dialog is empty. No error message, just a empty list. I'm sure I've a connection because after changing the Limit Connectivity to Hosts Matching field in the MySQL security tab (MySQL Workbench) from "%" to only "localhost", I get an error. All fields in the Administrative Roles tab are checked!
A few questions for you to consider:
Is that DSN associated with the database schema which includes the tables you want linked?
Does the DSN work in the opposite direction ... can you export an Access table to MySQL using that DSN?
Are there any provisions in MySQL to monitor client connections, requests, and so forth?
I'm basically grasping at straws on this one. But I'm wondering if maybe the DSN is functional, but perhaps not pointing at the MySQL location which includes the tables you want.
Point #2 should tell you whether the DSN is working at all. If you can export, find out where the exported table wound up in MySQL and compare that with the location of your other tables.