1045 Error accessing mysql db

[Augori]

After an operating system change (CentOS 5 to CentOS 6), my Python script
could no longer connect with mysql database.  I get the following error...

mysql_exceptions.OperationalError: (1045, "Access denied for user 'foo'@
'localhost
' (using password: YES)")

I have granted all on all databases to this user.
I attempted to run mysql_upgrade.

I am stymied because according to another guy, he is successfully accessing
the same database with the same credentials as I am (but in a PHP script).

Can any of you suggest an explanation for this?

Thanks in advance!

Re: mysqld_safe running a long time

[Augori]

Maybe it's because I'm accessing it through a C Panel SSH Shell that it
acts differently than you expected.  It doesn't matter anyway… I was able
to exit the shell and regain control of my shell.   I'm giving up on the
upgrade approach for now, so let's consider this conversation concluded.


On Wed, Aug 20, 2014 at 7:28 PM, Reindl Harald 
wrote:

>
>
> Am 21.08.2014 um 01:05 schrieb Augori:
> > when I use the bg command, it says
> >
> > 1 job already in background
> >
> > and continues to run in the foreground.
>
> *bullshit* if it is running in foreground you can't enter
> anything because your terminal would be blocked, the bg
> command only works if you suspend a foreground job
> with CTRL+Z to bring it into backgrund
>
> you really really should learn to post *complete* input
> and output what you are doing and honestly consider if
> what you are try to do makes any sense
>
> > On Wed, Aug 20, 2014 at 11:04 AM, Reindl Harald  > wrote:
> >
> > Am 20.08.2014 um 16:39 schrieb Augori:
> > > However, it's been 12 hours now and the thing is still restarting
> in safe
> > > mode and I can't tell if it's making progress.  The command I
> typed was
> > >
> > > /usr/bin/mysqld_safe --skip-grant-tables&
> > >
> > > I think I forgot to include the ampersand (&) at the end which
> would have
> > > made it run in the background.
> >
> > yes
> >
> > just type STRG+Z which suspneds the brocess followed by the command
> "bg"
> >
> > > So now I'm seeing output like this the following:
> > > ---
> > > ...
> > > 0-7f5f68388000 rw-p  00:00 0
> > > 7f5f68388000-7f5f6838900140820 08:35:01 mysqld_safe Number of
> processes
> > > running now: 0
> > > 140820 08:35:01 mysqld_safe mysqld restarted
> > > 
> > >
> > > It always says Number of processes running now is 0.
> > > And it always has the number 140820 on that last line.
> > >
> > > Should I stop this?  If so how?
> >
> > by just press "STRG+C"
> >
> > > If I let it go, is it going to take
> > > another 2-3 days to restart in regular mode?  Does anything have
> any
> > > alternative suggestions for my original credentials access problem?
> >
> > mysqld_safe has *nothing* to do with "safe mode"
> >
> > it's just the profram invoked to start mysqld and
> > watch / restart if mysqld dies
> >
> > if you start an application in forground it will always
> > take forever or until it exits which you don't expect
> > from a service because - well, you just said to do so
>
>

Re: mysqld_safe running a long time

[Reindl Harald]

Am 21.08.2014 um 01:05 schrieb Augori:
> when I use the bg command, it says 
> 
> 1 job already in background
> 
> and continues to run in the foreground.

*bullshit* if it is running in foreground you can't enter
anything because your terminal would be blocked, the bg
command only works if you suspend a foreground job
with CTRL+Z to bring it into backgrund

you really really should learn to post *complete* input
and output what you are doing and honestly consider if
what you are try to do makes any sense

> On Wed, Aug 20, 2014 at 11:04 AM, Reindl Harald  > wrote:
> 
> Am 20.08.2014 um 16:39 schrieb Augori:
> > However, it's been 12 hours now and the thing is still restarting in 
> safe
> > mode and I can't tell if it's making progress.  The command I typed was
> >
> > /usr/bin/mysqld_safe --skip-grant-tables&
> >
> > I think I forgot to include the ampersand (&) at the end which would 
> have
> > made it run in the background.
> 
> yes
> 
> just type STRG+Z which suspneds the brocess followed by the command "bg"
> 
> > So now I'm seeing output like this the following:
> > ---
> > ...
> > 0-7f5f68388000 rw-p  00:00 0
> > 7f5f68388000-7f5f6838900140820 08:35:01 mysqld_safe Number of processes
> > running now: 0
> > 140820 08:35:01 mysqld_safe mysqld restarted
> > 
> >
> > It always says Number of processes running now is 0.
> > And it always has the number 140820 on that last line.
> >
> > Should I stop this?  If so how?
> 
> by just press "STRG+C"
> 
> > If I let it go, is it going to take
> > another 2-3 days to restart in regular mode?  Does anything have any
> > alternative suggestions for my original credentials access problem?
> 
> mysqld_safe has *nothing* to do with "safe mode"
> 
> it's just the profram invoked to start mysqld and
> watch / restart if mysqld dies
> 
> if you start an application in forground it will always
> take forever or until it exits which you don't expect
> from a service because - well, you just said to do so



signature.asc
Description: OpenPGP digital signature

Re: mysqld_safe running a long time

[Augori]

Hi All,

when I use the bg command, it says

1 job already in background

and continues to run in the foreground.


On Wed, Aug 20, 2014 at 11:04 AM, Reindl Harald 
wrote:

>
>
> Am 20.08.2014 um 16:39 schrieb Augori:
> > However, it's been 12 hours now and the thing is still restarting in safe
> > mode and I can't tell if it's making progress.  The command I typed was
> >
> > /usr/bin/mysqld_safe --skip-grant-tables&
> >
> > I think I forgot to include the ampersand (&) at the end which would have
> > made it run in the background.
>
> yes
>
> just type STRG+Z which suspneds the brocess followed by the command "bg"
>
> > So now I'm seeing output like this the following:
> > ---
> > ...
> > 0-7f5f68388000 rw-p  00:00 0
> > 7f5f68388000-7f5f6838900140820 08:35:01 mysqld_safe Number of processes
> > running now: 0
> > 140820 08:35:01 mysqld_safe mysqld restarted
> > 
> >
> > It always says Number of processes running now is 0.
> > And it always has the number 140820 on that last line.
> >
> > Should I stop this?  If so how?
>
> by just press "STRG+C"
>
> > If I let it go, is it going to take
> > another 2-3 days to restart in regular mode?  Does anything have any
> > alternative suggestions for my original credentials access problem?
>
> mysqld_safe has *nothing* to do with "safe mode"
>
> it's just the profram invoked to start mysqld and
> watch / restart if mysqld dies
>
> if you start an application in forground it will always
> take forever or until it exits which you don't expect
> from a service because - well, you just said to do so
>
>

Stored procedure debuggers

[Larry Martell]

Does anyone know of any debuggers for stored procs that run on Mac and/or Linux?

-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql

Re: how to access Synology's mysql (mariadb) on the command line

[Wybo]

Yes, that worked - thank you very much!

On 2014-08-20 22:51, shawn l.green wrote:

Hello Wybo,

I cleansed your reply and cc:'ed the list again to share the answer.

On 8/20/2014 4:24 PM, Wybo wrote:

Hi Shawn,

Thanks for your prompt reply - I suppose I'll have to do that query via
phpMysqlAdmin. When I do that, the only host that appears is localhost.
However, when I browse the user table, I also see %edited%, which is the
hostname of the synology station, see the attached screenshot (%also edited%). 
Does this
mean that I have to add a new entry in this table? If so, can I do that
via phpMysqlAdmin?



Yes, you will need to use your phpMysqlAdmin session to issue an
appropriate GRANT command so that the 'wybo' user can login from
'wybo.fritz.box'.

Example -

GRANT  on *.* to
'wybo'@'wybo.fritz.box' IDENTIFIED BY 'password goes here in plain text'



--
Wybo

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql

Re: how to access Synology's mysql (mariadb) on the command line

[shawn l.green]

Hello Wybo,

I cleansed your reply and cc:'ed the list again to share the answer.

On 8/20/2014 4:24 PM, Wybo wrote:

Hi Shawn,

Thanks for your prompt reply - I suppose I'll have to do that query via
phpMysqlAdmin. When I do that, the only host that appears is localhost.
However, when I browse the user table, I also see %edited%, which is the
hostname of the synology station, see the attached screenshot (%also edited%). 
Does this
mean that I have to add a new entry in this table? If so, can I do that
via phpMysqlAdmin?



Yes, you will need to use your phpMysqlAdmin session to issue an 
appropriate GRANT command so that the 'wybo' user can login from 
'wybo.fritz.box'.


Example -

GRANT  on *.* to 
'wybo'@'wybo.fritz.box' IDENTIFIED BY 'password goes here in plain text'


Research the GRANT command itself (and the other account management 
commands) to see what else you can do while creating an account or 
adjusting permissions.

http://dev.mysql.com/doc/refman/5.6/en/account-management-sql.html

Examples of the types of host patterns you can use are also in the 
manual, here:

http://dev.mysql.com/doc/refman/5.6/en/account-names.html

Yours,
--
Shawn Green
MySQL Senior Principal Technical Support Engineer
Oracle USA, Inc. - Hardware and Software, Engineered to Work Together.
Office: Blountville, TN

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql

Re: how to access Synology's mysql (mariadb) on the command line

[shawn l.green]

Hi Wybo,

On 8/20/2014 3:47 PM, Wybo wrote:

My Synology station is on 192.168.178.27,
the database listens to port 3306,
on my FritzBox I forwarded port 3306 to 192.168.178.27,
I /can/ connect to the database on http://192.168.178.27/phpMyAdmin/
But when I try:

mysql --host=192.168.178.27 --password=* --user=wybo

I get:

ERROR 1045 (28000): Access denied for user 'wybo'@'wybo.fritz.box'
(using password: YES)

What am I doing wrong?


Access is granted only if three parts are correct:
1) the login you are using (wybo)
2) the password for the login
3) the host you are connecting from (wybo.fritz.box) is allows to use 
that account.


It's #3 that most people forget about.  Run this query

SELECT host FROM mysql.user WHERE user='wybo';

If you see a pattern in the results that would match your host's name, 
then you need to compare your password hashes. If you don't know if you 
have a matching host pattern, post the list of host patterns you got 
from the query to the list. We can tell you.


Regards,
--
Shawn Green
MySQL Senior Principal Technical Support Engineer
Oracle USA, Inc. - Hardware and Software, Engineered to Work Together.
Office: Blountville, TN

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql

how to access Synology's mysql (mariadb) on the command line

[Wybo]

My Synology station is on 192.168.178.27,
the database listens to port 3306,
on my FritzBox I forwarded port 3306 to 192.168.178.27,
I /can/ connect to the database on http://192.168.178.27/phpMyAdmin/
But when I try:

mysql --host=192.168.178.27 --password=* --user=wybo

I get:

ERROR 1045 (28000): Access denied for user 'wybo'@'wybo.fritz.box' (using 
password: YES)


What am I doing wrong?
--
Wybo

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql

Re: inconsistent optimization

[shawn l.green]

Hi Jim,

On 8/20/2014 11:04 AM, Jim wrote:

Without going into specific details on queries...

Using mysql 5.1 as provided with CentOS6, I've noticed some queries
providing what I can best explain as inconsistent optimization. The
database can be quieted to just controlled queries and at times the same
query will return very quickly when at other times may take minutes.

I don't see the same behavior with mysql5.0 under CentOS5. The same
queries on the same data returns quickly consistently.

When the queries run slowly they show in a process list as either in a
"copy to temp table" or "sending data" state. At first I thought query
restructuring to avoid the copy to temp table was a path to a solution,
but now I don't think so since the same query changed so that it no
longer needs a temp table will sit in the "sending data" state for a
long time.

The queries do eventually come back with correct results, but it takes
minutes rather than milliseconds (sometimes slow; sometimes fast).

Have others seen this behavior? Any explanations?
Any reading to point to for further understanding?



Fluctuations in query times can be the results of configuration mistakes 
(like creating a 1GB query cache or a tiny InnoDB Buffer Pool), or data 
changes (did you add or remove or change a bunch of rows), or query 
patterns (did you add or remove terms from your WHERE clauses, did you 
change which columns were in your SELECT clause, ... ).


To know why a query is doing what it is doing, you need to ask the 
Optimizer. The Optimizer is that part of the server that works out the 
most efficient way to go get the data you are asking for and how to 
process that data once it is pulled from disk or cache.


This is the purpose of the EXPLAIN operator. Just put that word before 
SELECT and see what you get.  An explanation of how to interpret an 
EXPLAIN report is here in the manual (you are reading the manual, right?)

http://dev.mysql.com/doc/refman/5.1/en/explain.html
http://dev.mysql.com/doc/refman/5.1/en/execution-plan-information.html

That will give you a starting place. After that, you can refer to the 
other sections of the "Optimization" chapter to see what you can or 
should be changing to improve your performance.


http://dev.mysql.com/doc/refman/5.1/en/optimization.html

You should also need to learn a little bit about the topic of "index 
statistics" as those are what the Optimizer uses to develop its 
execution plans.


http://dev.mysql.com/doc/refman/5.1/en/analyze-table.html
http://dev.mysql.com/doc/refman/5.1/en/show-index.html
http://dev.mysql.com/doc/refman/5.1/en/innodb-restrictions.html (search 
for "ANALYZE TABLE determines index cardinality...")

http://dev.mysql.com/doc/refman/5.1/en/innodb-parameters.html#sysvar_innodb_stats_sample_pages
http://dev.mysql.com/doc/refman/5.1/en/optimizer-issues.html


Feel free to ask the list any questions that may arise in your research.

Regards,
--
Shawn Green
MySQL Senior Principal Technical Support Engineer
Oracle USA, Inc. - Hardware and Software, Engineered to Work Together.
Office: Blountville, TN

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql

Re: inconsistent optimization

[Jim]

innodb

On 8/20/2014 1:22 PM, Martin Gainty wrote:

Jim/Jaime

What engine are you implementing?/
Qual mecanismo de MySQL que você está implementando?
Saludos desde Sud America
Martín



Date: Wed, 20 Aug 2014 13:54:46 -0300
Subject: Re: inconsistent optimization
From: edua...@gerencianet.com.br
To: j...@lowcarbfriends.com
CC: mysql@lists.mysql.com

Well,

Try to start checking the IOPs vs Disc. Check your iowait and the cache
size.

Could you send a "create table" and the query for us?





Atenciosamente,

*Eduardo Fontinelle*
*Chief Technology Officer | G**erencianet*
Phone: +55 (31) 3603-0812



2014-08-20 12:04 GMT-03:00 Jim :


Without going into specific details on queries...

Using mysql 5.1 as provided with CentOS6, I've noticed some queries
providing what I can best explain as inconsistent optimization. The
database can be quieted to just controlled queries and at times the same
query will return very quickly when at other times may take minutes.

I don't see the same behavior with mysql5.0 under CentOS5. The same
queries on the same data returns quickly consistently.

When the queries run slowly they show in a process list as either in a
"copy to temp table" or "sending data" state. At first I thought query
restructuring to avoid the copy to temp table was a path to a solution, but
now I don't think so since the same query changed so that it no longer
needs a temp table will sit in the "sending data" state for a long time.

The queries do eventually come back with correct results, but it takes
minutes rather than milliseconds (sometimes slow; sometimes fast).

Have others seen this behavior? Any explanations?
Any reading to point to for further understanding?

Thanks.

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql








--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql

RE: inconsistent optimization

[Martin Gainty]

Jim/Jaime

What engine are you implementing?/
Qual mecanismo de MySQL que você está implementando?
Saludos desde Sud America
Martín


> Date: Wed, 20 Aug 2014 13:54:46 -0300
> Subject: Re: inconsistent optimization
> From: edua...@gerencianet.com.br
> To: j...@lowcarbfriends.com
> CC: mysql@lists.mysql.com
> 
> Well,
> 
> Try to start checking the IOPs vs Disc. Check your iowait and the cache
> size.
> 
> Could you send a "create table" and the query for us?
> 
> 
> 
> 
> 
> Atenciosamente,
> 
> *Eduardo Fontinelle*
> *Chief Technology Officer | G**erencianet*
> Phone: +55 (31) 3603-0812
> 
> 
> 
> 2014-08-20 12:04 GMT-03:00 Jim :
> 
> > Without going into specific details on queries...
> >
> > Using mysql 5.1 as provided with CentOS6, I've noticed some queries
> > providing what I can best explain as inconsistent optimization. The
> > database can be quieted to just controlled queries and at times the same
> > query will return very quickly when at other times may take minutes.
> >
> > I don't see the same behavior with mysql5.0 under CentOS5. The same
> > queries on the same data returns quickly consistently.
> >
> > When the queries run slowly they show in a process list as either in a
> > "copy to temp table" or "sending data" state. At first I thought query
> > restructuring to avoid the copy to temp table was a path to a solution, but
> > now I don't think so since the same query changed so that it no longer
> > needs a temp table will sit in the "sending data" state for a long time.
> >
> > The queries do eventually come back with correct results, but it takes
> > minutes rather than milliseconds (sometimes slow; sometimes fast).
> >
> > Have others seen this behavior? Any explanations?
> > Any reading to point to for further understanding?
> >
> > Thanks.
> >
> > --
> > MySQL General Mailing List
> > For list archives: http://lists.mysql.com/mysql
> > To unsubscribe:http://lists.mysql.com/mysql
> >
> >
  

Re: mysqld_safe running a long time

[Reindl Harald]

Am 20.08.2014 um 18:55 schrieb Augori:
> Thanks!  But if it's running in the background, how will I know when it has 
> completed?

completed what?!
http://www.catb.org/esr/faqs/smart-questions.html#beprecise

what did you not understand in the paragraph below?

>> mysqld_safe has *nothing* to do with "safe mode"
>>
>>  it's just the profram invoked to start mysqld and
>>  watch / restart if mysqld dies

"/usr/bin/mysqld_safe --skip-grant-tables" does *nothing else*
than start the ordinary mysql-daemon with --skip-grant-tables

that does not more than *disable any authentication* so that you can
login with any password as any user and if someone does that on a
from outside reachable server he is BTW a fool

ask in a *clear way* what problem you need to solve instead
type commands you don't understand with params you don't
understand from random sources you don't understand

http://stackoverflow.com/questions/1708409/how-to-start-mysql-with-skip-grant-tables

> On Wed, Aug 20, 2014 at 11:04 AM, Reindl Harald  > wrote:
> 
> Am 20.08.2014 um 16:39 schrieb Augori:
> > However, it's been 12 hours now and the thing is still restarting in 
> safe
> > mode and I can't tell if it's making progress.  The command I typed was
> >
> > /usr/bin/mysqld_safe --skip-grant-tables&
> >
> > I think I forgot to include the ampersand (&) at the end which would 
> have
> > made it run in the background.
> 
> yes
> 
> just type STRG+Z which suspneds the brocess followed by the command "bg"
> 
> > So now I'm seeing output like this the following:
> > ---
> > ...
> > 0-7f5f68388000 rw-p  00:00 0
> > 7f5f68388000-7f5f6838900140820 08:35:01 mysqld_safe Number of processes
> > running now: 0
> > 140820 08:35:01 mysqld_safe mysqld restarted
> > 
> >
> > It always says Number of processes running now is 0.
> > And it always has the number 140820 on that last line.
> >
> > Should I stop this?  If so how?
> 
> by just press "STRG+C"
> 
> > If I let it go, is it going to take
> > another 2-3 days to restart in regular mode?  Does anything have any
> > alternative suggestions for my original credentials access problem?
> 
> mysqld_safe has *nothing* to do with "safe mode"
> 
> it's just the profram invoked to start mysqld and
> watch / restart if mysqld dies
> 
> if you start an application in forground it will always
> take forever or until it exits which you don't expect
> from a service because - well, you just said to do so



signature.asc
Description: OpenPGP digital signature

Re: inconsistent optimization

[Eduardo Fontinelle - Gerencianet Pagamentos]

Well,

Try to start checking the IOPs vs Disc. Check your iowait and the cache
size.

Could you send a "create table" and the query for us?





Atenciosamente,

*Eduardo Fontinelle*
*Chief Technology Officer | G**erencianet*
Phone: +55 (31) 3603-0812



2014-08-20 12:04 GMT-03:00 Jim :

> Without going into specific details on queries...
>
> Using mysql 5.1 as provided with CentOS6, I've noticed some queries
> providing what I can best explain as inconsistent optimization. The
> database can be quieted to just controlled queries and at times the same
> query will return very quickly when at other times may take minutes.
>
> I don't see the same behavior with mysql5.0 under CentOS5. The same
> queries on the same data returns quickly consistently.
>
> When the queries run slowly they show in a process list as either in a
> "copy to temp table" or "sending data" state. At first I thought query
> restructuring to avoid the copy to temp table was a path to a solution, but
> now I don't think so since the same query changed so that it no longer
> needs a temp table will sit in the "sending data" state for a long time.
>
> The queries do eventually come back with correct results, but it takes
> minutes rather than milliseconds (sometimes slow; sometimes fast).
>
> Have others seen this behavior? Any explanations?
> Any reading to point to for further understanding?
>
> Thanks.
>
> --
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe:http://lists.mysql.com/mysql
>
>

Re: mysqld_safe running a long time

[Augori]

Thanks!  But if it's running in the background, how will I know when it has
completed?


On Wed, Aug 20, 2014 at 11:04 AM, Reindl Harald 
wrote:

>
>
> Am 20.08.2014 um 16:39 schrieb Augori:
> > However, it's been 12 hours now and the thing is still restarting in safe
> > mode and I can't tell if it's making progress.  The command I typed was
> >
> > /usr/bin/mysqld_safe --skip-grant-tables&
> >
> > I think I forgot to include the ampersand (&) at the end which would have
> > made it run in the background.
>
> yes
>
> just type STRG+Z which suspneds the brocess followed by the command "bg"
>
> > So now I'm seeing output like this the following:
> > ---
> > ...
> > 0-7f5f68388000 rw-p  00:00 0
> > 7f5f68388000-7f5f6838900140820 08:35:01 mysqld_safe Number of processes
> > running now: 0
> > 140820 08:35:01 mysqld_safe mysqld restarted
> > 
> >
> > It always says Number of processes running now is 0.
> > And it always has the number 140820 on that last line.
> >
> > Should I stop this?  If so how?
>
> by just press "STRG+C"
>
> > If I let it go, is it going to take
> > another 2-3 days to restart in regular mode?  Does anything have any
> > alternative suggestions for my original credentials access problem?
>
> mysqld_safe has *nothing* to do with "safe mode"
>
> it's just the profram invoked to start mysqld and
> watch / restart if mysqld dies
>
> if you start an application in forground it will always
> take forever or until it exits which you don't expect
> from a service because - well, you just said to do so
>
>

Re: mysqld_safe running a long time

[Reindl Harald]

Am 20.08.2014 um 16:39 schrieb Augori:
> However, it's been 12 hours now and the thing is still restarting in safe
> mode and I can't tell if it's making progress.  The command I typed was
> 
> /usr/bin/mysqld_safe --skip-grant-tables&
> 
> I think I forgot to include the ampersand (&) at the end which would have
> made it run in the background.

yes

just type STRG+Z which suspneds the brocess followed by the command "bg"

> So now I'm seeing output like this the following:
> ---
> ...
> 0-7f5f68388000 rw-p  00:00 0
> 7f5f68388000-7f5f6838900140820 08:35:01 mysqld_safe Number of processes
> running now: 0
> 140820 08:35:01 mysqld_safe mysqld restarted
> 
> 
> It always says Number of processes running now is 0.
> And it always has the number 140820 on that last line.
> 
> Should I stop this?  If so how?  

by just press "STRG+C"

> If I let it go, is it going to take
> another 2-3 days to restart in regular mode?  Does anything have any
> alternative suggestions for my original credentials access problem?

mysqld_safe has *nothing* to do with "safe mode"

it's just the profram invoked to start mysqld and
watch / restart if mysqld dies

if you start an application in forground it will always
take forever or until it exits which you don't expect
from a service because - well, you just said to do so



signature.asc
Description: OpenPGP digital signature

inconsistent optimization

[Jim]

Without going into specific details on queries...

Using mysql 5.1 as provided with CentOS6, I've noticed some queries 
providing what I can best explain as inconsistent optimization. The 
database can be quieted to just controlled queries and at times the same 
query will return very quickly when at other times may take minutes.


I don't see the same behavior with mysql5.0 under CentOS5. The same 
queries on the same data returns quickly consistently.


When the queries run slowly they show in a process list as either in a 
"copy to temp table" or "sending data" state. At first I thought query 
restructuring to avoid the copy to temp table was a path to a solution, 
but now I don't think so since the same query changed so that it no 
longer needs a temp table will sit in the "sending data" state for a 
long time.


The queries do eventually come back with correct results, but it takes 
minutes rather than milliseconds (sometimes slow; sometimes fast).


Have others seen this behavior? Any explanations?
Any reading to point to for further understanding?

Thanks.

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql

mysqld_safe running a long time

[Augori]

Hi all,

mysql db has been starting in safe mode for 12 hours.  I don't know if I
should stop it or if I do, what will happen.  I'm hoping one of you can
help.

Here's how I got into this mess:
After a operating system change (CentOS 5 to CentOS 6), my Python script
could no longer connect with mysql database.  Others are connecting with
PHP using the same credentials as I am. So, following a comment on this
page:
http://stackoverflow.com/questions/8484722/access-denied-for-user-rootlocalhost-while-attempting-to-grant-privileges

I tried
/usr/bin/mysql_upgrade -u root -p (password)

This failed, so I tried to stop, restart in safe mode, and do the upgrade,
as suggested on this page:

http://blog.philippklaus.de/2011/02/solved-mysql_upgrade-failes-due-to-1045-access-denied/

However, it's been 12 hours now and the thing is still restarting in safe
mode and I can't tell if it's making progress.  The command I typed was

/usr/bin/mysqld_safe --skip-grant-tables&


I think I forgot to include the ampersand (&) at the end which would have
made it run in the background.

So now I'm seeing output like this the following:
---
...
0-7f5f68388000 rw-p  00:00 0
7f5f68388000-7f5f6838900140820 08:35:01 mysqld_safe Number of processes
running now: 0
140820 08:35:01 mysqld_safe mysqld restarted


It always says Number of processes running now is 0.
And it always has the number 140820 on that last line.

Should I stop this?  If so how?  If I let it go, is it going to take
another 2-3 days to restart in regular mode?  Does anything have any
alternative suggestions for my original credentials access problem?

Thank you in advance for any help you can give,
Auguri