I have multiple mysql databases and I want to perform some administration tasks on a particular database. How do I ensure that no one else can connect to that database while the tasks in progress?
Apparently, you can use the FLUSH command for this as such:
> FLUSH TABLES WITH READ LOCK;
and then
> UNLOCK TABLES;
to unlock the database again. Unsure if some setting needs to be set on the tables to allow a readlock. You can test this by trying to do a manual insert after the database is locked and if you get an error message about the table being locked, you know it worked.
More information on FLUSH command
You have a couple of options, as I see it:
Shutdown mysqld, the daemon that connections to be established to databases. This has the downside of preventing access to all the mysql databases on that computer.
Move the file or change the access permissions to it, so that only your user may work with it. (I have no idea if this will work.) The database files are located somewhere like /var/lib/mysql. Just don't forget when you're done to change them back to something that mysqld will be able to work with!
Good luck!
If you can afford stopping the server for the time of maintenance, stop the daemon and reconfigure it to not listen to network connections. Only allow connections through a local UNIX socket.
Then logon locally on the same machine, either physically or via SSH. As long as nobody else has access to the machine, this will ensure you are alone. When done, restore the original configuration file and restart the daemon.
A different approach would be to temporarily disable all user accounts but "root" (or whatever you use to do your maintenance) for the particular database. This has the drawback however of actually messing with account data which is a little more risky than just preventing network connections.
Related
I'm trying to upload a large database:
$mysql -u USERNAME -p MY_DATABASE < MY_DATABASE.sql
But the process is going extremely slowly, I would like to cancel and try again with different settings. How can I cancel this upload 'safely'? Or what is the best way to clean up my database after forced termination of the import?
You can kill MySQL process involved in your MY_DATABASE.sql
This show you running processes:
show processlist;
Then you should kill the process selecting it by the correct process_id from the user and time shown from previous command to understand which one is the correct one, if others processes are running:
kill process_id
I think that cleaning the DB is the hardest work, because it depends on the MY_DATABASE.sql content: if it populates a table, you can simply truncate it, if it create a DB and upload tables, views, stored procedures and other elements, you should drop the DB.
If you take a look at the MY_DATABASE.sql content and at the server content after killing the process (db created? tables or other elements created?) you will understand what to do.
If, as I can imagine, the script creates entirely a DB, you should only have to drop the DB created from the previous interrupted upload, if any, and restart the upload.
Rather stopping MySQL import with killing the process, I prefer use terminate key which is ctrl+c and service mysqld restart or service mysql restart.
This just ends the import process and it gets sometimes to end. Once it's done you can go with your process. If you end the process with killing it may cause some unexpected errors like a mysql server crash.
i just moved out RDS and setup my own Master/Slave mysql replication.
The replication is working fine, but my slave node is accepting changes, differently of what happened on RDS (the server generated an error saying that the server was on read only mode).
I trie to activate on my my.cnf the configuration read_only = ON (on the slave)...
but even after a service restart, the server continues to accept changes.
What am i doing wrong? I want that the servers accepts changes ONLY from the replication connection...
Just found it...I was using root user, and root can do anything.... for user without super privileges, the read-only IS working.
I don´t get it. Everytime when i´ve deleted all the content of a mysql-directory in var/lib/mysql/mywebsite, my website still runs on any device or browser without any negative effect. If i look in phpMyAdmin, the database is completely empty! If i delete the whole directory (with directory itself), it has an effect (site is gone), but after restoring this directory with an different database, the old version appears on the website again instead of the new restored database!
BUT if i clear my database tables of that same database in phpMyAdmin, it affects my site immediately... why is that, could it be, that there is any kind of DB-caching on my Vserver?
After:
service mysqld restart
everything is normal, means: right content / right database.
Would be nice if somebody could help me with this.
CentOS 6.9 (Final)
Plesk Onyx 17.5.3 Update Nr. 4
Wordpress 4.7.4 (without caching enabled / caching plugins)
On Unix, if a process has a file open while another process deletes it, the process can still access the file -- it doesn't really go away until all processes close it. The mysqld process already has the database files open. So deleting the directory doesn't affect the contents of the database until you restart it, which forces it to reopen all the files.
Also, mysqld loads indexes into memory when possible, and doesn't reread them from the file if it doesn't need to.
In general, you should avoid manipulating the files used by a database directly while the daemon is running, the results can be very unpredictable. You should preferably use commands in the database client to manage the database contents, but if you need to restore it from a file-level backup, you should shut down the daemon first.
Try drop database in PhpMyAdmin, Or execute in your console.
DROP DATABASE database_name;
Objective: to be able to synchronize 2 linux server realtime.
My concern is after using Rsync to mirror the mysql server. The only thing it wasnt able to synchronize is the entries (ie. inserting data to the database using the insert query). How will I be able to solve this?
Things I've done:
scp the keys of the 2 server so that password wont be asked for each transaction
I used
rsync -avc /var/lib/mysql/ root#10.1.99.XXX:/var/lib/mysql/
to sync the database/tables, but wasn't able to sync the entries.
Isubaki,
It's not quite as simple as just using rsync, as mysql may have the files open at the time you are pushing them across. Linux will do the file copy ok, but using this technique, the table is locked in memory until the database is restarted.
I do have a script that will do the sync part, but it does require a database restart, which may not be what you want (you mention realtime sync)
I use the following rsync command to backup my MySQL data to a machine within the LAN network. It works as expected.
rsync -avz /mysql/ root:PassWord#192.168.50.180:: /root/testme/
I just want to make sure that this is the correct way to use rsync.
I will also like to know if the 5 minute crontab entry for this will work.
don't use the root user of the remote machine for this. In fact, never directly connect to the root user, that's a major security risk. In this case, simply create a new user with few privileges that may only write to the backup location
Don't use a password for this connection, but instead use public-key authentication
Make sure that MySQL is not running when you do this, or you can easily get a corrupt backup.
Use mysqldump to create a dump of your database while MySQL is running. You can then safely copy that dump.
I find a better way of doing backups of MySQL is to use the replication facility.
set up you backup machine as a slave of your master. Each transaction is then automatically mirrored.
You can also shut down the slave and perform a full backup to tape from it. When you restart the slave it synchronises with the master again.
I don't really know about your rsync command, but I am not sure this is the right/best way to make backup with MySQL ; you should probably take a look at this page of the manual : 6.1. Database Backups
DB backups are not necessarily as simple as one might think, considering problems suchs as locks, delayed write, and whatever optimizations MySQL can do with its data... Especially if your tables are not using the MyISAM engine.
About the "5 minutes crontab" : you are doing this backup every five minutes ? If your data is that sensible, you should probably think about something else, like replication to another server, to always have an up-to-date copy.