Hi everyone,
I have recently installed MySQL 4.0.13 on a freebsd box, and I have
stumbled into the following problem:
I have set the following in /etc/my.cnf:
set-variable= max_connections=100
set-variable= wait_timeout=60
(tried with and w/o 'set-variable ='). Then I restar
the capability to specify the my.ini file to read on startup
> under " my.ini Setup "
> hth,
> Martin
> - Original Message -
> From: "Bogdan TARU" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, July 21, 2003 6:37 AM
> Sub
Hi guys & gals,
Tried to get an answer through the manual, but couldn't find one. So, is
there a way to do replication w/o stopping the master. The only way I
found up until now was to stop the master (in order to insure there are no
changes to the database), copy the database directory,
Hi guys,
I've got a weirdo problem with replicating a database. Sometimes I get
some duplicate keys problems for _only_ one table. There is nothing
special about this table, it looks like:
+--+--+--+-+-++
| Fiel
Hello,
I recently upgraded the MySQL server from 4.0.15 to 4.1.7, without
significant problems. But I continued to use PHP-4.3.9 linked against
the old MySQL 4.0.15 on the webservers for some time. Everything went
ok, up until the point when I tried linking PHP-4.3.9 against
MySQL-4
Hi everyone,
So, back to the problems with auto_increment columns and replication
problems. I have noticed this problem always occures when using INSERT
SELECT syntax with an auto_increment key
simple example:
CREATE TABLE test1 (value INT);
INSERT INTO test1 SET value=1;
INSERT INTO t
7 Sep 2003, Victoria Reznichenko wrote:
> Bogdan TARU <[EMAIL PROTECTED]> wrote:
> >
> > So, back to the problems with auto_increment columns and replication
> > problems. I have noticed this problem always occures when using INSERT
> > SELECT syntax with an aut
Hi,
I am running MySQL 3.23.41 on a FreeBSD 4.4, and I experience very high
loads of the machine, without any apparent reason. We have a new project
using this MySQL engine, with lots of inserts/deletes. But it happens that
in the mornings, when nobody makes any kind of access to the data
