Using the issue tracker 4.0.4 package, it broke with no error indication.
Using phpmyadmin indicates #1030 - Got error 127 from storage engine
on the issues table.
I'm guessing it's a mysql corruption.
Can anyone confirm ?
How can I fix it ?
Is there any known issue which could cause it ?
Cross-posted to VAMP
Thanks,
Chris
Chris Sharman wrote:
> Alpha VMS 7.3-1, Apache 2.0, php 4.3.2, mysql 4.1.9,
> php_msql client 3.23.49
<most of OP snipped>
>
> Cross-posted to VAMP
^^^^ Is this a NNTP group,
and if so what is its full name, pretty please.
>
> Thanks,
> Chris
>
Thanks,
Mike
Possible database corruption, have you tried repairing the table,
REPAIR TABLE <table-name>
Ref,
http://www.databasejournal.com/features/mysql/article.php/10897_3300511_2
No.
Meant to post it, sorry.
http://www.issinoho.com:8080/phpbb2/index.php
New & quiet at present, but hopefully will become a useful resource.
Chris
Mike, try this,
http://www.issinoho.com:8080/phpbb2/
Thanks for that - repaired, but lost 9 out of 12 rows - this is only a
test table at present, but that data loss doesn't encourage me to use
this in earnest - is mysql usually this unreliable ?
This is about the first day the database has been tried out by more than
one user.
Thanks, Chris
VAMP has been running flawlessly for months now; I've also used MySQL
both on Linux & Windows and have never encountered corruption or loss.
You may just be unlucky :-(
For the record, VAMP is running on 4.1.8, perhaps (9) has some issues;
maybe you could backfit (8) if you continue to have a problem.
Chris S. & issinoho
Thanks for the pointer.
Mike.
That's something - what sort of usage are you seeing ?
My installation was ok until yesterday, when I rolled issue-tracker out
from me personally to 3/4 other users - and one of them entereed some
data at more or less the same time as me.
I wonder if it relates to the version discrepancy between mysql server &
the php mysql client - although I see from php/php_info.php that you're
running a nearly identical config to mine.
I also get this warning from phpMyAdmin:
"The mbstring PHP extension was not found and you seem to be using
multibyte charset. Without mbstring extension phpMyAdmin is unable to
split strings correctly and it may result in unexpected results."
As I don't seem to have an mbstring extension (I assume the VMS port
doesn't have it), and I'm not aware of any non-ascii character
requirements (on our UK English site) I've been ignoring it.
Thanks
Chris
I also have the mbstring comment in phpmyadmin.
->Thanks for that - repaired, but lost 9 out of 12 rows - this is only a
->test table at present, but that data loss doesn't encourage me to use
->this in earnest - is mysql usually this unreliable ?
->This is about the first day the database has been tried out by more than
->one user.
I've seen this (the dreaded 127 error) as well with a PHP application
written by a completely inexperienced non-programmer (which of course
shouldn't matter). Yet MYSQL has run for weeks reliably as the backend
(no php) for RT - a far more complex and intense application (see
http://www.bestpractical.com/rt/) with just one little problem:
SELECTING or INSERTING TEXTLONG columns (fields) longer than 65021 bytes
(which RT uses for column content in it's attachment table) will
result in:
ERROR 2027: Malformed packet
or
ERROR 2013: Lost connection to MySQL server during query
This occurs when either the client or server is vms (7.3-2
TCP5.4-ECO2) and the request traverses a network. When both client and
server are vms, all is well. It's not yet clear if this is a mysql
problem.
--
-- Carl Karcher, Waisman Computing Services, Waisman Center, UW-Madison
-- karcher.n...@waisman.wisc.edu
> Alpha VMS 7.3-1, Apache 2.0, php 4.3.2, mysql 4.1.9,
> php_msql client 3.23.49
>
> Using the issue tracker 4.0.4 package, it broke with no error indication.
> Using phpmyadmin indicates #1030 - Got error 127 from storage engine
> on the issues table.
>
Which storage engine have you used?
Only Innodb work correctly, MyISAM is know to have some problem.
Anyway ony Innodb support transaction, so I strongly suggest to only use
this storage engine, this is the default on OpenVMS and probably in
future MySQL version.
> I'm guessing it's a mysql corruption.
> Can anyone confirm ?
> How can I fix it ?
> Is there any known issue which could cause it ?
>
> Cross-posted to VAMP
>
> Thanks,
> Chris
>
Jean-François
Innodb is the default, right ? I didn't change it. [vms]my.cnf has lines
relating to innodb, and the rest are commented out. I didn't make any
changes.
I wondered about skip-networking & safe-updates, but didn't turn them
on, since I didn't really understand the implications. Should I ?
But the repair article I saw said it was only for MyISAM - which may be
why it didn't repair innodb that well, I suppose.
Thanks,
Chris
Right, Innodb is the default, but you can specify when you create a
table which storage engine you want to use for this table.
You can use
mysql> show table status like 'my_table';
to check which storage engine is used.
You've guessed it JF - every table in every db has engine MyISAM, not
innodb. That could be my problem, I guess. But I haven't created
anything myself - I just ran the setup stuff I was told to run for
mysql, and then for issuetracker - is there some way to check/change the
default ? Some way to change (unload/drop/create/reload) existing tables
& dbs ? Would it give the applications any problems, or would the
changes be transparent ?
Thanks,
Chris
You've guessed it JF - every table in every db has engine MyISAM, not
innodb. That could be my problem, I guess. But I haven't created
anything myself - I just ran the setup stuff I was told to run for
mysql, and then for issuetracker - is there some way to check/change the
default ? Some way to change (unload/drop/create/reload) existing tables
& dbs ? Would it give the applications any problems, or would the
changes be transparent ?
Thanks,
Chris
>> I wondered about skip-networking & safe-updates, but didn't turn them
For the record, VAMP is using InnoDB, however some other databases
within my MySQL installation are in fact MyISAM. Now I haven't
explicitly set the engine type at any point, so I can only conclude that
the SQL script that creates the database is specifying it.
> Chris Sharman wrote:
>
>> Jean-François Piéronne wrote:
>>> Which storage engine have you used?
>>>
>>> Only Innodb work correctly, MyISAM is know to have some problem.
>>> Anyway ony Innodb support transaction, so I strongly suggest to only
>>> use this storage engine, this is the default on OpenVMS and probably
>>> in future MySQL version.
>>
>> Innodb is the default, right ? I didn't change it. [vms]my.cnf has
>> lines relating to innodb, and the rest are commented out. I didn't
>> make any changes.
>
> Right, Innodb is the default, but you can specify when you create a
> table which storage engine you want to use for this table.
> You can use
> mysql> show table status like 'my_table';
>
> to check which storage engine is used.
Seems like MyISAM is the default, and the only engine supported for the
system tables.
I've put "default-table-type=innodb" in the [mysqld] section of my.cnf
and restarted - it wasn't there before.
I've also done: "alter table <name> type=innodb;" to all my issue
tracker tables (but not to mysql or mysql_help). Doing that seemed to
lose some data too, but I'm hoping that that will be the end of the
suspect data.
What are the known problems with the MyISAM engine ?
What engine are other people seeing used (show table status;) ?
Has anyone got a default-table-type set ?
Thanks,
Chris
Correct, don't convert system tables, MyISAM is the only supported
engine for the system tables (mysql database)
> I've put "default-table-type=innodb" in the [mysqld] section of my.cnf
> and restarted - it wasn't there before.
>
It was in the MYSQL_ROOT:[VMS.MYSQL]run_mysqld.com
which use the qualifier --default-storage-engine=InnoDB
note also the --ansi qualifier, if you don't need this just remove it.
> I've also done: "alter table <name> type=innodb;" to all my issue
> tracker tables (but not to mysql or mysql_help). Doing that seemed to
> lose some data too, but I'm hoping that that will be the end of the
> suspect data.
>
> What are the known problems with the MyISAM engine ?
The most frequent problem is a corruption of the lengh of the record.
Most of the time a repair fix the problem.
> What engine are other people seeing used (show table status;) ?
> Has anyone got a default-table-type set ?
>
I know site which use MySQL on VMS using InnoDB on multi GB database
with millions records without more problems than on another OS, which
do't mean without any problems ;-)
Jean-François