mysql

imcompatibility between mysql V3 libraries on webapp and PHP4 - problem: cannot connect to database

| |

starting phpwebsite:

mysqladmin -u root -p create itacwebdb

mysql -u root -p
mysql> GRANT ALL PRIVILEGES ON itacwebdb.* TO itacwebdba@localhost
IDENTIFIED BY 'somedecentpassword';
mysql> SET PASSWORD FOR admin@localhost=OLD_PASSWORD('thepassword');
mysql> exit

[the database administrator password must be stored in hash format for V3 mysql libraries -- may need to use this if accessed by PHP4 libraries. ]

compiling shib with embedded mysql

|

seems that the problem to compiling shib with the embedded mysql server
is not in the shib configuration but in the mysql_config script
distributed with mysql. this script lists the libraries needed to link
the mysqld embedded server and seems to ommit "-lz" (the compression
library) for the libs needed to link the embedded server. adding this lib
to the shib ./configure script works around this problem. you can simply
do a:

LDLIBS=-lz ./configure ...

This seems to be a problem with the 4.1.10 mysql rpm from mysql.com and
doesn't fix itself even when I build the rpm locally.

can't compile test code for embedded mysql

|

[phpwiki]
have had no luck with the test code and can't figure out why it's failing.
google doesn't seem to be of help. mysql.com doesn't seem to indicate any
problems with mysql embedded. and my test embedded build absolutely
refuses to link. if i do the build/link in one step i get an undefined
function mysql_server_init, if I do it in two steps I get complaints about
references to compress which I can't figure out how to resolve.

there doesn't seem to be anything special about linking the embedded db
according to the docs. the only diff between embedded and non-embedded is
that mysql_init_server() is not an empty stub in the embedded version.

n/a

backing up mysql databases

Backing up a mysql databes is pretty easy. In the simplist case, you can just backup the files that make up the database. Ideally you want to lock the tables first so other processes don't change the data (mainly indexes) while your doing the backup. It's ideal just to lock the database you are interested in but you can be broad and lock all the databases for now. We don't have a lot of simultanous access or independent databases for now, so locking them all should not do much harm. Once they are locked you can backup the database files of interest using tar. When you are done, remember to unlock the database.

Syndicate content