The logical place to begin in discussing how to administer a MySQL installation is to look at the eco system in which that MySQL installation is going to live. So MySQL is a client server system and we're going to review that just a little bit and take a look at some of the parts of this client server aspect of the MySQL installation that we've installed. First though it's a good idea to look over some terminology just to make sure we're all talking the same language here. So we're going to define two terms here, server and client. The server is a specific program called MySQL D, the D stands for daemon or daemon however you want to pronounce it, daemon. But that means servant in Latin and that's what it is doing. That's what is job is, it's there for us, it's there to respond to our requests. So the MySQL server, MySQL D is simply running the background waiting for someone to ask it to do something. Now this is the core program in our database system and it is the only file, the only program that touches the data directly. So this is the program that we send all of our requests to and it then sends the results back to us. But we don't talk to it directly generally, instead we use one of a number of client programs, many of which are designed for doing very specific kinds of things. And we use those as our agent or our representative or our avatar for communicating with the server. Because it knows how to translate our requests into a language that the server understands and can respond to. So it communicates with the server on our behalf using a valid communications protocol. Okay. Let's take a look at a little schematic diagram of how this might go about. So here is my version of an icon for the MySQL server, Sequila the dolphin is the icon for MySQL and I'm trying to indicate that it's being served in some way. If we look at where it resides the MySQL server resides on a specific piece of hardware that we call the host machine for that MySQL server. Notice that I will not use the word server to talk about the hardware here. I know we do that in other ways but that just gets confusing. So for us the server is this program and it's living on a host machine that we can refer to internally as local host. That's a common thing in the Unix environment but even Windows has adopted that now so universally we can talk about this running on local host. And there may be other processes running on local host as well that want to communicate with the server. For example we might have a PHP process that's working along with an Apache web server or some other program but this PHP process knows how to talk the MySQL server. And we may give it some commands that we want the server to carry out for us and notice here that we have it communicating with the server on a specific protocol, TCP/IP. Now that's a very common thing to use, we can use that on any of the platforms. It is the default communications protocol by the way for intra process communications on a Windows machine. It's not the default on any of the Unix's including Mac OS X but it's easy enough for us to set it up to, to communicate on that protocol. Now maybe we also want to use a Command Line program and perhaps we're on one of the Unix systems. Well we might want that to communicate with the default protocol which is a Unix Socket File. And so we're just doing this communication. In that case we don't have to worry about what the port number is, the port number is something that's specific to TCP/IP. Or maybe we're working on a Windows machine and we've decided that we want to make a, a quick backup, a text backup of some of our tables. So we're going to use the MySQL Dump program and we've decided that we want to turn off network access, the TCP/IP isn't going to work for us. Instead we have two choices there, we can either use named pipes as I'm doing here or we can use another protocol called Shared Memory. Either of those will work just fine when TCP/IP access is turned off. Now so far we've talked about other processes that are communicating with our server on the same host machine. But there can be many other kinds of machines that want to communicate with our MySQL server and, and programs running on them. And you'll notice one recurring theme here, there's one protocol that they all use which is TCP/IP. We need to use that for communicating across the network or across the Internet to this process running on this specific host machine if our client is coming from another host. That's the only choice that we have here. Now yes we could SSH into this machine but then we're acting as though we're on the local machine in the first place. So that would still be considered local host access. But if we don't have local host access and we want to communicate directly with the server from a remote client host, then we have to use TCP/IP. Okay. That's at least the basics, we'll look at these things in more detail as we go through the course. The next thing I want to look at is a little schematic diagram about the internal organization of the MySQL server and the resources that it uses. But that's going to have to wait until the next lesson.
| Course: | MySQL 5 Administration-Part 1 |
| Author: | David Swain |
| SKU: | 34307 |
| ISBN: | 978-1-61866-086-2 |
| Release Date: | 2012-12-31 |
| Duration: | 16 hrs / 171 lessons |
| Work Files: |
Yes |
| Captions: | No |
| Compatibility: |
Vista/XP/2000, OS X, Linux QuickTime 7, Flash 8 |