=====MySQL=====
[root@1038 bin]# ./mysql_install_db --user=mysql
Installing all prepared tables
041122 20:51:29 /usr/libexec/mysqld: Shutdown Complete
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/bin/mysqladmin -u root password 'new-password'
/usr/bin/mysqladmin -u root -h 1038.flexservers.com password 'new-password'
See the manual for more instructions.
NOTE: If you are upgrading from a MySQL <= 3.22.10 you should run
the /usr/bin/mysql_fix_privilege_tables. Otherwise you will not be
able to use the new GRANT command!
You can start the MySQL daemon with:
cd /usr ; /usr/bin/safe_mysqld &
You can test the MySQL daemon with the benchmarks in the 'sql-bench' directory:
cd sql-bench ; run-all-tests
Please report any problems with the /usr/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 https://order.mysql.com
N.B.: there is a max length of about 17 or 18 characters for MySQL user names! My Unix name campinglachassagne for instance did not properly translate into a MySQL user name (Virtualmin truncates the username automatically).
=====Thursday, november the 25th, 2004=====
Server has come back online after hard disk crash. Flexservers people have fixed it and restored fresh install state.
Up till now, I have reinstalled the iptables-rules.
Situation: we have an Apache2 server, which should be replaced by an Apache1 server to safely work with php in a production environment.
=====MySQL - Part 2=====
It turns out that the standard installation of Plesk on the Flexserver has made a mysql user //admin//, with the same password as the Plesk user //admin//. It also turns out that the Plesk password is stored here:
/etc/psa/.psa.shadow
In a plain text file...
I have added an "ordinary" user //mysql //for use on the webserver:
mysql> GRANT ALL PRIVILEGES ON *.* TO 'mysql'@'localhost'
-> IDENTIFIED BY '************';
This user cannot grant privileges to itself or any other users.
====Dropping databases from MySQL====
After experimenting with several control panels (for webserver administration), I felt the acute need to delete some databases. This is the syntax: ''**DROP DATABASE database_name;**''
But beware! Most of the time, some files remain in MySQL's directory/file structure. Look up ''**/var/lib/mysql/**'' and see if there are any files left in the directory "database_name". Delete any file you may encounter in this directory, then issue the command once more:
mysql> DROP DATABASE example;
Query OK, 0 rows affected (0.00 sec)
====20051130 Starting and stopping MySQL====
The MySQL server is actually a daemon called mysqld. The binary file called mysqld can be found here: ''**/usr/libexec**''.
There is also a shell script called mysqld. So far, I have used this script to start and stop the mysqld daemon. You use these options like this:
/etc/rc.d/init.d/mysqld stop
/etc/rc.d/init.d/mysqld start
If you use the //start //option, the script seems to execute the following command:
/usr/bin/safe_mysqld --defaults-file=/etc/my.cnf >/dev/null 2>&1 &
From the manual:
safe_mysqld adds some safety features such as restarting the server when an error occurs and logging run-time information to a log file.
However, the safe_mysqld command has (surprise, surprise) less options than mysqld itself. For instance, safe_mysqld lacks the ''**--log-update **''and ''**--log-bin**'' options for mysqld. Fortunately, the documentation states:
//Note that all options on the command line to safe_mysqld are passed to mysqld. If you wants to use any options in safe_mysqld that mysqld doesn't support, you must specify these in the option file. //
Now, something has to be done about the mysqld script, because we really need the -''**log-bin **''option (or, if that undocumented option does not work in version 3.23.58, ''**--log-update**'').
===False failure message during startup===
But first, we have to get rid of an annoying thing that has been bothering me ever since I installed MySQL. Whenever you start mysql (''**mysqld start**''), the script will tell you that the startup of MySQL failed, even when it did not. Deleting anonymous users is the cause of this trouble, as is explained in a text derived from [[http://bradthemad.org/tech/notes/mysql_setup.php|http://bradthemad.org/tech/notes/mysql_setup.php]]:
//The startup script /etc/rc.d/init.d/mysqld actually uses the anonymous account when starting the MySQL server to do a "ping" and verify that it has actually started. Removing the anonymous account will cause this check to fail, even though the DB may be up and running fine. To remedy this, edit the script, and make the following edit://
# If you've removed anonymous users, this line must be changed to
# use a user that is allowed to ping mysqld.
#ping="/usr/bin/mysqladmin -uUNKNOWN_MYSQL_USER ping"
ping="pidof mysqld"
====Logging updates to the database====
If you ever feel the need to backup your MySQL database, use mysqldump. It really works wonders, but also produces a lot of data. So, to implement incremental backups you need to log all updates that have occurred since that last full backup. This is where the ''**--log-bin**'' option comes into play. If you start the mysqld daemon with this option, then the database server logs every tiny update into a binary file.
The mysqld shell script, located in ''**/etc/rc.d/init.d/mysqld**'', uses the following configuration file: ''**/etc/my.cnf**''.
In this configuration file, find the ''**[mysqld]**'' section, and add this under it:
log-bin
The actual log files are stored in your MySQL data directory:
[root@1038 mysql]# pwd
/var/lib/mysql
[root@1038 mysql]# ls -l *-bin.*
-rw-rw---- 1 mysql mysql 8675 Nov 30 19:43 1038-bin.001
-rw-rw---- 1 mysql mysql 51191 Nov 30 19:56 1038-bin.002
-rw-rw---- 1 mysql mysql 6487 Nov 30 19:57 1038-bin.003
-rw-rw---- 1 mysql mysql 116623 Nov 30 20:40 1038-bin.004
-rw-rw---- 1 mysql mysql 60 Nov 30 20:26 1038-bin.index
If you do not specify a name for the log files, the host name (in my case 1038) followed by '-bin' is used. To clarify where these files come from, I have given the log-bin files this name:
log-bin=solin01_mysql
===Deleting binary log files===
To delete a specific range of binary log files, you can issue an SQL command:
mysql -uUser -pPassw -e "PURGE MASTER LOGS TO 'solin01_mysql.113'"
This command will delete all binary log files prior to the mentioned log file. You can also delete the files manually, but then the binary index log file will not be updated, so it is safer to use he SQL command.
There is also an option to delete all binary log files prior to a given date, e.g.:
mysql -uUser -pPassw –e "PURGE MASTER LOGS BEFORE now();"
The ''**before**'' syntax is **not** supported however in version 3.23.58.
To delete all log files, issue this command:
mysql -uUser -pPassw –e "RESET MASTER;"
=====Upgrading MySQL 20060415=====
====Preperations====
===Making Backups Using Webmin or MySQLDump===
First of all, I wanted to make absolutely certain that all databases on the current server can be stored in backup files. So I went to the MySQL section of Webmin, which contains an option to back up all databases. I chose to make backups wich, upon restoring the database, drop the existing tables. All backups are in fact text files, containing SQL commands for creating tables and subsequently inserting the data.
This seems like the safest bet, because making binary backups (if possible at all) may leave you stranded if the binary format of the //next// database server is even slightly different.
Just to be on the safe side, I have also dumped the entire database server:
[root@1038 dbs]# mysqldump --all-databases --add-drop-table -u*** -p*** > mysql20060415_1400.sql
As an added beneift, this dump also includes a //create database //statement.
===Restoring Backups===
Should you need to restore the backups:
mysql -u USER -p DBNAME < dump.sql
Please remember to use the correct character encoding. If your database dump was done in UTF8, then you should also tell the mysql client to use UTF8 when restoring the database:
mysql -u USER -p --default-character-set=utf8 DBNAME < dump.sql
===Finding out about dependencies===
Using the ''**rpm**'' tool, I quickly came up with these dependencies:
[root@1038 root]# rpm -e --test mysql-3.23.58-9
error: Failed dependencies:
libmysqlclient.so.10 is needed by (installed) perl-DBD-MySQL-2.9003-4
libmysqlclient.so.10 is needed by (installed) mysql-server-3.23.58-9
libmysqlclient.so.10 is needed by (installed) libdbi-dbd-mysql-0.6.5-8.1
mysql = 3.23.58 is needed by (installed) mysql-server-3.23.58-9
mysql = 3.23.58 is needed by (installed) mysql-devel-3.23.58-9
I am not overly worried about the consequences of an upgrade for, say, the perl module, because I plan to use either ''**rpm**'' or ''**yum**'' to upgrade. These tools will take care of the dependencies, by (re)installing all required packages (I hope).
===Keeping the old version ready for emergencies===
From the MySQL website:
//"If you are cautious about using new versions, you can always rename your old ////**mysqld**//// before installing a newer one. For example, if you are using MySQL 4.0.18 and want to upgrade to 4.1.1, rename your current server from ////**mysqld**//// to ////**mysqld-4.0.18**////. If your new ////**mysqld**//// then does something unexpected, you can simply shut it down and restart with your old ////**mysqld**////."//
This seems like a really good idea. This is the location of all mysqld files:
[root@1038 root]# find / -name mysqld
/etc/logrotate.d/mysqld
/etc/rc.d/init.d/mysqld
/var/run/mysqld
/var/lock/subsys/mysqld
/usr/libexec/mysqld
The only thing left to to, is finding out which one is the "real" mysqld.
===The binaries or rpms===
The MySQL people explicitly tell you to use the binaries, instead of compiling your own MySQL server from source code. So, which rpm do we use? There is no official MySQL 4.0 for Fedora Core 2, so we have the following options:
*using somebody else's Fedora 2 targeted MySQL 4 rpm (assuming we can find one)
*using the "generic" Linux x86 MySQL 4 rpm
As I was unable to find a specific Fedora 2 targeted MySQL 4 rpm, I decided to go with the generic rpm. You can download the latest 4.0 version (4.0.26) here:
[[http://downloads.mysql.com/archives.php?p=mysql-4.0&v=4.0.26|http://downloads.mysql.com/archives.php?p=mysql-4.0&v=4.0.26]]
Or, more orderly presented, here:
[[http://dev.mysql.com/downloads/mysql/4.0.html|http://dev.mysql.com/downloads/mysql/4.0.html]]
And version 4.1.18 here:
[[http://dev.mysql.com/downloads/mysql/4.1.html|http://dev.mysql.com/downloads/mysql/4.1.html]]
===Shared libraries===
Gotta figure this out yet. See:
[[http://dev.mysql.com/doc/refman/5.0/en/linux-rpm.html|http://dev.mysql.com/doc/refman/5.0/en/linux-rpm.html]]
This is something about MySQL-shared-compat needed for RedHat and therefore, presumably, also for Fedora MySQL installations.
This comes down to installing ''**MySQL-shared-compat-4.0.26-0.i386.rpm**''.
====Upgrade target: from version 3.23.58 to at least MySQL 4.1.16====
I had a very specific reason for upgrading: version 1.6 of the Learning Management System //Moodle //needs at least MySQL 4.1.16. And my version was 3.23.58.
With this goal in mind, I set out to see what MySQL version I should install. After all, the latest MySQL version at the time of writing was 5.1, so I had these versions to choose from: 4.0, 4.1, 5.0 and 5.1. Why not go straight to the latest version? Well, the MySQL website advises:
//"that when you upgrade from one release series to another, you should go to the next series rather than skipping a series. For example, if you currently are running MySQL 4.0 and wish to upgrade to a newer series, upgrade to MySQL 4.1 rather than to 5.0 or 5.1."//
So, getting from 3.23.58 to 5.1 would require me to install //four //subsequent upgrades! Therefore, my target was to first get to at least 4.1.16.
===Upgrading from MySQL 3.23 to 4.0===
Let's get down to business. After upgrading, we need to do what's described here:
[[http://dev.mysql.com/doc/refman/4.1/en/upgrading-from-3-23.html|http://dev.mysql.com/doc/refman/4.1/en/upgrading-from-3-23.html]]
This comes down to:
*check startup scripts for deprecated stuff
*convert your old ISAM tables to MyISAM format
*check dependencies
====The actual upgrade – first attempt====
Enough talk already! Let's just do it now:
[root@1038 rpm]# rpm -Uvh --nodeps MySQL-server-4.0.26-0.i386.rpm
warning: MySQL-server-4.0.26-0.i386.rpm: V3 DSA signature: NOKEY, key ID 5072e1f5
Preparing... ########################################### [100%]
1:MySQL-server ########################################### [100%]
Installing all prepared tables
060415 14:15:49 /usr/sbin/mysqld: Shutdown Complete
PLEASE REMEMBER TO SET A PASSWORD FOR THE MySQL root USER !
To do so, start the server, then issue the following commands:
/usr/bin/mysqladmin -u root password 'new-password'
/usr/bin/mysqladmin -u root -h 1038.flexservers.com password 'new-password'
See the manual for more instructions.
NOTE: If you are upgrading from a MySQL <= 3.22.10 you should run
the /usr/bin/mysql_fix_privilege_tables. Otherwise you will not be
able to use the new GRANT command!
Please report any problems with the /usr/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 https://order.mysql.com
[root@1038 rpm]# rpm -Uvh MySQL-shared-compat-4.0.26-0.i386.rpm
warning: MySQL-shared-compat-4.0.26-0.i386.rpm: V3 DSA signature: NOKEY, key ID 5072e1f5
Preparing... ########################################### [100%]
1:MySQL-shared-compat ########################################### [100%]
[root@1038 rpm]# rpm -Uvh MySQL-devel-4.0.26-0.i386.rpm
warning: MySQL-devel-4.0.26-0.i386.rpm: V3 DSA signature: NOKEY, key ID 5072e1f5
Preparing... ########################################### [100%]
1:MySQL-devel ########################################### [100%]
[root@1038 rpm]# rpm -Uvh MySQL-client-4.0.26-0.i386.rpm
warning: MySQL-client-4.0.26-0.i386.rpm: V3 DSA signature: NOKEY, key ID 5072e1f5
Preparing... ########################################### [100%]
1:MySQL-client ########################################### [100%]
Situation after above installations:
[root@1038 rpm]# find / -name mysqld
/var/run/mysqld
/var/lock/subsys/mysqld
/usr/sbin/mysqld
Unfortunately, ''**/etc/rc.d/init.d/mysqld stop**'''' ''does not work anymore, so I had to reboot the system. I probably should have stopped the MySQL server //before// installing the new version...
===Failure===
After the reboot, the mysqld daemon tells me the following:
[root@1038 root]# /usr/sbin/mysqld
Fatal error: Please read "Security" section of the manual to find out how to run mysqld as root!
060415 14:37:27 Aborting
060415 14:37:28 /usr/sbin/mysqld: Shutdown Complete
A web search suggests that I use ''**mysqld_safe**'':
[root@1038 bin]# ./mysqld_safe start
chown: `mysql': invalid user
Starting mysqld daemon with databases from /var/lib/mysql
STOPPING server from pid file /var/run/mysqld/mysqld.pid
060415 14:46:52 mysqld ended
Close. But apparently the mysql user has been deleted. So:
[root@1038 bin]# groupadd mysql
[root@1038 bin]# useradd -g mysql mysql
But unfortunately:
[root@1038 bin]# ./mysqld_safe start
Starting mysqld daemon with databases from /var/lib/mysql
STOPPING server from pid file /var/run/mysqld/mysqld.pid
060415 14:53:49 mysqld ended
====Plunging forward – successfully – to 4.1.18====
Nothing really worked, so I decided to just skip the 4.0 version.
[root@1038 rpm]# rpm -Uvh --nosignature --nodeps MySQL-server-4.1.18-0.i386.rpm
Preparing... ########################################### [100%]
Giving mysqld a couple of seconds to exit nicely
1:MySQL-server ########################################### [100%]
060415 15:48:01 [Warning] Asked for 196608 thread stack, but got 126976
060415 15:48:01 [Warning] Asked for 196608 thread stack, but got 126976
PLEASE REMEMBER TO SET A PASSWORD FOR THE MySQL root USER !
To do so, start the server, then issue the following commands:
/usr/bin/mysqladmin -u root password 'new-password'
/usr/bin/mysqladmin -u root -h 1038.flexservers.com password 'new-password'
See the manual for more instructions.
NOTE: If you are upgrading from a MySQL <= 3.22.10 you should run
the /usr/bin/mysql_fix_privilege_tables. Otherwise you will not be
able to use the new GRANT command!
Please report any problems with the /usr/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 https://order.mysql.com
Starting MySQL. SUCCESS!
And the other rpms:
[root@1038 rpm]# rpm -Uvh --nosignature MySQL-client-4.1.18-0.i386.rpm
Preparing... ########################################### [100%]
1:MySQL-client ########################################### [100%]
[root@1038 rpm]# rpm -Uvh --nosignature MySQL-devel-4.1.18-0.i386.rpm
Preparing... ########################################### [100%]
1:MySQL-devel ########################################### [100%]
[root@1038 rpm]# rpm -Uvh --nosignature MySQL-shared-compat-4.1.18-0.i386.rpm
Preparing... ########################################### [100%]
1:MySQL-shared-compat ########################################### [100%]
===Warning===
The MySQL server is up and running again, but the rpm manager does not seem to know it, even though we installed everything //through //rpm!
[root@1038 rpm]# rpm -q mysql
package mysql is not installed
[root@1038 rpm]# rpm -q MySQL-server-4.1.18-0.i386.rpm
package MySQL-server-4.1.18-0.i386.rpm is not installed
===MyIsam===
//"The //''//ISAM//''// file format still works in MySQL 4.0, but is deprecated and is not compiled in by default as of MySQL 4.1. //''//MyISAM//''// tables should be used instead."//
([[http://dev.mysql.com/doc/refman/4.1/en/upgrading-from-3-23.html|http://dev.mysql.com/doc/refman/4.1/en/upgrading-from-3-23.html]])
I have checked a few random tables in databases created (originally on MySQL 3.23) by Moodle and Typo3. All were of type MyIsam. Us phpMyAdmin to check this, or fire up the mysql client, connect to a specific database, and issue the following statement:
show table status like 'mdl_assignment'
====Starting and Stopping MySQL 20060415====
Apparently, you can start and stop MySQL through:
/usr/bin/mysqld_safe --user=mysql &
/usr/bin/mysqladmin -u root shutdown
I have also used these commands in the Webmin MySQL module.
====Performance issues in MySQL====
Ever since I have installed MySQL 4.1, Moodle is having performance related issues. If more than 20 users log on, the DB server halts. Here are some locations and tools for monitoring MySQL performance. The thing is, I am not really sure if the previous DB installation did not have the same problems: maybe there just weren't that many simultaneous users yet.
The file ''**/etc/my.cnf**'' is used to set MySQL variables. Here is mine (20061002):
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
# Uncomment the following if you want to log updates
log-bin=/var/lib/mysql/backups/solin01_mysql
log_slow_queries=/var/log/mysql_slow_queries.log
long_query_time=10
log=/var/log/mysql_general.log
log-warnings=2
set-variable=max_connections=500
[mysql.server]
user=mysql
basedir=/var/lib
[safe_mysqld]
err-log=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
Note that you should **not **normally log all general MySQL activity, as this log will enlarge very quickly. At the very least, this log should be rotated. General logging corresponds to the ''**mysqladmin variables**'' setting:
| log | ON |
You can see what variables are currently in use by issueing the following command (username and password omitted here): ''**mysqladmin variables**''. Here's a snippet of output:
| log | OFF |
| log_bin | ON |
| log_error | |
| log_slave_updates | OFF |
| log_slow_queries | ON |
| log_update | OFF |
| log_warnings | 2 |
| long_query_time | 10 |
=====MySQL 5=====
After running apt-get install mysql-server, a Debian configuration tool came up with the following notice:
Install Hints
On upgrades from MySQL 3.23, as shipped with Debian Woody, symlinks in place of /var/lib/mysql or /var/log/mysql gets accidently removed and have manually be restored.
MySQL will only install if you have a non-numeric hostname that is resolvable via the /etc/hosts file. E.g. if the "hostname" command returns "myhostname" then there must be a line like "10.0.0.1 myhostname".
A new mysql user "debian-sys-maint" will be created. This mysql account is used in the start/stop and cron scripts. Don't delete.
Please remember to set a PASSWORD for the MySQL root user! If you use a /root/.my.cnf, always write the "user" and the "password" lines in there, never only the password!
See /usr/share/doc/mysql-server-5.0/README.Debian for more information.
The ''**debian-sys-maint**'' user does not seem to exist as a unix user, however, but solely as a MySQL user:
host:/etc/apt# passwd debian-sys-maint
passwd: Unknown user debian-sys-maint
The whole installation output was:
host:/etc/apt# apt-get install mysql-server
Reading Package Lists... Done
Building Dependency Tree... Done
The following extra packages will be installed:
libmysqlclient15off mysql-client-5.0 mysql-common mysql-server-5.0
Suggested packages:
tinyca
The following packages will be REMOVED:
mysql-client-4.1 mysql-common-4.1 mysql-server-4.1
The following NEW packages will be installed:
libmysqlclient15off mysql-client-5.0 mysql-common mysql-server mysql-server-5.0
0 upgraded, 5 newly installed, 3 to remove and 28 not upgraded.
Need to get 30.6MB of archives.
After unpacking 37.1MB of additional disk space will be used.
Do you want to continue? [Y/n] Y
Get:1 http://dotdeb.netmirror.org stable/all mysql-common 5.0.24a-2.dotdeb.0 [40.8kB]
Get:2 http://dotdeb.netmirror.org stable/all libmysqlclient15off 5.0.24a-2.dotdeb.0 [1747kB]
Get:3 http://dotdeb.netmirror.org stable/all mysql-client-5.0 5.0.24a-2.dotdeb.0 [6950kB]
Get:4 http://dotdeb.netmirror.org stable/all mysql-server-5.0 5.0.24a-2.dotdeb.0 [21.8MB]
Get:5 http://dotdeb.netmirror.org stable/all mysql-server 5.0.24a-2.dotdeb.0 [38.1kB]
Fetched 30.6MB in 9s (3065kB/s)
Preconfiguring packages ...
(Reading database ... 16272 files and directories currently installed.)
Removing mysql-server-4.1 ...
Stopping MySQL database server: mysqld.
Removing mysql-client-4.1 ...
dpkg: mysql-common-4.1: dependency problems, but removing anyway as you request:
libmysqlclient12 depends on mysql-common (>= 4.0.24-10sarge2) | mysql-common-4.1; however:
Package mysql-common is not installed.
Package mysql-common-4.1 is to be removed.
libmysqlclient14 depends on mysql-common-4.1 (>= 4.1.11a-4sarge5) | mysql-common; however:
Package mysql-common-4.1 is to be removed.
Package mysql-common is not installed.
Package mysql-common-4.1 which provides mysql-common is to be removed.
libmysqlclient12 depends on mysql-common (>= 4.0.24-10sarge2) | mysql-common-4.1; however:
Package mysql-common is not installed.
Package mysql-common-4.1 is to be removed.
libmysqlclient14 depends on mysql-common-4.1 (>= 4.1.11a-4sarge5) | mysql-common; however:
Package mysql-common-4.1 is to be removed.
Package mysql-common is not installed.
Package mysql-common-4.1 which provides mysql-common is to be removed.
Removing mysql-common-4.1 ...
Selecting previously deselected package mysql-common.
(Reading database ... 16040 files and directories currently installed.)
Unpacking mysql-common (from .../mysql-common_5.0.24a-2.dotdeb.0_all.deb) ...
Selecting previously deselected package libmysqlclient15off.
Unpacking libmysqlclient15off (from .../libmysqlclient15off_5.0.24a-2.dotdeb.0_i386.deb) ...
Selecting previously deselected package mysql-client-5.0.
Unpacking mysql-client-5.0 (from .../mysql-client-5.0_5.0.24a-2.dotdeb.0_i386.deb) ...
Selecting previously deselected package mysql-server-5.0.
Unpacking mysql-server-5.0 (from .../mysql-server-5.0_5.0.24a-2.dotdeb.0_i386.deb) ...
Selecting previously deselected package mysql-server.
Unpacking mysql-server (from .../mysql-server_5.0.24a-2.dotdeb.0_all.deb) ...
Setting up mysql-common (5.0.24a-2.dotdeb.0) ...
Installing new version of config file /etc/mysql/my.cnf ...
Setting up libmysqlclient15off (5.0.24a-2.dotdeb.0) ...
Setting up mysql-client-5.0 (5.0.24a-2.dotdeb.0) ...
Setting up mysql-server-5.0 (5.0.24a-2.dotdeb.0) ...
Installing new version of config file /etc/init.d/mysql ...
Installing new version of config file /etc/logrotate.d/mysql-server ...
Installing new version of config file /etc/mysql/debian-start ...
Stopping MySQL database server: mysqld.
Starting MySQL database server: mysqld.
Checking for corrupt, not cleanly closed and upgrade needing tables.
Setting up mysql-server (5.0.24a-2.dotdeb.0) ...
====Configuration====
The user table held the following information:
mysql> select User, Password from user;
+------------------+------------------+
| User | Password |
+------------------+------------------+
| root | |
| root | |
| debian-sys-maint | ******* |
+------------------+------------------+
My first job was to assign a password to the root user:
host:/etc/mysql# mysqladmin -u root password newpwd
=====Reset MySQL Root Password=====
Not that you would ever forget your MySQL root password of course, but here's how to reset it.
[[http://dev.mysql.com/doc/refman/5.0/en/resetting-permissions.html|How to Reset the Root Password]]. This web page explains two methods. I couldn't get the first one to work, so I'll only document the second one here.
Stop your MySQL server. To do this, find out where your .pid file is located and put the path in the following command (and **do** use these backticks, or it will not work):
host:~# kill `cat /var/run/mysqld/mysqld.pid`
Now, restart the webserver with this command:
host:~# mysqld_safe --skip-grant-tables --user=root
And log in as root:
host:~# mysql -u root
Finally, just issue the SQL commands to reset the password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 3
Server version: 5.0.30-Debian_0.dotdeb.1 Dotdeb Sarge backport
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
mysql> UPDATE mysql.user SET Password=PASSWORD('NewPassword') WHERE User='root';
Query OK, 2 rows affected (0.03 sec)
Rows matched: 2 Changed: 2 Warnings: 0
mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)
=====Import Script for GZipped SQL Files=====
#!/bin/bash
db=$1
user=$2
passwd=$3
if [ "$db" = "" ]; then
echo "Usage: $0 db_name user password"
exit 1
fi
clear
for sql_file in *.sql.gz; do
echo "Importing $sql_file";
zcat $sql_file | mysql --user=$user --password=$passwd $db
done
This script takes all *.sql.gz files in the current directory, unzips them (with zcat) to the standard output, which is redirected (with the pipe symbol |) to the mysql client.
The original files are kept in place (i.e. unzipped).