I want a simple way to see what commands are being sent to MySQL. I have several MySQL projects that sometimes have a few messy layers of code. I want something like SQL Server Profiler without all of the bells and whistles. I just need to see the SQL traffic. Not analyze which queries are executed most often.
I found MySQL Proxy and can't get it to work in Windows. I downloaded their binaries, and tried their first example LUA script from the link. It loads fine, but when I try to connect to port 4040 using mysql, I get:
ERROR 1105 (HY000): #07000MySQL Proxy Lua script failed to load. Check the error log.
What error log? I didn't even give it the credentials to connect to my real SQL Server. What can I do to get this to work? I'm open to other options (hopefully not sniffing traffic, but maybe if someone can make it easy).
Enable query logging in my.ini. this will write all queries to a log file
add the line
log = [querylog_filename]
Then restart the mysql service
using a program such as tail for win http://tailforwin32.sourceforge.net/ will allow you to watch the queries as they run.
if you have a problematic query you can enable slow logging as well. which will log important details about queries that take a long time to run
DC
Related
I am getting an error while running a SQL script to load data. Error is pasted below:
Preparing...
[WinError 32] The process cannot access the file because it is being used by another process: 'C:\\Users\\PRATIK~1\\AppData\\Local\\Temp\\tmpf75l0wi5.cnf'
I have tried uninstalling and installing MySQL several times but nothing is helping.
I faced the same issues while trying to run a MySQL script. I tried to find the process in the temp folder and removed it and tried again but the process seems to start again and appears in the temp folder. I could not run the script, however, I found a workaround, instead of running the script try to open it and run it in the query editor.
Just downgrade your MySQL workbench version.
In my case I downgraded the version from
8.0.25 to 8.0.20.
The sounds like you already had tried that script execution before and stopped it without stopping the mysqld process. So this process (which does the actual import) still holds a file lock on the temporary config file.
Try removing that file and check that all MySQL processes that you don't want are stopped. Then try again.
It seems the actual issue is not related to MySQL itself, but to MySQL Workbench.
The error you're seeing is a generic error coming from Windows itself, not from MySQL. It's unclear how you're running MySQL, for example is it in your localhost, in a Docker environment, or in a remote server.
It seems clear that at least two processes are trying to get an exclusive lock on that temporary file. My guess is that MySQL won't write temporary files to the user folder we're seeing (with your username Pratik).
On Windows, MySQL checks in order the values of the TMPDIR, TEMP, and TMP environment variables. For the first one found to be set, MySQL uses it and does not check those remaining. If none of TMPDIR, TEMP, or TMP are set, MySQL uses the Windows system default, which is usually C:\windows\temp.
Something you can do is to change your MySQL configuration so it uses a specific Temporary path you'll set, restart MySQL and retry running the query. If you see the error contains your new temporary path you've isolated the issue, it is indeed a MySQL problem. If you keep seeing this path you've isolated the issue to MySQL WorkBench.
An alternative approach would be to run the same query from another MySQL client, for example the command-line client mysql; and see if you're getting the same error.
Probably the simpler approach would be to try the queries with dBeaver, another MySQL client, and use that to isolate the issue to either the MySQL server itself or MySQL WorkBench.
This is a common issue for the upgraded version of MySQL, Try using Open Script instead of Run Script and that seems to clear up the issue.
I've found that it was already reported in the official bug tracker: https://bugs.mysql.com/bug.php?id=104841.
I've just checked, and it's still present in MySQL Workbench 8.0.30.
Work Around
Do not try to open the SQL file from this tool bar:
Go to Server > Data Import:
select import from self-contained file
select your target schema
then start import (bottom right btn)
Well, I'm trying to locate the log file to check errors in phpmyadmin interface and I saw in posts and forums that phpmyadmin have a binary log tab to check it, but I don't have enabled that tab and the solutions I found don't have any real solution to me...
Thanks yall!
The Phpmyadmin application does not have a log file, however you can perform this trick:
Phpmyadmin has a php script that when executed will return a result with the errors you find.
On Ubuntu Server the file is in:
/usr/share/phpmyadmin/error_report.php
then you must enter that folder and run
php error_report.php
this will return the errors that Phpmyadmin has, most of the time they are errors in the configuration file config.inc.php
What problem are you seeing with phpMyAdmin that you hope to fix by viewing the log? You haven't really described what problem you're trying to solve, which makes answering your question a bit difficult.
There are a number of logs available, but the most direct answer about the log file to check regarding errors with phpMyAdmin is in your webserver's error log. Read on for more details, though.
If it's a problem within phpMyAdmin directly (or something that phpMyAdmin does with MySQL), it's usually shown directly on the screen as a friendly message. If it's something that breaks phpMyAdmin directly, it's logged through whatever means you have configured for PHP errors to be logged (usually directly to the webserver error log).
If you're having a problem with a query through MySQL, those are logged by MySQL through the MySQL error log, which is usually to a file in most systems I'm familiar with.
The binary log is not related to error logging, but is instead an ongoing transaction log where MySQL records ongoing queries (docs, more docs). Based on your description, this is not what you're looking for.
I am running a mysql database and I connect to it just fine. My question is: whenever I connect to the database (to add new input via php) do I also have to include a disconnect command line?
I ask because my bandwidth usage is growing faster than I expected so I am happy thinking that I am getting traffic, but perhaps it is growing because I connect and do not "disconnect"?
From the mysql docs
mysql is a simple SQL shell with input line editing capabilities. It
supports interactive and noninteractive use.
The fact is that the SQL shell should not be causing major load on your box. The standard practice is to just close the shell and kill the program.
Typing Control+C causes mysql to attempt to kill the current
statement. If this cannot be done, or Control+C is typed again before
the statement is killed, mysql exits
When you exit mysql command line tool the process will end and mysql will continue doing its thing. But the answer to your question is no SQL shell should not be slowing things.
From PHP its a good idea to close the connection when you are done using it. To check out what processes are running open up mysql cmd tool and try the following to see what is connected to your mysql instance.
SHOW PROCESSLIST
if showprocesslist isnt what you were looking for give this a shot:
mysql > show status like '%onn%';
Hopefully this will give you enough information to handle the traffic load.
devzone.zend.com :
"Open connections (and similar resources) are automatically destroyed at the end of script execution. However, you should still close or free all connections, result sets and statement handles as soon as they are no longer required. This will help return resources to PHP and MySQL faster."
My advice:
It is a good practise to close a connection after doing the queries you wanted.
I found the following code on mysql forge site.
MySQL Proxy : An easy way to log all warnings and errors into a MySQL table.
http://forge.mysql.com/tools/tool.php?id=133
This may sound too basic, but from where do I start if I need this functionality.
Here you have more details about MySQL proxy scripting.
What you need to do with the script you linked is just run it on MySQL database and it will do all the magic for you. It's a complete server side solution so you don't have to worry about logging errors in your client application. MySQL will automatically run read_query function for every row returned and read_query_result for every set returned.
I have encountered this problem a couple of times, in the last few days. So, it happens occasionally. I have setup mysql on a remote machine, and there is a java program on another machine querying the database to read and write records every few seconds.
I am using phpMyAdmin to administer my database. And, at times, after running some SQL query, the mysql server stops responding. Even the pinging the host machine doesn't succeed. And, I have to ask someone with physical access to the machine to boot it up again.
I checked for log files but couldn't find them in the mysql directory. Is logging disabled by default? What is missing here? And, how can I go about troubleshooting this?
EDIT:
I was able to ping the server after some while. So, the server must have been temporarily busy. It's not a specific query but things like re-ordering the data of a table serially under the browse tab.
Use a mysqlclient to make a connection and keep it open.
I personally use the mysql from the commandline.
If the server becomes unresponsive execute
SHOW PROCESSLIST;
It will list all mysql processes and will show how long queries are waiting/executing.
Optionally use the KILL statement to terminate the query that locking the tables.
KILL $pid
I'd highly recommend using MySQL's own GUI tools for database management, for a vriety of reasons:
They have full support for InnoDB tables, including Foreign Key management
You can use database-level security to make sure only you get into your data (unlike phpMyAdmin, which at best can only be root access installed behind a .htaccess password)
It is official and supported. No extra binaries run on the server, so you run no risk of it crashing and taking the server down with it (unless your query itself is locking it...)