Avoid FreeBSD, Unless they did some real big magic on the scheduler of 9. Claudio On Jun 28, 2013 6:12 PM, "Andy Wallace" <awall...@ihouseweb.com> 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 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 > >
