I have a server running 5 or 6 small Rails apps. All their attached files are on S3 and they all use MySQL as database. Each app has its own user and runs some thins. There is an nginx server doing the load balancing and domain routing.
I plan to replace this server by a Docker installation : one server with one container per app, with a nginx in front.
My question is : where would you put the database part ?
I mainly see 4 possibilities :
1) One Mysql server inside of each app container. This seams not to be Docker's philosophy I think. It would require each container's data to be backuped individually.
2) A unique MySQL container for all apps.
3) A standard MySQL installation on the host Docker server.
4) A separate MySQL server for all apps.
What would you do ?
PS : I know Docker is not production ready yet, I plan to use it for staging at the moment and switch if I'm happy with it.
It depends on several factors. Here are some questions to help you to decide.
Are the 5-6 apps very similar (i.e., in Docker terms, you could base them on a common image), and are you thinking about deploying more of them, and/or migrating some of them to other servers?
YES: then it makes sense to embed the MySQL server in each app, because it will "stick around" with the app, with minimal configuration effort.
NO: then there is no compelling reason to embed the MySQL server.
Do you want to be able to scale those apps (i.e. load balance requests for a single app on multiple containers), or to scale the MySQL server (to e.g. a master/slave replicated setup) ?
YES: then you cannot embed the MySQL server, otherwise, scaling one tier would scale the other tier, which will lead to though headaches.
NO: then nothing prevents you from embedding the MySQL server.
Do you think that there will be a significant database load on at least one of those apps?
YES: then you might want to use separate MySQL servers, because a single app could impede the others.
NO: then you can use a single MySQL server.
Embedding the MySQL server is fine if you want a super-easy-to-deploy setup, where you don't need scalability, but you want to be able to spin up new instances super easily, and you want to be able to move instances around without difficulty.
The most flexible setup is the one where you deploy one app container + one MySQL container for each app. If you want to do that, I would suggest to wait for Docker 0.7, which will implement links, which will let you have a basic service discovery mechanism, so that each app container can easily discover the host/port of its database container.
I wouldn't deploy MySQL on the host; if you want a single MySQL install, you can achieve the same result by running a single MySQL container and running it with -p 3306:3306 (it will route the host's 3306/tcp port to the MySQL container's 3306/tcp port).
Since the 5 or 6 apps are small as you described, I will definitely exclude the option of installing a separate MySQL per container for two reasons:
It is waste of server resources, it is almost equivalent to installing MySQL 5 or 6 times on the same server.
It is less flexible (cannot scale DB independently from the apps) and harder to backup.
Having a dedicated MySQL container or installing MySQL on the host directly (i.e. not dockerizied), should have almost the same performance (at the end you will have a native mysql process on the host regardless if it is in the container or not).
The only difference is that you have to mount a volume to persist the data outside the MySQL
container, so having a dedicated MySQL container is a better option.
Related
Specific Question: In a 2-3 week process of learning MySQL and attempting to get a Python stock info scrapping program to feed data into a MySQL schema (database, table) I’m having serious difficulties with connections. Having been bitten by doing something wrong & having to re-install MySQL about 8 times now, I’m getting rightfully leery of just about everything in the installation process. Thus this question:
Is “Local instance MySQL” which shows up in the upper left corner of the first (black) MySQL Workbench screen the proper one to use to connect to the database?
As a follow-up,
What is the difference between the windows service MySQL57, the connection MySQL57, and Local instance MySQL57?
During the very painful process of trying to get MySQL up and running, I think I've gotten further when with a fresh installation the first screen reads “MySQL57” as opposed to “Local instance …”
My setup parameters are pretty vanilla with the exception that I’m putting the MySQL program on my D: drive as opposed to the C: drive (an SSD reserved for the operating sys).
System: Windows 8 64bit on a Xeon Ivy Bridge processor, large SSD’s, large HD’s, mucho RAM, dual X-fired video cards, ASUS Sabertooth MB (self-built a yr ago)
Software: MySQL 5.7, complete installation except for module for Visual Basic and Python3 (running 2.7). Attempting to use the above hardware as both a server & client.
Even though I did my first Fortran programming in 1964, and spent my career on Unix machines, please regard me as a newbie when it come to the jargon associated with databases and client/server communications.
Why am I asking this question? My “down the road question” will be about getting data from Python into the MySQL table, but “first things first” --- I would like to get a nice clean installation that I can trust.
By the way, I’ve thoroughly scoured this site and many others but have not found any answers that fit my requirements; they’re either for a non-Windows environment, too full of jargon for me to understand, or too simplistic to be useful.
TIA, Doug
Seems there's some confusion about certain terms. So let's have a look at each:
MySQL is a server application that you can install and connect to via
TCP/IP (on any platform), named pipes (on Windows) or sockets (on
*nix like platforms). This server is totally independent and has no name or such for identification.
A Windows service to run the MySQL server: this is just a helper to allow running the server when your machine starts up. A service is not strictly necessary to run a MySQL server but without it you would have to manually start/stop the server. You can create as many service entries for a server as you want, but usually it makes no sense to create more than one. Since there can be more than one server (each with an own service) on the box it is highly recommended to give the services speaking names (like MySQL57 for a 5.7 MySQL server, MySQL56 or a 5.6 server etc.).
MySQL Workbench connections are entries that store parameters to connect to a MySQL server. They are not tied to a specific service in general (you can connect to a non-Windows server too), but might be associated with such a service if they are configured for a local server (on a Windows machine) and you want to be able to start/stop this server from within MySQL Workbench (see Administrator section). They use the service name to act on a particular service (you configure that in the Connection manager, System profile). On Windows MySQL Workbench attempts to find installed service (to help new users to get up and running quicker) when it is started and no connection is currently defined. It then automatically creates a connection for each service it found (it uses "mysql*" as pattern to search for services). You can retrigger this process by removing all connections and restart MySQL Workbench.
The created connnections (like the “Local instance MySQL”) appear as tile you can simply click to open that connection. Be aware that clicking on the rightmost 1/4 of the tile will open an information popup only, not open the connection as such.
Now to your question:
What is the difference between the windows service MySQL57, the
connection MySQL57, and Local instance MySQL57?
I don't understand where you see a connection MySQL57. There's usually only a service MySQL57 and connection in MySQL Workbench to the server this service is for involved.
I'm also not sure why this is such a dreadful process for you. Especially for Windows a lot of effort has been put into an easy installation experience. The normal process should be like:
Download the MySQL Installer
Run the installer. Select a typical scenario from the presets or select the individual products you want to have installed, say, a MySQL server + MySQL Workbench.
The installer will download and install the selected components.
Configure your server (like giving it a proper service name, TCP/IP port etc.).
After finishing the installer you start MySQL Workbench and can immediately work with your new server (as described above MySQL Workbench picks up the service automatically).
Depending on your download speed this should be something like a 5 - 10 mins. process.
HTH
with due respect sir , windows service mysql is a service created by windows upon successful to help you start / stop mysql. You can use Local Instance Mysql57 without a glitch, as that is just a way of MySQL representing your local mysql instance in the workbench.
I'm trying to migrate a web site to friend's server. The site uses MySQL, but he didn't previously have it set up. He's installed the package now and suggested that I could run my own instance of it. I'm at a loss for how to do so. Is it even possible? If so, how?
Some relevant information:
The OS in use is CentOS 5.9
Using MySQL 5.0.95
I only need the DB to be read locally via PHP when serving my site.
I have no root privileges on this system (although a full shell), but am close friends with the owner/administrator if that's necessary.
To clarify:
It's the daemon that I want to run my own instance of. So I guess what I want to know is if it's possible to have multiple users on the system running their own instances of mysqld containing different databases.
All I need this for is serving a web page. If I have to break down and switch to a pseudo-database using CSV files I will, but I'd much rather stick to MySQL if I can.
If MYSQL is setup on that machine yes you can run your own instance of it.
You can have it set up and your site given its on Database within that MYSQL instance and that specific MYSQL account can be used to access the tables etc. involved with your website.
Now if he is only putting MYSQL on the machine then having you set everything up you will just need an account for MYSQL and from ther eyou can get in and just create all the needed items that will allow your site to fully function.
EDIT
In response to your comment. You can you just can't clog the same port or have configurations that conflict each other. As long as it won't be to much of a performance hit and you configure a different user to start each instance you should be able to do Something like this.
I'm building a rails 3.1 app that requires a load of data to be crunched and processed on a local server (using a bunch of non-rails tools and writing to mysql) and then for the refined results to be punted up to a heroku production server (front end). because the data crunching aspect of the process needs to be run in batches, my first instinct was simply to upload the results table to production using something like "heroku db:push --tables data" - but the problem is that it is sslloowww and the app is without data for about 40mins at a time. the crunching batches need to be run about 4x per day - so it looks like this approach isn't really going to work. any suggestions how to speed this process up or any alternative schemes for getting the data less obtrusively up to the production server? thanks!
Sounds like you may have to rearchitect or what about running your rails app on EC2 and ditching Heroku? I think Heroku is great if your app is simple or you can make do with the plugins that they have. But when it gets complex I think it may be too complicated.
Heroku makes it clear that you cannot access their databases from outside. What you can do however is (if you want to stay on Heroku) is to use another database (like the RDS or roll your own) and have your application connect to it. Then upload data to that database directly.
Is it possible to split the instance of a dedicated box to serve mySQL on a seperate host. Example:
www.site.com - ip 192.1.1.1
mysql1.site.com - ip 192.1.1.2
and then I can host mySQL on this seperate subdomain server even do:
$dbhost="mysql1.site.com";
or
$dbhost="mysql1.site.com:3001";
// i dont know how to make ports
I have seen people do this, in once instance have
mysql1.site.com
mysql2.site.com
mysql3.site.com
where mysql1 is copied per 30seconds to 2 and 3, and if 1 fails, 2 and 3 are ready for backup..
Yes, it is fully possible. You have two servers: one runs application, the other runs MySql database. Your application connects to the server running the database. No big deal.
For example on Amazon AWS the usual configuration is to run your application on Amazon EC2 server and your database on Amazon RDS server.
if you need to sandbox mysql on one host then head over to http://mysqlsandbox.net/ not suited for production though so if you have one box and need multiple installations you can look in to virtualization as well
Yes. You can have your mysqld on a different server than the httpd. And, yes, you can set up database replication.
We have a Linux server running Red Hat Enterprise 3 and MySQL 3.23. This server has a number of websites on it.
We have a new website that we want to put on this server that uses MySQL 4/5. Is it possible to run the two versions of MySQL in parallel?
If so, how?
Yes you can. Of course on of the servers would have to use non-standard port number.
See the documentation http://dev.mysql.com/doc/refman/5.1/en/multiple-unix-servers.html
Yes, it's possible, but tricky.
Firstly, it's probably best not to use the RedHat supplied RPMS - they'll cause all sorts of dependency issues.
In essence, all you need to do is to build the two versions, and install them into completely different directories.
Then you need to make sure that they're configured with separate:
data directories
TCP ports
Local connection sockets
PID state files
In practise that can be done my creating two my.cnf files, and making sure those are chosen in the command line parameters in the daemon start up scripts.
Note also that you'll need to be very careful with any shared libraries that might get built, particularly if you're running any client applications on the same server.
This gets nasty if, for example, you want Perl::DBD::mysql running, as it's not simple to arrange for there to be two copies, with each linked against a different version of the shared libraries.