Does MySQL keep a transaction log and if so where could I find it?
A number of rows have mysteriously been deleted from a table and I want to try and see how and when it occurred.
If you turned on - mysql can track binary log, which contains all the modifications (to be clear - it contains the queries that had changed something).
But anyway, it is useless if you do not have the initial dump, which precedes the binlog turning on. Also i suppose if you made the dump and turned on binlog - you would not ask such question :-S
Short answer: not by default.
In order to have accurate logging results, you need to have started the server in binary logging mode first, using the parameter --log-bin=your-file-name. It then creates a binary log file {your-file-name.seq} where seq is a sequence number for subsequent log files (recommended to put your file name there, with explicit directory location).
More information on the MySQL site explaining all the details: https://dev.mysql.com/doc/refman/5.7/en/binary-log.html
If you're using MySql on Windows, there's a file located in C:\Program Files\MySQL\MySQL Server 5.0\data (assuming a C: drive for the installation target and MySql version 5.0), that is called %COMPUTERNAME%.log that contains the commands that have been executed.
Related
I'm unsure if my mysql is actually being monitor by monit. See screenshot.
As you can see under processes the mysqld process is not being monitored (it failed a sew times first) but under files there is mysql_bin and mysql_rc both of which are OK.
Is it safe to remove the mysql monitoring symbolic link or do i need this anyway?
thanks
Short answer is no. Some more info:
That both of the entries in the File section are OK does not relate to any kind of working or running application. The File section of monit simply checks file state information, such as, but not limited to, last modification time, size, file hashes, etc.
So basically the two OKs in File section just tell you that the mysql files are present and have not been changed.
The entry inside Process section is what you want to focus an. It checks the presence of a running mysqld process on your system. You need to check if the configuration of that entry inside monitrc (or included files) is looking for the right parameters. It should watch out for a process using a pidfile and could potentially check if a connection could be established.
See monit docs on MySQL and/or paste your monit config for any in-depth help regarding monit.
PS: #Shadow: The question (more likely: the resulting problem) has nothing to do with a DB, but is a question about monitoring.
I'm trying to create a DataBase for a very little program that just I and 2 more friends use, so the database will be little.
What I want to do is to share this database with these 2 friends, so I thought about storing the data in a OneDrive shared folder.
At the moment, I'm using a txt file as a "database". Which is placed in a shared OneDrive folder, so when my friends execute the program, it can read the data from there and make it sort of real time "online".
The thing is that I can't find the my.ini file in my
C:\Program Files\MySQL\MySQL Server 8.0\
directory, so I can't change the data folder.
Another trouble I have is that I also don't have the Data folder in that directory, instead I've found it in this one:
C:\Program Files\MySQL\MySQL Workbench 8.0 CE
Is it possible to do what I want to do? And how should I proceed?
Do you think I should be using MySQL 5.x version?
Thanks
If you want to share a database with a couple of other users, putting the datadir in OneDrive isn't going to work.
MySQL stores data in the files under the datadir, that's true. They're stored in files called tablespaces which have the .ibd extension.
But as you do INSERT/UPDATE/DELETE operations, data is temporarily stored in memory and in the transaction logs (ib_logfile*. MySQL has to do a delicate coordination between these, to save data in a durable way, while ensuring good performance. It works well, but only if the MySQL Server is the only process writing to the files.
OneDrive is not coordinating with MySQL at all. It will periodically check for files that have changed since it last did a sync. The interval OneDrive checks files is about every 10 minutes, and this is not configurable.
OneDrive may choose to sync the files at a moment after you've done some INSERT/UPDATE/DELETE operations, and the data is modified in RAM, but hasn't yet been updated in the tablespace files on disk.
Once you've committed a change, it must also be safely stored in the transaction log, even if it isn't updated in the tablespace. But if your friends receive the files in this state (transaction log contains changes which aren't present in the tablespace), they can reconstruct the data from your RAM that they didn't get. This is called InnoDB crash recovery. MySQL Server does if automatically if it starts up and finds the transaction log contains changes that aren't in the tablespace. It assumes you had a sudden reboot and lost what was in RAM.
If your friends try to just keep their MySQL Server running continuously, reading a datadir that is simultaneously being updated by their one OneDrive, it'll basically overwrite their files and MySQL will become confused. It only checks to see if it should do crash recovery as MySQL Server starts. So if the files change in unexpected ways while MySQL Server is already running, it'll just conclude that your hard drive has gotten corrupted. It'll probably report a fatal error and shut down MySQL.
Also if your friends try to make changes of their own to the database, their changes would conflict with the updates from OneDrive. Then their attempts to overwrite files would eventually be synchronized in the opposite direction via OneDrive, and would eventually corrupt your database too. This would happen without warning at 10 minute intervals, whenever OneDrive chose to do its file sync.
So I'm afraid OneDrive is not the solution to share your database.
Alternatives that do have a chance of working include:
Hosting a single instance of MySQL Server on a website that you all share, and giving each of you a client that can use the database. A popular free client is phpMyAdmin. That way there'd be only one instance of MySQL Server, one datadir, even though you each would be concurrent clients reading and writing data. This is the simplest solution, most likely to work.
Exporting the data from your MySQL Server instance using mysqldump periodically, and putting the export file on OneDrive, or sending it to your friends through email or any other means. Then they would have to import that data to their MySQL Server manually. This would overwrite any changes they had done to their database, but it wouldn't appear as corruption. If they want to send changes back to you, they could do a similar operation: export their database, put the dump file on OneDrive, then you'd get their dump file and import it to your MySQL Server instance, overwriting any changes you had done locally since the last time you sent your export to your friends.
Use a MySQL add-on for multi-server synchronous replication, such as InnoDB Group Replication or Percona XtraDB Cluster. But this is probably too complex for you to set up if you're a newbie with MySQL.
I accidentally dropped a database which I used for my web application, and it is in MySQL. Browsing through the internet I found out that to recover you need to have binary logs enabled. Read that binary logs records only changes in tables, so what it has to do with recovering a db. Upon executing the command "show binary logs;" console shows me "Error Code: 1381. You are not using binary logging". I am a newbie to MySQL, so is it possible to recover it without my binary logging enabled PLUS I have not made any real backup for the db. Going through the MySQL "my.cnf" file found that InnoDB is default enabled, can it help me recover.
If I cannot recover, please mention the steps to be carried out next time creating a new db to ensure that I could recover even if it has been accidentally deleted.
I think it can't be recovered. In case of this case, you can do the following when creating a new db:
open the binary log by add the following:
log-bin=/data/mysqlbinlog/mysql-bin
binlog-format=mixed (or row)
create a slave db.
Good luck for you.
I am looking to write a backup / restore script based on MYSQL's binary logging.
I have a database on a mysql server, and my colleague also has his own database on the same mysql server.
Looking at the binary logs, I see the statements are logged for both these databases.
Is the database being written to specified in the logs?
Can I safely replay a binary log containing an extra database in it - i.e. I want to replicate database_A, my binary log file contains commands sent to database_A as well as database_B, can I replay these commands into a copy of database_A safely? Or do I need to ask my sysadmin to only log things for dataabse_A?
OK, studying the log files a bit more, it seems that the mysql binlog utility adds the "use database" statements in the appropriate place. I added a part to my script that effectively grepped out the relevant database statements.
I have a mysql log file that regularly goes over 30gb, this sucks when you realise that your server is full because of this file. I need a simple solution to limit this file to about 1gb, i don't need logs that run that long, and i'd rather avoid this problem in the future.
Any ideas? Thanks
To specify it in the my.cnf file, backup your current my.cnf file (always recommended), stop slave, stop the MySQL server and place the following option:
# relay log restrictions
relay-log-space-limit=15G
Then save and quit the file and start MySQL. Unless you configured differently, MySQL will automatically start the slave thread.