Saya menjalankan MySQL 5.0.45 pada OS X 10.6.1 dan saya tidak bisa membuat MySQL untuk login apa pun. Saya men-debug aplikasi dan perlu melihat semua pertanyaan dan kesalahan.
Saya menambahkan ke etc / my.cnf:
[mysqld]
bind-address = 127.0.0.1
log = /var/log/mysqld.log
log-error = /var/log/mysqld.error.log
Saya menggunakan sudo untuk membuat dua file log, mengatur izin ke 644, lalu me-restart MySQL.
Saya merujuk ke
Mana log mysql saya di OS X? untuk memecahkan masalah.
Berlari:
ps auxww|grep [m]ysqld
Pengembalian:
_mysql 71 0.0 0.8 646996 15996 ?? S 7:31PM 0:01.10 /usr/local/mysql/libexec/mysqld --basedir=/usr/local/mysql --datadir=/usr/local/mysql/var --pid-file=/usr/local/mysql/var/Macintosh-41.local.pid
_mysql 46 0.0 0.0 600336 744 ?? Ss 7:30PM 0:00.03 /bin/sh /usr/local/mysql/bin/mysqld_safe
Dan berlari:
$(ps auxww|sed -n '/sed -n/d;/mysqld /{s/.* \([^ ]*mysqld\) .*/\1/;p;}') --verbose --help|grep '^log'
Pengembalian:
log /var/log/mysqld.log
log-bin (No default value)
log-bin-index (No default value)
log-bin-trust-function-creators FALSE
log-bin-trust-routine-creators FALSE
log-error /var/log/mysqld.error.log
log-isam myisam.log
log-queries-not-using-indexes FALSE
log-short-format FALSE
log-slave-updates FALSE
log-slow-admin-statements FALSE
log-slow-queries (No default value)
log-tc tc.log
log-tc-size 24576
log-update (No default value)
log-warnings 1
Berlari:
mysql> show variables like '%log%';
Pengembalian:
+---------------------------------+---------------------------+
| Variable_name | Value |
+---------------------------------+---------------------------+
| back_log | 50 |
| binlog_cache_size | 32768 |
| expire_logs_days | 0 |
| innodb_flush_log_at_trx_commit | 1 |
| innodb_locks_unsafe_for_binlog | OFF |
| innodb_log_arch_dir | |
| innodb_log_archive | OFF |
| innodb_log_buffer_size | 1048576 |
| innodb_log_file_size | 5242880 |
| innodb_log_files_in_group | 2 |
| innodb_log_group_home_dir | ./ |
| innodb_mirrored_log_groups | 1 |
| log | ON |
| log_bin | OFF |
| log_bin_trust_function_creators | OFF |
| log_error | /var/log/mysqld.error.log |
| log_queries_not_using_indexes | OFF |
| log_slave_updates | OFF |
| log_slow_queries | OFF |
| log_warnings | 1 |
| max_binlog_cache_size | 4294967295 |
| max_binlog_size | 1073741824 |
| max_relay_log_size | 0 |
| relay_log_purge | ON |
| relay_log_space_limit | 0 |
| sync_binlog | 0 |
+---------------------------------+---------------------------+
26 rows in set (0.00 sec)
Adakah bantuan tentang bagaimana saya bisa membuat MySQL untuk login?
5.4.3 The General Query Log
The general query log is a general record of what mysqld is doing. The server writes information to this log when clients connect or disconnect, and it logs each SQL statement received from clients. The general query log can be very useful when you
suspect an error in a client and want to know exactly what the client sent to mysqld.
Each line that shows when a client connects also includes using
connection_type
to indicate the protocol used to establish the connection. connection_type
is one of TCP/IP
(TCP/IP connection established without SSL), SSL/TLS
(TCP/IP connection
established with SSL), Socket
(Unix socket file connection), Named Pipe
(Windows named pipe connection), or Shared Memory
(Windows shared memory connection).
mysqld writes statements to the query log in the order that it receives them, which might differ from the order in which they are executed. This logging order is in contrast with that of
the binary log, for which statements are written after they are executed but before any locks are released. In addition, the query log may contain statements that only select data while such statements are never written to the binary log.
When using statement-based binary logging on a replication source server, statements received by its replicas are written to the query log of each replica. Statements are written to the query log of the source if a client reads events with the
mysqlbinlog utility and passes them to the server.
However, when using row-based binary logging, updates are sent as row changes rather than SQL statements, and thus these statements are never written to the query log when
binlog_format
is ROW
. A given update also might not be written to the query log when this variable is set to MIXED
, depending on the statement used. See Section 17.2.1.1, “Advantages
and Disadvantages of Statement-Based and Row-Based Replication”, for more information.
By default, the general query log is disabled. To specify the initial general query log state explicitly, use --general_log[={0|1}]
. With no argument or an argument of 1,
--general_log
enables the log. With an argument of 0, this option disables the log. To specify a log file name, use --general_log_file=file_name
. To specify the log destination, use the
log_output
system variable (as described in Section 5.4.1, “Selecting General Query Log and Slow Query Log Output Destinations”).
If you specify no name for the general query log file, the default
name is host_name
.log
. The server creates the file in the data directory unless an absolute path name is given to specify a different directory.
To disable or enable the general query log or change the log file name at runtime, use the global general_log
and
general_log_file
system variables. Set general_log
to 0 (or OFF
) to disable the log or to 1 (or ON
) to enable it. Set general_log_file
to
specify the name of the log file. If a log file already is open, it is closed and the new file is opened.
When the general query log is enabled, the server writes output to any destinations specified by the log_output
system variable. If you enable the log, the server opens the log file and writes startup messages to it. However, further logging of queries to the file does
not occur unless the FILE
log destination is selected. If the destination is NONE
, the server writes no queries even if the general log is enabled. Setting the log file name has no effect on logging if the log destination value does not contain FILE
.
Server restarts and log flushing do not cause a new general query log file to be generated (although flushing closes and reopens it). To rename the file and create a new one, use the following commands:
$> mv host_name.log host_name-old.log
$> mysqladmin flush-logs
$> mv host_name-old.log backup-directory
On Windows,
use rename rather than mv.
You can also rename the general query log file at runtime by disabling the log:
SET GLOBAL general_log = 'OFF';
With the log disabled, rename the log file externally (for example, from the command line). Then enable the log again:
SET GLOBAL general_log = 'ON';
This method works on any platform and does not require a server restart.
To disable or enable general query logging for the current session, set the session
sql_log_off
variable to ON
or OFF
. (This assumes that the general query log itself is enabled.)
Passwords in statements written to the general query log are rewritten by the server not to occur literally in plain text. Password rewriting can be suppressed for the general query log by starting the server with the
--log-raw
option. This option may be useful for diagnostic purposes, to see the exact text of statements as received by the server, but for security reasons is not recommended for production use. See also Section 6.1.2.3, “Passwords and Logging”.
An implication of password rewriting is that statements that cannot be parsed (due, for example, to syntax errors) are not written to the general query log because they cannot be known to be password free. Use cases that require logging of all statements including those with errors should use the --log-raw
option, bearing in mind that this also bypasses password rewriting.
Password rewriting occurs only when plain text passwords are expected. For statements with syntax that expect a password hash value, no rewriting occurs. If a plain text password is supplied erroneously for such syntax, the password is logged as given, without rewriting.
The log_timestamps
system variable controls the time zone of timestamps in messages written to the
general query log file (as well as to the slow query log file and the error log). It does not affect the time zone of general query log and slow query log messages written to log tables, but rows retrieved from those tables can be converted from the local system time zone to any desired time zone with CONVERT_TZ()
or by setting the session
time_zone
system variable.