MySQL Problems

* MYSQL WON’T START OR STOP?:

=============================

You may never ever delete the special mysql user “debian-sys-maint”. This user

together with the credentials in /etc/mysql/debian.cnf are used by the

init scripts to stop the server as they would require knowledge of the

mysql root users password else.

So in most of the times you can fix the situation by making sure that

the debian.cnf file contains the right password, e.g. by setting a new

one (remember to do a “flush privileges” then).

* WHAT TO DO AFTER UPGRADES:

============================

 – running mysql_fix_privileges_tables to be able to make use of

   possibly added new privilege columns. This script does not give

   any use more rights.

* WHAT TO DO AFTER INSTALLATION:

================================

The MySQL manual describes certain steps to do at this stage in a separate

chapter.  They are not necessary as the Debian packages does them

automatically.

The only thing that is left over for the admin is

 – setting the passwords

 – creating new users and databases

 – read the rest of this text

* SSL/TLS SECURE NETWORKING:

============================

Please take a look at my SSL-MINI-HOWTO.txt which is in this directory, too.

* NETWORKING:

=============

For security reasons, the Debian package has enabled networking only on the

loopback device using “bind-address” in /etc/mysql/my.cnf.  Check with “netstat

-tlnp” where it is listening. If your connection is aborted immediately see if
“mysqld: all” or similar is in /etc/hosts.allow and read hosts_access(5).

* WHERE IS THE DOCUMENTATION?:

==============================

As the documentation is under a different licence than the rest of MySQL it

had to be separated into the mysql-doc package which is in the non-free branch

of Debian. You can find the Changelogs/News there, too.

* PASSWORDS:

============

It is strongly recommended to set a password for the mysql root user

(which is NOT the same as the “normal” root user) with the command:

 /usr/bin/mysqladmin -u root password ‘enter-your-good-new-password-here’

If you already had a password set add ” -p ” before “-u” to the line above.

If you are tired to type the password in every time or want to automate

your scripts you can store it in the file $HOME/.my.cnf. It should be

chmod 0600 (-rw——- username username .my.cnf) to ensure that nobody

else can read it. Every other configuration parameter can be stored

there, too. You will find an example below and more information in the

MySQL manual in /usr/share/doc/mysql-doc or www.mysql.com.

ATTENTION: It is necessary, that a .my.cnf from root always contains a “user”

line whereever there is a “password” line, else, the Debian maintenance

scripts, that use /etc/mysql/debian.cnf, will use the username
“debian-sys-maint” but the password that is in root’s .my.cnf. Also note,

that every change you make in the /root/.my.cnf will affect the mysql cron

script, too.

        # an example of $HOME/.my.cnf

        [mysql]

        user            = your-mysql-username

        password        = enter-your-good-new-password-here

        [mysqladmin]

        user            = your-mysql-username

        password        = enter-your-good-new-password-here

* BIG_ROWS FOR EVEN MORE ROWS IN A TABLE:

=========================================

If you ever run out of rows in a table there is the possibility of building the

package with “-DBIG_ROWS” which, according to a MySQL employee on

packagers@lists.mysql.com should leat to a 64bit row index (I guess > 2^32 rows)

but also to an aprox. 5% performance loss.

Related Posts

Postgres: Copy a database

simple

November 17, 2012

Databases, Postgres

No Comment

For backup and development reasons a copy of a postgres database on the same system is often used. This is not a big problem and can be done directly as a SQL statement: [crayon-5a669167ee0ca612942092/] in your favorite console (psql, pgadmin, etc). There is one thing to remember, if you do a template copy this can […]

Read More

Oracle: Timeout idle or dead sessions

Lately in a project we had a lot of problems with idle database sessions. It turns out that the DBA did not configure any timeout for the oracle database for idle or dead sessions. This is done with the PMON process, and via SQL*Net, by the sqlnet_expire_time parameter. SQL*Net In your sqlnet.ora file add the […]

Read More

Leave a Reply