--- doc/build/Attic/loncapasqldatabase.html 2001/02/10 18:38:37 1.4 +++ doc/build/Attic/loncapasqldatabase.html 2001/02/12 17:32:15 1.5 @@ -8,13 +8,13 @@ Scott Harrison
-Last updated: 02/10/2001 +Last updated: 02/12/2001
This file describes issues associated with LON-CAPA and a SQL database.
-
I am going to begin documentation by inserting what notes I have into this file. I will be subsequently rearranging @@ -39,7 +39,7 @@ current status of everything is that it been minimally tested, but things need to be cleaned up and checked again!
-Right now, a lot of "feasibility" work has been done. Recipes for manual installation and configuration have @@ -70,7 +70,7 @@ to the point of getting this SQL softwar however there may be more optimal approaches than currently exist.
-LON-CAPA is meant to distribute A LOT of educational content to A LOT of people. It is ineffective to directly rely on contents @@ -131,7 +131,7 @@ THE SOLUTION: processes (lonsql's) handle the MySQL database manipulations.
-Installation of the LON-CAPA SQL database normally occurs by default when using the LON-CAPA installation CD @@ -160,7 +160,7 @@ from source or pre-compiled file listing actual MySQL functionality on the system
-The following set of tarballs was found to work together properly on a LON-CAPA RedHat 6.2 system: @@ -174,13 +174,13 @@ properly on a LON-CAPA RedHat 6.2 system Installation was simply a matter of following the instructions and typing the several "make" commands for each
-Not yet developed. This will be part of an interface present on LON-CAPA systems that can be launched by entering the command /usr/sbin/loncapaconfig.
-This is not complete.
@@ -215,124 +215,9 @@ FLUSH PRIVILEGES; Copy support-files/mysql.server to the right place on the system (/etc/rc.d/...). --Not yet documented or formalized. -
--
- --
-start the mysql daemon as /usr/local/bin/safe_mysqld & -Login as root: mysql -u root -p mysql -enter the password as newmysql -add the user www: grant all priveleges on *.* to www@localhost identified by 'newmysql' with grant option; - -INSERT INTO user (Host, User, Password) -VALUES ('localhost','www',password('newmysql')); - -GRANT ALL PRIVILEGES ON *.* TO www@localhost; - -FLUSH PRIVILEGES; - -Here the user www has the right to grant privileges to other users. -This can be changed if required with a simple update command on the grant tables - - -/home/httpd/perl/perlsql/lonsql -/usr/local/mysql/fakeclient -- -
-
-This is the output from scripts/mysql_install_db... -still some todo things (like support-files/mysql.server) - -Creating db table -Creating host table -Creating user table -Creating func table -Creating tables_priv table -Creating columns_priv table - -To start mysqld at boot time you have to copy support-files/mysql.server -to the right place for your system - -PLEASE REMEMBER TO SET A PASSWORD FOR THE MySQL root USER ! -This is done with: -/usr/local/bin/mysqladmin -u root password 'new-password' -See the manual for more instructions. - -Please report any problems with the /usr/local/bin/mysqlbug script! - -The latest information about MySQL is available on the web at http://www.mysql.com -Support MySQL by buying support/licenses at http://www.tcx.se/license.htmy. -- -
+The Perl API
-August, 29 2000; Scott Harrison; LON-CAPA - -These are notes related to a Perl interface and MySQL server installation -on Redhat 6.1 and 6.2 boxes. (Guy Albertelli and Harsha Jagasia -contributed significantly to this.) - -******************** -* MySQL COMPONENTS * -******************** - -There are three components to an effective MySQL installation for the -LON-CAPA system. - -Perl::DBI module- the API "front-end"... - database interface module for organizing generic - database commands which are independent of specific - database implementation (such as MySQL, mSQL, Postgres, etc). - -Perl::MySQL module- the API "mid-section"... - the module to directly interface with the actual - MySQL database engine - -MySQL database engine- the "back-end"... - the binary installation (compiled either from source - or pre-compiled file listings) which provides the - actual MySQL functionality on the system - -RedHat Installation- - -Initially done from source: -DBI-1.13.tar.gz Msql-Mysql-modules-1.2209.tar.gz mysql-3.22.32.tar.gz - -I am now using pre-compiled file listings. - -There were problems with using the RedHat packages since the three -different RedHat packages were somewhat noncompatible with each other -in terms of expected file locations. (The Debian linux distribution, -on the other hand, has a working set of these packages). - -Regardless of how we install these three components, there still remain -certain things which need to happen for the configuration. - -***************** -* CONFIGURATION * -***************** - -(Note: SOMEPASSWORD is actually set to another text string on the current -LON-CAPA systems.) - -Configuration is needed to generate the necessary functionality for the -MySQL system with LON-CAPA. - -The functionality needed can be understood from this example line -of perl code from "lonsql". - $dbh = DBI->connect( "DBI:mysql:loncapa", "www", "SOMEPASSWORD", @@ -395,56 +280,28 @@ FLUSH PRIVILEGES; ** ABILITY for LON-CAPA machines to communicate with SQL databases on other LON-CAPA machines -This is a little more intricate than might first be expected (and I probably -won't do a perfect job reciting everything in this short synopsis). Because -LON-CAPA machines will likely be handling many SQL requests at a time, -there were some problems with current MySQL capabilities. - -PROBLEM SITUATION: - - If Server A wants data from Server B, Server A uses a lonc process to - send a database command to a Server B lond process. - lonc= loncapa client process A-lonc= a lonc process on Server A - lond= loncapa daemon process - - database command - A-lonc --------TCP/IP----------------> B-lond - - The problem emerges that A-lonc and B-lond are kept waiting for the - MySQL server to "do its stuff", or in other words, perform the conceivably - sophisticated, data-intensive, time-sucking database transaction. By tying - up a lonc and lond process, this significantly cripples the capabilities - of LON-CAPA servers. - - While commercial databases have a variety of features that ATTEMPT to - deal with this, freeware databases are still experimenting and exploring - with different schemes with varying degrees of performance stability. - -THE SOLUTION: - - A separate daemon process was created that B-lond works with to - handle database requests. This daemon process is called "lonsql". - - So, - database command - A-lonc ---------TCP/IP-----------------> B-lond =====> B-lonsql - <---------------------------------/ | - "ok, I'll get back to you..." | - | - / - A-lond <------------------------------- B-lonc <====== - "Guess what? I have the result!" - - Of course, depending on success or failure, the messages may vary, - but the principle remains the same where a separate pool of children - processes (lonsql's) handle the MySQL database manipulations. +An up-to-date lond and lonsql. ++ +
+
+** TEST the database connection with my current tester.pl code +which mimics what command will eventually be sent through lonc. +$reply=reply( + "querysend:SELECT * FROM general_information WHERE Id='AAAAA'",$lonID); ++ +
Here are excerpts of code which implement the above handling: - -**LONSQL - +
++
+**LONSQL A subroutine from "lonsql" which establishes a child process for handling -database interactions. +database interactions. sub make_new_child { my $pid; @@ -536,14 +393,19 @@ sub make_new_child { exit; } } - -** LOND enabling of MySQL requestsw - - This code is part of every lond child process in the way that it parses command request syntax - sent to it from lonc processes. querysend corresponds to B-lonc sending the result of the query. - queryreply corresponds to B-lond indicating that it has received the request and will start the - database transaction (it returns "ok" to A-lonc ($client)). - + ++** LOND enabling of MySQL requests +
+This code is part of every lond child process in the +way that it parses command request syntax sent to it +from lonc processes. Based on the diagram above, querysend +corresponds to B-lonc sending the result of the query. +queryreply corresponds to B-lond indicating that it has +received the request and will start the database transaction +(it returns "ok" to +A-lonc ($client)). +# ------------------------------------------------------------------- querysend } elsif ($userinput =~ /^querysend/) { my ($cmd,$query)=split(/:/,$userinput); @@ -563,14 +425,8 @@ sub make_new_child { print $client "error:$!\n"; } - - -** TEST the database connection with my current tester.pl code which mimics what command will eventually be - sent through lonc. - -$reply=reply( - "querysend:SELECT * FROM general_information WHERE Id='AAAAA'",$lonID);+