I am trying to setup a django website on EC2, basically I want to start MySQL server, and Uwsgi after reboot.
In order to make MySQL start on reboot, I did:
sudo cp /opt/mysql/server-5.6/support-files/mysql.server /etc/init.d/
sudo update-rc.d mysql.server defaults
In order to make Uwsgi start on reboot, I created a file /etc/init/uwsgi.conf:
description "ubuntu uwsgi instance"
start on runlevel [2345]
stop on runlevel [06]
exec uwsgi --ini /home/ubuntu/uwsgi.ini
However the problem is that I will need mysql to start first, right now it looks like Uwsgi starts first, and tried to connect to mysql, which fails, and mysql never gets started.
Could anyone help me on how to solve this issue?
Thanks in advance
When your computer starts up, it doesn't run the init.d scripts directly. Instead, depending on what's called the "runlevel", it runs the scripts in /etc/rcN.d (where N is the runlevel). You can determine the current runlevel with the runlevel command; mine returns 2 in normal operation. That means that when the computer started up, it ran the scripts in /etc/rc2.d. The contents of rc2.d are just symlinks to scripts in /etc/init.d, named according to whether they should be started or stopped, and the order they should be run.
Use the runlevel command to find out what runlevel your computer is at (probably 2), then look in /etc/rc2.d for a link named smthing like uwsgi, which will be a symlink to /etc/init.d/uwsgi, and rename it to zzz999 - or whatever it takes to get it to sort after the other entries - that will cause it to run last.
There's more information about init.d scripts and runlevels at https://www.linux.com/news/enterprise/systems-management/8116-an-introduction-to-services-runlevels-and-rcd-scripts
Even if you start MySQL before uWSGI you're not assured it will be available when uWSGI is managing requests.
At start MySQL does some checks on database, loads InnoDB indexes, recover from transaction log or it may even hang.
You shouldn't rely on that approach.
Instead add application logic that ensures you correctly handle unavailability of database, i.e. retrying or showing an error page to the user asking to retry.
Related
im trying to restart my mysql server. The server is on a Kubernetes/fedora container. I have tried to use # /etc/init.d/mysqld restart and # systemctl restart mysqld. The problem is that there is no files in the init.d.
When running # /etc/init.d/mysqld restart bash says No such file, obviously as there is no such file. When running # systemctl restart mysqld it responds "bash: systemctl: Command not found"
The mysql-servier is running fine and i can log into it, however i cant restart it. Please help.
To restart a server on Kubernetes you simply need to delete the pod with kubectl delete pod <id>. If you didn't create pod manually, but rather with a deployment, it will restart and come back online automatically.
Deleting a pod is a correct way of shutting down servers. First Kubernetes will send mysql a TERM signal that will politely ask it to shutdown. Then after some time (configurable) it will shoot it with KILL if it doesn't comply.
The mysql-servier is running fine and i can log into it, however i cant restart it.
You have 2 options and both have it's 'dangers' to address:
More likely, container is started with either CMD given in docker image or command directive in kubernetes manifest that is actually starting your mysql. In that case, regardless of the way you manage to do termination (during restart) of running instance of mysql on that container you will also - terminate the whole container. Kubernetes will then restart that container, or whole pod.
Less likely, but possible is that container was started with some other 'main' command, and mysql is started as part of a separate script. In that case inspecting docker file or kubernetes manifest will give you details about start/stop procedure and only in that case you can restart mysql without actually killing the container it is running onto.
Dangers: data persistence. If you don't have proper data persistence in place killing running container (either through restart or refresh) will also destroy any ephemeral data with it.
Additional note: have you tried service mysql status and service mysql restart?
When I run mysqld, it has a whole lot of information about what it's doing.
As I understand, this is not the correct way to run a mysql server and you should use service mysql start instead (on older servers at least).
Any searches for mysqld log come up with logs for queries, I want to know what the program is doing as it starts. (I'm trying to set up mariadb 10.1.14 with galera replication)
I want to be able to run service mysql start and then watch what's happening in the background.
I have a problem, where my shutdown runlevel MySQL bash scripts are not executed. rcS.d, however works always.
I used scripts in init.d folder to be run on different runlevels. Currently, the only one I have gotten to work, is the bash script that inserts a row about the server booting up.
The problem is, that when I use the same method to run a script while the runlevels are 0 or 6, for example, the script is never run. I think it might be a priority issue. Look at the picture below (The priority is the same as the kill priorities for apache, etc...). Are the scripts run in alphabetical order or could I bump all priorities up by one somehow?
I'm guessing the problem is that the services are killed before the script is run - apache killed # 1 & mysql killed # 2. The same script works for booting up - a bash mysql insert command in the file.
Over the weekend I started having all kinds of problems with mysql. I upgraded to Yosemite a while ago and was able to get mysql working. But all of a sudden, my computer is shutting down when I put it to sleep, and when I turn it on in the morning, mysql won't start.
In order to fix this over the weekend, I reinstalled mysql via homebrew, which also required porting over my data/ files and updating the permissions correctly – kind of a pain. I'd rather not do that again.
When I try to restart mysql from the command line I get (There is no shsair.local.pid file btw):
ERROR! The server quit without updating PID file (/usr/local/var/mysql/shsair.local.pid)
I eventually got things to work by updating my.cnf to include:
innodb_force_recovery = 6 (I have no idea what that does or if I should keep it)
But just to see if it was working or not, I tried to start and stop mysql with:
mysql.server stop
and it just hangs. I see this same behavior if I try to restart the computer (it hangs for a long time before shutting off, and I assume because it's trying to shut down mysql.
I'm up for trying any changes to configurations, but it is very important I keep the data/ files as I have years of database work in there.
Thanks!
On my server two websites are hosted (say abc.com and test.xyz.com)
I was trying to rebuild the DB for test.xyz.com and in the process
1.I dropped the database related to it.
2.stopped the mysql ( /etc/init.d/mysqld stop)
3.moved ibdata1 file (/var/lib/mysql/ibdata1) to /tmp/
4. tried to start the mysql
but it is not getting started and on trying to connect to database using terminal, i am getting Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock'.
I tried to move back ibdata1 file from /tmp/ to /var/lib/mysql but there was already a file ibdata1. Its a wonder but now website is not working since NO DB connection.
Both the sites stopped working now. Please help
and-
/etc/init.d/mysqld status gives - mysqld (pid 31905) is running...
Thanks
Quick fix:
Stop your server
Delete the newly created ibdata1 file in /var/lib/mysql. This file is created automatically when it doesn't exist. Also note, it most likely contains the data for all your databases on the server.
Copy the ibdata1 from your tmp folder back to /var/lib/mysql
Start server again
I'll explain later, when I have more time, but I think it might be urgent for you to have that quick fix :)
UPDATE: (From comments) You can't connect, okay, the cause for this could be anything. I think the best thing to do (you don't have much to loose anyway) is you simply kill mysql.
Do
ps aux | grep mysqld
Then
kill -9 <the processnumber of mysql from the previous command>
Then do as I said earlier. And never ever simply move ibdata1 again :)
Also I'm voting to close as offtopic. Then it's going to be moved to dba.stackexchange.com which is a partner site that is more dedicated to administrating database servers. You might get better help there.