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:
Avoid FreeBSD,
Unless they did some real big magic on the scheduler of 9.
Claudio
On Jun 28, 2013 6:12 PM, "Andy Wallace" wrote:
> 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 ev
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 varia
Ok, I appreciate the Einsteinian and Vonnegut humor... just wanted to say. Still
have the problem though. 8-(
On 6/27/13 9:51 AM, Nick Khamis wrote:
Just out of curiosity, is the hardware stationed, or traveling close
to the speed of light (i.e., 18,000 miles per second)? Sorry I could
not help
Just out of curiosity, is the hardware stationed, or traveling close
to the speed of light (i.e., 18,000 miles per second)? Sorry I could
not help it
N.
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/mysql
Well, that begs the question - will restarting the MySQL server instance
tonight fix
the current problem? We do have a plan in place to test and eventually deploy
a more
recent version of MySQL (5.6?), but for now, I have to support 1000's of
customers.
My fingers are crossed.
On 6/27/13 12:2
Hi,
On 06/27/2013 08:19 PM, Andy Wallace wrote:
Benjamin -
Unfortunately:
mysql> show global variables like 'timestamp';
+---++
| Variable_name | Value |
+---++
| timestamp | 1372238834 |
+---++
1 row in set (0.00
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
Sort of:
mysql> show variables like 'init_connect';
+---+---+
| Variable_name | Value |
+---+---+
| init_connect | |
+---+---+
On 6/27/13 11:23 AM, Eric Bergen wrote:
Does show variables like 'init_connect'; return anything?
On Thu, Jun
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();
+-+-
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 se
Does show variables like 'init_connect'; return anything?
On Thu, Jun 27, 2013 at 11:19 AM, Andy Wallace wrote:
> Benjamin -
> Unfortunately:
>
> mysql> show global variables like 'timestamp';
> +---++
> | Variable_name | Value |
> +---++
> | t
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
Problem is that I don't set the timestamp variable anywhere (except yesterday as
a test to try and fix the problem). This is stuff that has been working
correctly
for many months. We had some network/dns and load issues over the last couple of
days, and the mysql clock is frozen at:
mysql> sele
y Wallace" , "mysql list"
>
> Sent: Thursday, 27 June, 2013 1:36:31 AM
> Subject: Re: NOW() is stuck...
>
> Random I-can't-sleep thought: you wouldn't be testint this in a
> single
>
--
Unhappiness is discouraged and will be corrected with kitten pictures.
This is the expected behavior if you set the timestamp variable in
your session. This is the same mechanism that replication uses to
execute transactions on the slave with the correct time. Setting
timestamp back to default or reopening your connection will fix it.
MariaDB [(none)]> set timestamp=
Well, if you want to get unstuck in time, maybe you need to call Billy
Pilgrim ;-)
Andy Wallace 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(
Submit a bug:
http://bugs.mysql.com
Alas, you probably cannot provide a reproducible test case. Still, someone
might start at the code and discover a possible cause.
> -Original Message-
> From: Andy Wallace [mailto:awall...@ihouseweb.com]
> Sent: Wednesday, June 26, 2013 3:10 PM
> To: m
18 matches
Mail list logo
