unfortunately I forgot to note down the new password from the last recovery. This means I can't login as root and the init script can't restart it due to not having been updated (sys_maint).
Is there a way for me to fix this, most of the guides I found require you to restart the mysql server, well, doesn't work in my case.
I could kill the process but am I able to start it up again afterwards?
If so I could probably use this way, if it works with mariadb:
http://dev.mysql.com/doc/refman/5.0/en/resetting-permissions.html#resetting-permissions-unix
After spending a few more hours with the issue I tried the one way and it even worked, though I didn't have any access to the database. So in terms of security concerns, well its even official..:
B.5.4.1.2 https://dev.mysql.com/doc/refman/5.0/en/resetting-permissions.html
Related
I had a problem over the weekend. MySQL started giving "Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock'" Error over the weekend.
As suggested, I checked the location of the socket file, and it was in the right spot.
Then I checked the permission of the folders, and they were set to 0755.
Then I checked the disk space and there was plenty of it.
Then I performed a graceful server restart. That was what solved the problem.
My question, with these given, what can be the cause for this issue? This is our production server and I need to do due diligence an get to the root of this to prevent this from happening.
EDIT:
I am not attempting to resolve the issue, I am attempting to investigate the cause.
my.cnf has this set:
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
Thank you.
The last time I ran into this issue, I was able to get around it by setting the host parameter (-h127.0.0.1).
I'm not sure why it worked though, or rather, I'm not sure which specific configuration issues lead to it. Sometimes there can be different mysql.sock files at the same time, or in unexpected places (for example, on my last work machine I accidentally had three instances in different directories).
i need to update listen_addresses in postgres.conf file and want to avoid restart of postgres server process. I tried pg_ctl reload but its not working. Postgres documentation for this parameter says "This parameter can only be set at server start."
http://www.postgresql.org/docs/8.4/static/runtime-config-connection.html#GUC-LISTEN-ADDRESSES
It there any possible way to avoid the restart?
It there any possible way to avoid the restart?
No. That's why the documentation says it may only be set at restart.
If you can't afford the downtime for a simple database restart then you almost certainly need to have a connection pooling and failover system in place anyway. Start planning that so you can introduce it at the same time.
Also, 8.4 is old. If you're restarting a busy system anyway, consider planning an upgrade into the mix. Look at pg_upgrade.
Background: I used to develop using MAMP and over the months/years I've accumulated a large mysql database (a few gigs) that I use for development for my different projects. I finally got around to setting up a VM using Vagrant and I've gotten everything set up and working nicely except my database. I'm running a CentOS 6.5 guest box on an OSX host.
My problem: I need my database to be completely persistent so I can vagrant up/destroy as many boxes as I need to, but the mysql persists.
My solution #1: I initially mounted a synced folder using vboxsf. This works pretty well and seems to be my best option so far, but performance is pretty bad. Query-intensive pages on my dev sites take 1-3 seconds to load whereas they might normally take under a second to load.
My solution #2: I then tried mounting a synced folder using nfs because the performance should be much better. The issue here is that mysql complains b/c, given the nature of nfs, it can't chown the data directory to the mysql:mysql user. I get the following errors when trying to start up the mysqld service:
chown: changing ownership of '/www/mysql': Operation not permitted
chmod: changing permissions of '/www/mysql': Permission denied
Sooo, my question is: are there any better ways to accomplish what I need? I feel like NFS would be the best solution, but I don't know how to get around the whole ownership/permission issues automatically with Vagrant. Any help would be appreciated.
I had the same issue or requirement for my local dev on Mac. And I found a solution for a MySQL-only Vagrant box with external data linked as folder_sync. But it'll run on Win too I guess.
Here is the Vagrant box config: https://github.com/ronnyhartenstein/vagrant-mysql-shared-folder
And if you understand German, here is my blog article with some background infos and tests (and fails of course): http://blog.rh-flow.de/2014/11/11/es-hat-sich-ausgemampft-vagrant-ist/
First of all, let me start with saying this is not best practice. You may know yourself that this can lead to problems if e.g. your PC goes blank or you want to give one project to another person for development. Of course, especially as a one-person-endevour, there are more important things than having test data importers and stuff :) So let's look for solutions.
NFS Permissions
To get NFS permissions right, your users need to have the same UID and GUID on host and guest. It's pretty tricky to setup and you should not change it from the guest. Maybe you can change it on the host to make it writeable to mysql and make UID and GUID the same. Of course, the moment the host changes this won't work anymore.
rsync shared folder
Rsync might not be the fastest in terms of syncing, but if you create on rsync shared folder where only MySQL is writing and which syncs back to some folder on your host this might be a solution. The "real" projects could still live inside a virtualbox share or nfs and you don't need to bother with correct permissions.
There might be some other solutions as well:
Create a backup/restore strategy
One way to go would be to backup MySQL inside your vagrant box at various points, e.g. every day. You could also run the backup when the box is shut down, thus creating a backup right before you destroy the box. Placing this backup at a shared folder, you'd have up-to-date data in case you destroy a box. Performance should be pretty good as the data MySQL is using wouldn't be on a shared folder.
Run MySQL on host or other vagrant box
It's of course possible to connect from within your vagrant box to your host or another vagrant box which runs MySQL. Your host or this box could be long-lived and could serve as a central "MySQL Server" for all your projects.
Have a MySQL slave running on the same machine which writes to shared folder
I believe with MySQL a master/slave combination is possible. Running both on one machine with the master (which you use in your projects) living inside your vm and not writing anything to a shared folder and a slave which writes to your shared folder and is a mirror of your master. This would mean that you have high performance and a few secs of delay between writing something and having it written to your shared folder. Of course, keeping this setup running and making sure it works all the time can be tricky.
You can use bindfs for changing the user/group of a share. I'm actually using a plugin called vagrant-bindfs which let's you remount a share with different ownerships. It works, but i haven't tried it with mysql to see how it performs.
Relevant lines on my Vagrantfile:
unless Vagrant.has_plugin?("vagrant-bindfs")
raise 'vagrant-bindfs is not installed! Please install with vagrant plugin install vagrant-bindfs'
end
config.vm.synced_folder "../", "/temp-nfs-mounts/sites-unbinded", type: :nfs
config.bindfs.bind_folder "/temp-nfs-mounts/sites-unbinded", "/sites", :force_user => "vagrant", :force_group => "vagrant", :create_as_user => true
I need to set ft_min_word_len = 3.
I never restarted my mysql server on my production server. So I fear this moment :).
Are there any way to set ft_min_word_len = 3 without restarting mysql?
And if i must restart it, can you tell me the exact step I have to do?
I am on Devian GNU/Linux
MySQL: 5.0.32
(where I can find where is the mysql configuration file?)
Thanks a lot
No, I'm afraid you need to restart MySQL for it to accept the change. That said, there's nothing to be afraid of, as this won't affect any data. (If you're feeling paranoid, simply carry out the change/restart at an off-peak time, when site traffic is low.)
In terms of the configuration file, I think it lives in /etc/mysql/my.cnf on Debian. (If not, check /etc/my.cnf.)
To restart the service, simply issue a "/etc/init.d/mysql restart" command and all should be well.
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.