Nope, it was locked on a single value for about 36 hours, until we restarted the
engine last night. Now it's running fine, and we're setting up a testbed to
evaluate
MySQL 5.6 and FreeBSD 9 (?) for replacing our current Solaris 10/MySQL 5.1.46
setup.
On 6/28/13 12:44 AM, walter harms wrote:
hi,
does the value change at all like below ?
mysql> show global variables like 'timestamp';
+---------------+------------+
| Variable_name | Value |
+---------------+------------+
| timestamp | 1372404355 |
+---------------+------------+
1 row in set (0.00 sec)
mysql> show global variables like 'timestamp';
+---------------+------------+
| Variable_name | Value |
+---------------+------------+
| timestamp | 1372404371 |
+---------------+------------+
1 row in set (0.00 sec)
re,
wh
Am 27.06.2013 20:19, schrieb Andy Wallace:
Benjamin -
Unfortunately:
mysql> show global variables like 'timestamp';
+---------------+------------+
| Variable_name | Value |
+---------------+------------+
| timestamp | 1372238834 |
+---------------+------------+
1 row in set (0.00 sec)
And:
mysql> set global timestamp = 0;
ERROR 1228 (HY000): Variable 'timestamp' is a SESSION variable and can't
be used with SET GLOBAL
This does indeed persist across sessions. Any command line connection I
make to the database
shows the "bad" value for NOW(). I also tweaked the application code to
include NOW() in an
existing query, and the value returned to my PHP code is also the "bad"
value.
Thanks for looking,
andy
On 6/27/13 11:10 AM, Stillman, Benjamin wrote:
It persists across sessions?
Does this return anything:
show global variables like 'timestamp';
Hopefully it returns:
Empty set (0.00 sec)
I vaguely remember reading about a bug in 5.1.4x with something to do
with
a global timestamp. I thought it only showed one though, and that you
couldn't set it.
If the above returned a timestamp and not an empty set, try: set global
timestamp = 0;
That should return something like this:
ERROR 1228 (HY000): Variable 'timestamp' is a SESSION variable and can't
be used with SET GLOBAL
But if it returns:
Query OK, 0 rows affected (0.00 sec)
And then your queries return correct timestamps, you've found a bug.
I'd hope that it would fail, but the only thing I can think of is if it's
being set as a global variable. If this does fix your problem, and if
you're using replication, you may have an issue with your replicated
data.
Replication uses timestamp extensively.
On 6/27/13 1:44 PM, "Andy Wallace" <awall...@ihouseweb.com> wrote:
But the question is how. I have nothing in the code that does it, or
this
would have been true for months instead of just the last 24 hours. In
addition, this is currently set globally - no matter what connection to
the database, it all comes up with this value. Which means that all my
time-based queries no longer work correctly.
Does your message suggest that setting it to 0 might clear the problem?
On 6/27/13 10:31 AM, Stillman, Benjamin wrote:
Timestamp is a session variable, so it must have been set to something
other than 0 (1372228034 epoch is the date you're showing) in your
current
session.
mysql> set timestamp = 1372228034;
Query OK, 0 rows affected (0.00 sec)
mysql> select now(), sysdate();
+---------------------+---------------------+
| now() | sysdate() |
+---------------------+---------------------+
| 2013-06-26 02:27:14 | 2013-06-27 13:20:48 |
+---------------------+---------------------+
1 row in set (0.00 sec)
mysql> set timestamp = 0;
Query OK, 0 rows affected (0.00 sec)
mysql> select now(), sysdate();
+---------------------+---------------------+
| now() | sysdate() |
+---------------------+---------------------+
| 2013-06-27 13:21:34 | 2013-06-27 13:21:34 |
+---------------------+---------------------+
1 row in set (0.00 sec)
Cliff's notes: set timestamp = 0;
On 6/26/13 6:10 PM, "Andy Wallace" <awall...@ihouseweb.com> wrote:
We've been having some issues with one of our MySQL servers lately,
and
currently
the dang thing is "stuck". For at least the last hour, NOW() is
returning
the same
value:
mysql> select now();
+---------------------+
| now() |
+---------------------+
| 2013-06-26 02:27:14 |
+---------------------+
The system variable "timestamp" also has that same time value
stored in
it. How
can we kick this loose so that the values are more current with real
time? (it is
currently 3:08PM here, despite our MySQL instance thinking it's 2am.
The
system
time on the machine is correct:
$ date
Wed Jun 26 15:08:56 PDT 2013
This is MySQL 5.1.46 running on solaris2.10.
Any ideas short of restarting the MySQL engine? I'm willing to do
that,
but would much
rather wait and not do it in the middle of the day.
Thanks,
Andy
--
Andy Wallace
iHOUSEweb, Inc.
awall...@ihouseweb.com
(866) 645-7700 ext 219
--
"Sometimes it pays to stay in bed on Monday, rather than spending the
rest of the week debugging Monday's code."
- Christopher Thompson
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql
________________________________
Notice: This communication may contain privileged and/or confidential
information. If you are not the intended recipient, please notify the
sender by email, and immediately delete the message and any attachments
without copying or disclosing them. LBI may, for any reason, intercept,
access, use, and disclose any information that is communicated by or
through, or which is stored on, its networks, applications, services,
and devices.
--
Andy Wallace
iHOUSEweb, Inc.
awall...@ihouseweb.com
(866) 645-7700 ext 219
--
"Sometimes it pays to stay in bed on Monday, rather than spending the
rest of the week debugging Monday's code."
- Christopher Thompson
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql
________________________________
Notice: This communication may contain privileged and/or confidential
information. If you are not the intended recipient, please notify the
sender by email, and immediately delete the message and any
attachments without copying or disclosing them. LBI may, for any
reason, intercept, access, use, and disclose any information that is
communicated by or through, or which is stored on, its networks,
applications, services, and devices.
--
Andy Wallace
iHOUSEweb, Inc.
awall...@ihouseweb.com
(866) 645-7700 ext 219
--
"Sometimes it pays to stay in bed on Monday, rather than spending the rest of the
week debugging Monday's code."
- Christopher Thompson
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql
