morgo

26 ms·

1. 241.▲
   by morgo 13y ago

   Checkbox: "Notify when Back Up" http://www.pagerduty.com/docs/guides/pingdom-integration-gui...
2. 242.▲
   by morgo 13y ago

   I would rather it use the API rather than email. I think it's also prone to misconfiguration, since you have to explicitly check a box to alert when back up. It just feels like a second class citizen.
3. 243.▲
   by morgo 13y ago

   Anyone know of a service like this with good Pager Duty integration? I've previously used Pingdom (which doesn't), and I'd happily make the switch.
4. 244.▲
   by morgo 13y ago

   http://en.wikipedia.org/wiki/Onesies_(brand)
5. 245.▲
   by morgo 13y ago

   I think this would be a difficult question to answer, without knowing the specific case why you are getting deadlocks. What you want for best performance is optimistic concurrency control. Which means that you need to allow for "deadl
6. 246.▲
   by morgo 13y ago

   Hi! There are some good suggestions in this thread already. Step #1 is to determine why it is slow. If it is slow under load, then I am going to suspect that you are hitting table locks - which means you need to migrate to InnoDB (row lock
7. 247.▲
   by morgo 13y ago

   That's really cool. Thanks!
8. 248.▲
   by morgo 13y ago

   Durability will typically be very expensive to implement unless you have a fast SSD or RAID controller with NVRAM, so it will skew the test considerably if you make MySQL offer it, but say MongoDB does not have to. But I do recommend it for
9. 249.▲
   by morgo 13y ago

   I think it would be interesting if respective technology vendors could be motivated to tune the configuration, and be bound by some rules. eWeek did a DB shootout like this 10 years ago, and (as the rumor goes) led to the creation of the
10. 250.▲
    by morgo 13y ago

    I have a rudimentary knowledge of MySQL Internals, so I am going to take a guess why it has taken so long. They want to implement this feature server side, which means that they either have to add: (1) A new server setting (SET SHOW_CREATE_
11. 251.▲
    by morgo 13y ago

    :)
12. 252.▲
    by morgo 13y ago

    For context, here is Stephen Conroy talking about spams and scams coming through the portal: http://www.youtube.com/watch?v=1gl7X6peh-w
13. 253.▲
    by morgo 13y ago

    More official comment: http://insidemysql.com/the-mysql-man-pages-are-available-und...
14. 254.▲
    What MySQL is really good at(tocker.ca)

    1 points by morgo 13y ago|0 comments
15. 255.▲
    Benchmarking & Prewarming Amazon ELBs(tocker.ca)

    1 points by morgo 13y ago|0 comments
16. 256.▲
    Thoughts on Amazon Offsite Backup(tocker.ca)

    1 points by morgo 13y ago|0 comments
17. 257.▲
    by morgo 14y ago

    Both are available in the Amazon Linux AMI: httpd.x86_64 : Apache HTTP Server httpd24.x86_64 : Apache HTTP Server
18. 258.▲
    by morgo 14y ago

    I've worked from home for maybe 5 of the past 8 years. I personally hate it, but these were the better opportunities than what I could obtain locally. I think what the original author has to see is that it's not about his strengths/weaknes
19. 259.▲
    by morgo 14y ago

    Yeah I can't wait till people wise up and don't just see "the cloud" as one AZ in us-east-1. (It wouldn't have helped in this case, but its a general annoyance I have.)
20. 260.▲
    by morgo 14y ago

    I think the author merged in two terms of his analysis of performance that are really separate: - Response Time (how long does it take per task) - Throughput (how many tasks can we complete per N) For some of us, getting better responses me
21. 261.▲
    by morgo 14y ago

    Supports versus recommends are two different things. To do master-master correctly, you need either some sort of conflict resolution or a locking manager. MySQL has neither.
22. 262.▲
    by morgo 14y ago

    Don't forget wifi :) I wish conferences offered two rates: one for just the talks, and one for talks + (coffee,wifi,lunch).
23. 263.▲
    by morgo 14y ago

    http://www.engineyard.com/blog/2011/5-subtle-ways-youre-usin...
24. 264.▲
    by morgo 14y ago

    A queue is FIFO oriented, a database is least-recently-used (LRU). It works, but is not going to be the most efficient tool. Where a queue is really useful is converting from foreground to background, so that you can optimize for throughpu
25. 265.▲
    by morgo 15y ago

    You can make the internet break for a small number of people, but on this scale I don't think ISPs would be able to deal with the support calls.
26. 266.▲
    by morgo 15y ago

    There are very few banks. The poster is clearly upset with his, but if they refuse to do business, he will have even fewer options.
27. 267.▲
    by morgo 15y ago

    "Yet another self-promotion article. Oh, we stuff data in memory and then when it is time to write changes on disk everything got frozen! MySQL suck, buy our solution! Nice guys.)" You got this part all wrong. He explicitly said that 'thei
28. 268.▲
    by morgo 15y ago

    Common myth. Real answer: it depends. I recently had a bug approved to update the manual: http://bugs.mysql.com/bug.php?id=54306
29. 269.▲
    by morgo 15y ago

    Yes, I agree 100%. There is a downside however. memcached is very much for hash-structures (point lookups only). InnoDB is a B+tree, so it can do ranged reads as well.
30. 270.▲
    by morgo 15y ago

    What's interesting about this article now, is the feature is (more or less) going mainline in MySQL 5.6, except the API will be the standard memcached protocol and not the handler socket API in the linked article. See: http://dev.mysql.com