Category Archives: Security

Jim Starkey Speaks, July Boston MySQL User Group Meeting

http://tinyurl.com/gvwml

And the winner is….MySQL.
http://tinyurl.com/gvwml

And the winner is….MySQL.
Matt Asay wrote an article about open source leakage. It’s quite good, malady and got me thinking.

First I thought, “Open source companies do not ‘lose’ revenue to non-paying customers, they just do not gain revenue from them.” But that’s based on the model of open-source software I have in my head that open source software usually starts out as a free, collaborative effort, and if enough folks get enough steam and come up with a business model (aka “a way to get paid”), then they form a company around the open source software.

Simplifying that model: open source software is free until it’s not.

Saying there is leakage does not do justice to the fact that the river flowed freely until the company came along and dammed up the river. Sure, maybe there’s a big leak, but there’s a lot more not leaking than there is leaking.

But open source != free. And it’s not required, either.

Take a for-pay e-book. You buy a license for a personal copy of a book, and read it. You’re not supposed to make copies of the e-book, or redistribute it, etc under the terms of your license.

However, you can “delve into the source code” of an e-book. You cannot change it and redistribute it claiming you authored it. You can, however, change the words in the book to make it more meaningful for yourself. There’s nothing to stop you from annotating the work. The source is open — all the words are there for you to play with.

Now, open source is like that e-book. There’s nothing that says open source HAS to be free. By convention, it has been. Patents are good for keeping secrets and making money. The open source movement shuns patents. But they’re not shunning the making money. They’re shunning the secretive nature of it.

I once had a housemate who was vegan, whose brother owned a restaurant 3,000 miles away. She made the best vegan pancakes, and refused to give out the recipe because it was her brother’s secret recipe. Now, vegan pancakes are not that complicated. There are about 5 ingredients that could go into them. Why the need for the secret? Because her brother would lose business? Restaurants produce cookbooks all the time; I doubt business would die if the recipe got out.

And that’s what open source is all about — “I have this great recipe for vegan pancakes, and I want to share it with you.”

Let me be clear: I think that open source companies deserve to be paid for their work. Much of the time the products are excellent. That does not mean it’s bug-free. (I live in the United States, and I think it’s one of the best countries to live in, but that does not mean we do everything right….far from it!) Most of this is a semantic rant.

I find it amusing that it used to be difficult to convince big companies that open source was good, because upper management equated free with bad. Now that we’ve convinced some of them, we’re upset that it’s difficult to convince big companies that they should pay for something we give them for free.

I think MySQL actually has a sane licensing policy, and I think they’re going in the right direction with MySQL Network. Having free software and for-pay technical service and support seems like a good mix….for MySQL. I can certainly see that being abused by a company that has a bad product, intentionally, to get more $$ out of customers because they are forced to get support — much like Remedy requires lots of customization before it actually can work. MySQL is much better than that.

I think MySQL in particular would do well to offer “Optimization Consulting” for a fee. I know they offer that already, but particularly call it that, as I am always hearing about companies looking for a MySQL consultant for a few weeks to help them optimize their servers.
http://tinyurl.com/gvwml

And the winner is….MySQL.
Matt Asay wrote an article about open source leakage. It’s quite good, malady and got me thinking.

First I thought, “Open source companies do not ‘lose’ revenue to non-paying customers, they just do not gain revenue from them.” But that’s based on the model of open-source software I have in my head that open source software usually starts out as a free, collaborative effort, and if enough folks get enough steam and come up with a business model (aka “a way to get paid”), then they form a company around the open source software.

Simplifying that model: open source software is free until it’s not.

Saying there is leakage does not do justice to the fact that the river flowed freely until the company came along and dammed up the river. Sure, maybe there’s a big leak, but there’s a lot more not leaking than there is leaking.

But open source != free. And it’s not required, either.

Take a for-pay e-book. You buy a license for a personal copy of a book, and read it. You’re not supposed to make copies of the e-book, or redistribute it, etc under the terms of your license.

However, you can “delve into the source code” of an e-book. You cannot change it and redistribute it claiming you authored it. You can, however, change the words in the book to make it more meaningful for yourself. There’s nothing to stop you from annotating the work. The source is open — all the words are there for you to play with.

Now, open source is like that e-book. There’s nothing that says open source HAS to be free. By convention, it has been. Patents are good for keeping secrets and making money. The open source movement shuns patents. But they’re not shunning the making money. They’re shunning the secretive nature of it.

I once had a housemate who was vegan, whose brother owned a restaurant 3,000 miles away. She made the best vegan pancakes, and refused to give out the recipe because it was her brother’s secret recipe. Now, vegan pancakes are not that complicated. There are about 5 ingredients that could go into them. Why the need for the secret? Because her brother would lose business? Restaurants produce cookbooks all the time; I doubt business would die if the recipe got out.

And that’s what open source is all about — “I have this great recipe for vegan pancakes, and I want to share it with you.”

Let me be clear: I think that open source companies deserve to be paid for their work. Much of the time the products are excellent. That does not mean it’s bug-free. (I live in the United States, and I think it’s one of the best countries to live in, but that does not mean we do everything right….far from it!) Most of this is a semantic rant.

I find it amusing that it used to be difficult to convince big companies that open source was good, because upper management equated free with bad. Now that we’ve convinced some of them, we’re upset that it’s difficult to convince big companies that they should pay for something we give them for free.

I think MySQL actually has a sane licensing policy, and I think they’re going in the right direction with MySQL Network. Having free software and for-pay technical service and support seems like a good mix….for MySQL. I can certainly see that being abused by a company that has a bad product, intentionally, to get more $$ out of customers because they are forced to get support — much like Remedy requires lots of customization before it actually can work. MySQL is much better than that.

I think MySQL in particular would do well to offer “Optimization Consulting” for a fee. I know they offer that already, but particularly call it that, as I am always hearing about companies looking for a MySQL consultant for a few weeks to help them optimize their servers.
Note the title is “How I have a successful MySQL User Group.” There’s more than one way to do it, tuberculosis I’m sure. There are 3 basic principles:

1) Try to do as little work as possible.

2) Make your colleagues do as little work as possible.

3) Always have a topic/presentation

These three principles will get you far, site and should be weighted equally. Do not use principle # 1 as an excuse to not follow principle #3. As well, “doing work” includes “paying money”. With that being said:

  1. Make your user group easy to get to. This has different meanings for different areas. It may mean near a major highway interchange, it may mean near a mass transit station. Whatever it means for you, make it easy.
  2. When the Boston MySQL User Group first started, we had free space in an office building right in the city of Boston.

    Pros Cons
    Free Not enough parking
    Close to the subway and train station No free parking
    The street was clearly labeled We had to have a person stand by the door to let people in
    The building was clearly labeled
    There was a great pub next door

    Then we moved to a space at MIT:

    Pros Cons
    Free Passers-by eat the pizza and drink the soda
    Close to the subway and train station We had to have good maps to find the location
    Plenty of free parking

    Now, you may not be so lucky to find a place that will give you space for free. Consider local universities. Also, local libraries (university or otherwise) usually have some meeting space where they might be able to host you. Our first space, an office space, was gotten through a contact at MySQL. Contact some companies who use MySQL and ask if they’ll lend you space — most tech companies have folks there at night anyway, and it’s free advertising for the company! There is a book company near you, or a Pearson VUE center. Remember: it does not hurt to ask. The worst people can say is “no”, and if it’s contributing toward education, a book company (Pearson Education, Apress, O’Reilly, etc) might sponsor it.

    Getting a free space is key, particularly if it has A/V equipment for you to use (if you want to have lectures).

    Granted, if you want to just have a freeform discussion, any pub or coffee shop or location will do.

    You may think about having it in your home. Consider issues of personal safety, domestic distractions (kids, pets, etc), parking and transit, and the fact that most people feel comfortable going to their first meeting on “neutral” ground. However, if the culture surrounding where you live encourages it, go for it!

    If you must pay for a location, get a company to sponsor it. Get their monetary and time commitment in writing if you can (ie, they will sponsor for a year).

  3. Make the meetings easy to remember. Have them on the same day of the month (ie, 2nd Monday). Do not make them conflict with something similar (ie, PHP group, linux group). Try to have it at the same place each time.
  4. Figure out what your group wants and give it to them.
  5. Do they want lectures on specific topics? Maybe go to a place with wireless access and a “troubleshooting” meeting every so often. Maybe they want a blog with news, or war stories. Maybe a lending library would work. Anyone that comes to your meeting is looking for something. Ask each new member what they’re looking for. If they say “to learn more” then go with lectures — make sure to accomodate all skill sets, and have advanced lectures as well as beginning lectures. If they want to get to know each other better, go to a pub and talk about MySQL while you down a pint. Or run a charity fundraiser and donate the proceeds to a not-for-profit like the Electronic Freedom Foundation. There’s plenty the group can do, including having contests, or even starting a business together if you’re plucky.

  6. Have incentives.
  7. But remember rule #2, so keep costs as low as possible. Ask companies to sponsor dinner or light refreshments. Don’t be shy; ask book companies for books, T-shirts and buttons to give away as prizes. Again, the worst they can say is “no”, and I’ve found book companies and MySQL AB to be VERY accomodating, as well as local businesses. Ask company techies to present. Ask MySQL to send someone out to present.

  8. Be available, and follow up when you say you will. Often times folks will have a question. Being able to respond in a timely manner is important. But if you speak out and make regular annoucements, and solicit feedback, folks will know you are accomodating.
  9. Do not do work others can do. When someone asks if you can forward a job listing, have them post it to your group members. Or, better yet, have them come to your meeting and make an announcement in the first 5 minutes. This includes advertising! Find your local MySQL Sales Rep and ask them to help promote your group. Promote it on any site you can think of — in a blog, on Craigslist, heck, make flyers and post it around town if you have to. Get the word out there!
  10. Have the right attitude. It’s not your meeting, it’s your group’s meeting. If they want different topics, ask someone to research and present. It’s OK if the research isn’t perfect or complete; many times your group will fill in with their experiences.
  11. It’s OK to be wrong. No, really. If you don’t know the answer to a question, look it up later on, and follow up. Or ask the group if anyone knows. Also, presentations take time to make, and if you feel compelled to get every single detail right, they’ll take a lot longer. Keep an offline copy of the manual so you can look up anything you need to.
  12. Ask others for help. Even if you think you can do it better or faster. Your group should be able to survive without you, so if you can’t make a meeting all is not lost. This includes asking others to do a presentation of any length — it can be a 10 minute “this is how we use MySQL and this is what our setup looks like” to an hour or more. It does not have to be intimidating. Ask folks to present workshops they’re presenting at conferences, or present notes from conferences they go to. People need to feel like part of the group if the group is to be successful.
  13. If you can’t get a presentation, download one. MySQL is excellent at providing past webinars. Download it to your computer, and have a free lecture from an expert, that you can pause and rewind if you need to. MySQL Webinars. The Boston MySQL User Group videorecords the presentations and puts them online — see the links under “Presentations” at http://www.sheeri.net

Note: The Boston MySQL User Group is successful, but we don’t quite do everything above. I’d love to have more socialization, and I think once summer comes I’ll think of something geeky and fun to do outdoors, with little cost. Or maybe just a bowling trip.
http://tinyurl.com/gvwml

And the winner is….MySQL.
Matt Asay wrote an article about open source leakage. It’s quite good, malady and got me thinking.

First I thought, “Open source companies do not ‘lose’ revenue to non-paying customers, they just do not gain revenue from them.” But that’s based on the model of open-source software I have in my head that open source software usually starts out as a free, collaborative effort, and if enough folks get enough steam and come up with a business model (aka “a way to get paid”), then they form a company around the open source software.

Simplifying that model: open source software is free until it’s not.

Saying there is leakage does not do justice to the fact that the river flowed freely until the company came along and dammed up the river. Sure, maybe there’s a big leak, but there’s a lot more not leaking than there is leaking.

But open source != free. And it’s not required, either.

Take a for-pay e-book. You buy a license for a personal copy of a book, and read it. You’re not supposed to make copies of the e-book, or redistribute it, etc under the terms of your license.

However, you can “delve into the source code” of an e-book. You cannot change it and redistribute it claiming you authored it. You can, however, change the words in the book to make it more meaningful for yourself. There’s nothing to stop you from annotating the work. The source is open — all the words are there for you to play with.

Now, open source is like that e-book. There’s nothing that says open source HAS to be free. By convention, it has been. Patents are good for keeping secrets and making money. The open source movement shuns patents. But they’re not shunning the making money. They’re shunning the secretive nature of it.

I once had a housemate who was vegan, whose brother owned a restaurant 3,000 miles away. She made the best vegan pancakes, and refused to give out the recipe because it was her brother’s secret recipe. Now, vegan pancakes are not that complicated. There are about 5 ingredients that could go into them. Why the need for the secret? Because her brother would lose business? Restaurants produce cookbooks all the time; I doubt business would die if the recipe got out.

And that’s what open source is all about — “I have this great recipe for vegan pancakes, and I want to share it with you.”

Let me be clear: I think that open source companies deserve to be paid for their work. Much of the time the products are excellent. That does not mean it’s bug-free. (I live in the United States, and I think it’s one of the best countries to live in, but that does not mean we do everything right….far from it!) Most of this is a semantic rant.

I find it amusing that it used to be difficult to convince big companies that open source was good, because upper management equated free with bad. Now that we’ve convinced some of them, we’re upset that it’s difficult to convince big companies that they should pay for something we give them for free.

I think MySQL actually has a sane licensing policy, and I think they’re going in the right direction with MySQL Network. Having free software and for-pay technical service and support seems like a good mix….for MySQL. I can certainly see that being abused by a company that has a bad product, intentionally, to get more $$ out of customers because they are forced to get support — much like Remedy requires lots of customization before it actually can work. MySQL is much better than that.

I think MySQL in particular would do well to offer “Optimization Consulting” for a fee. I know they offer that already, but particularly call it that, as I am always hearing about companies looking for a MySQL consultant for a few weeks to help them optimize their servers.
Note the title is “How I have a successful MySQL User Group.” There’s more than one way to do it, tuberculosis I’m sure. There are 3 basic principles:

1) Try to do as little work as possible.

2) Make your colleagues do as little work as possible.

3) Always have a topic/presentation

These three principles will get you far, site and should be weighted equally. Do not use principle # 1 as an excuse to not follow principle #3. As well, “doing work” includes “paying money”. With that being said:

  1. Make your user group easy to get to. This has different meanings for different areas. It may mean near a major highway interchange, it may mean near a mass transit station. Whatever it means for you, make it easy.
  2. When the Boston MySQL User Group first started, we had free space in an office building right in the city of Boston.

    Pros Cons
    Free Not enough parking
    Close to the subway and train station No free parking
    The street was clearly labeled We had to have a person stand by the door to let people in
    The building was clearly labeled
    There was a great pub next door

    Then we moved to a space at MIT:

    Pros Cons
    Free Passers-by eat the pizza and drink the soda
    Close to the subway and train station We had to have good maps to find the location
    Plenty of free parking

    Now, you may not be so lucky to find a place that will give you space for free. Consider local universities. Also, local libraries (university or otherwise) usually have some meeting space where they might be able to host you. Our first space, an office space, was gotten through a contact at MySQL. Contact some companies who use MySQL and ask if they’ll lend you space — most tech companies have folks there at night anyway, and it’s free advertising for the company! There is a book company near you, or a Pearson VUE center. Remember: it does not hurt to ask. The worst people can say is “no”, and if it’s contributing toward education, a book company (Pearson Education, Apress, O’Reilly, etc) might sponsor it.

    Getting a free space is key, particularly if it has A/V equipment for you to use (if you want to have lectures).

    Granted, if you want to just have a freeform discussion, any pub or coffee shop or location will do.

    You may think about having it in your home. Consider issues of personal safety, domestic distractions (kids, pets, etc), parking and transit, and the fact that most people feel comfortable going to their first meeting on “neutral” ground. However, if the culture surrounding where you live encourages it, go for it!

    If you must pay for a location, get a company to sponsor it. Get their monetary and time commitment in writing if you can (ie, they will sponsor for a year).

  3. Make the meetings easy to remember. Have them on the same day of the month (ie, 2nd Monday). Do not make them conflict with something similar (ie, PHP group, linux group). Try to have it at the same place each time.
  4. Figure out what your group wants and give it to them.
  5. Do they want lectures on specific topics? Maybe go to a place with wireless access and a “troubleshooting” meeting every so often. Maybe they want a blog with news, or war stories. Maybe a lending library would work. Anyone that comes to your meeting is looking for something. Ask each new member what they’re looking for. If they say “to learn more” then go with lectures — make sure to accomodate all skill sets, and have advanced lectures as well as beginning lectures. If they want to get to know each other better, go to a pub and talk about MySQL while you down a pint. Or run a charity fundraiser and donate the proceeds to a not-for-profit like the Electronic Freedom Foundation. There’s plenty the group can do, including having contests, or even starting a business together if you’re plucky.

  6. Have incentives.
  7. But remember rule #2, so keep costs as low as possible. Ask companies to sponsor dinner or light refreshments. Don’t be shy; ask book companies for books, T-shirts and buttons to give away as prizes. Again, the worst they can say is “no”, and I’ve found book companies and MySQL AB to be VERY accomodating, as well as local businesses. Ask company techies to present. Ask MySQL to send someone out to present.

  8. Be available, and follow up when you say you will. Often times folks will have a question. Being able to respond in a timely manner is important. But if you speak out and make regular annoucements, and solicit feedback, folks will know you are accomodating.
  9. Do not do work others can do. When someone asks if you can forward a job listing, have them post it to your group members. Or, better yet, have them come to your meeting and make an announcement in the first 5 minutes. This includes advertising! Find your local MySQL Sales Rep and ask them to help promote your group. Promote it on any site you can think of — in a blog, on Craigslist, heck, make flyers and post it around town if you have to. Get the word out there!
  10. Have the right attitude. It’s not your meeting, it’s your group’s meeting. If they want different topics, ask someone to research and present. It’s OK if the research isn’t perfect or complete; many times your group will fill in with their experiences.
  11. It’s OK to be wrong. No, really. If you don’t know the answer to a question, look it up later on, and follow up. Or ask the group if anyone knows. Also, presentations take time to make, and if you feel compelled to get every single detail right, they’ll take a lot longer. Keep an offline copy of the manual so you can look up anything you need to.
  12. Ask others for help. Even if you think you can do it better or faster. Your group should be able to survive without you, so if you can’t make a meeting all is not lost. This includes asking others to do a presentation of any length — it can be a 10 minute “this is how we use MySQL and this is what our setup looks like” to an hour or more. It does not have to be intimidating. Ask folks to present workshops they’re presenting at conferences, or present notes from conferences they go to. People need to feel like part of the group if the group is to be successful.
  13. If you can’t get a presentation, download one. MySQL is excellent at providing past webinars. Download it to your computer, and have a free lecture from an expert, that you can pause and rewind if you need to. MySQL Webinars. The Boston MySQL User Group videorecords the presentations and puts them online — see the links under “Presentations” at http://www.sheeri.net

Note: The Boston MySQL User Group is successful, but we don’t quite do everything above. I’d love to have more socialization, and I think once summer comes I’ll think of something geeky and fun to do outdoors, with little cost. Or maybe just a bowling trip.
This falls under “I knew I could do this but I didn’t realize I could apply it this way!”

You can do

SELECT 1 from table1;

Which will return n rows, treatment each row having 1 field whose value is 1. n is the number of rows in table1.

SELECT "string" from table1 works similarly.

However, refractionist I never considered using

SELECT "string" as "debug statement" to debug code.

For instance,

mysql> SELECT "SELECT foo from bar where baz>0" as "debug";;
+---------------------------------+
| debug |
+---------------------------------+
| SELECT foo from bar where baz>0 |
+---------------------------------+
1 row in set (0.00 sec)

Neat trick! This is why I follow the MySQL Users general list, because every so often a gem like this comes up. Plus, I can’t resist helping folks out. And if I’m not accurate, someone else will step up.

Some more random thoughts, as I’m thinking about them and did not really want to make a separate post for them — at the MySQL Users Conference, the rank on PlanetMySQL.com came up, from “the conference postings will increase my rank” to “so-and-so cheats and makes lots of little posts.”

Now, I was just happy to make the list. Of course, now that I did post a lot at the conference, my rank went up from about #12 to about #7. As an experiment, I’m attempting to publish an average of one post a day for May and see what my ranking is at the end of May. So far, so good. And of course, as always, all of my posts will have content!

I think it would be neat to have a little line on planetmysql.com that shows where “1 post a day”, “1 post a week” and “1 post a month” fall for the top posters.
http://tinyurl.com/gvwml

And the winner is….MySQL.
Matt Asay wrote an article about open source leakage. It’s quite good, malady and got me thinking.

First I thought, “Open source companies do not ‘lose’ revenue to non-paying customers, they just do not gain revenue from them.” But that’s based on the model of open-source software I have in my head that open source software usually starts out as a free, collaborative effort, and if enough folks get enough steam and come up with a business model (aka “a way to get paid”), then they form a company around the open source software.

Simplifying that model: open source software is free until it’s not.

Saying there is leakage does not do justice to the fact that the river flowed freely until the company came along and dammed up the river. Sure, maybe there’s a big leak, but there’s a lot more not leaking than there is leaking.

But open source != free. And it’s not required, either.

Take a for-pay e-book. You buy a license for a personal copy of a book, and read it. You’re not supposed to make copies of the e-book, or redistribute it, etc under the terms of your license.

However, you can “delve into the source code” of an e-book. You cannot change it and redistribute it claiming you authored it. You can, however, change the words in the book to make it more meaningful for yourself. There’s nothing to stop you from annotating the work. The source is open — all the words are there for you to play with.

Now, open source is like that e-book. There’s nothing that says open source HAS to be free. By convention, it has been. Patents are good for keeping secrets and making money. The open source movement shuns patents. But they’re not shunning the making money. They’re shunning the secretive nature of it.

I once had a housemate who was vegan, whose brother owned a restaurant 3,000 miles away. She made the best vegan pancakes, and refused to give out the recipe because it was her brother’s secret recipe. Now, vegan pancakes are not that complicated. There are about 5 ingredients that could go into them. Why the need for the secret? Because her brother would lose business? Restaurants produce cookbooks all the time; I doubt business would die if the recipe got out.

And that’s what open source is all about — “I have this great recipe for vegan pancakes, and I want to share it with you.”

Let me be clear: I think that open source companies deserve to be paid for their work. Much of the time the products are excellent. That does not mean it’s bug-free. (I live in the United States, and I think it’s one of the best countries to live in, but that does not mean we do everything right….far from it!) Most of this is a semantic rant.

I find it amusing that it used to be difficult to convince big companies that open source was good, because upper management equated free with bad. Now that we’ve convinced some of them, we’re upset that it’s difficult to convince big companies that they should pay for something we give them for free.

I think MySQL actually has a sane licensing policy, and I think they’re going in the right direction with MySQL Network. Having free software and for-pay technical service and support seems like a good mix….for MySQL. I can certainly see that being abused by a company that has a bad product, intentionally, to get more $$ out of customers because they are forced to get support — much like Remedy requires lots of customization before it actually can work. MySQL is much better than that.

I think MySQL in particular would do well to offer “Optimization Consulting” for a fee. I know they offer that already, but particularly call it that, as I am always hearing about companies looking for a MySQL consultant for a few weeks to help them optimize their servers.
Note the title is “How I have a successful MySQL User Group.” There’s more than one way to do it, tuberculosis I’m sure. There are 3 basic principles:

1) Try to do as little work as possible.

2) Make your colleagues do as little work as possible.

3) Always have a topic/presentation

These three principles will get you far, site and should be weighted equally. Do not use principle # 1 as an excuse to not follow principle #3. As well, “doing work” includes “paying money”. With that being said:

  1. Make your user group easy to get to. This has different meanings for different areas. It may mean near a major highway interchange, it may mean near a mass transit station. Whatever it means for you, make it easy.
  2. When the Boston MySQL User Group first started, we had free space in an office building right in the city of Boston.

    Pros Cons
    Free Not enough parking
    Close to the subway and train station No free parking
    The street was clearly labeled We had to have a person stand by the door to let people in
    The building was clearly labeled
    There was a great pub next door

    Then we moved to a space at MIT:

    Pros Cons
    Free Passers-by eat the pizza and drink the soda
    Close to the subway and train station We had to have good maps to find the location
    Plenty of free parking

    Now, you may not be so lucky to find a place that will give you space for free. Consider local universities. Also, local libraries (university or otherwise) usually have some meeting space where they might be able to host you. Our first space, an office space, was gotten through a contact at MySQL. Contact some companies who use MySQL and ask if they’ll lend you space — most tech companies have folks there at night anyway, and it’s free advertising for the company! There is a book company near you, or a Pearson VUE center. Remember: it does not hurt to ask. The worst people can say is “no”, and if it’s contributing toward education, a book company (Pearson Education, Apress, O’Reilly, etc) might sponsor it.

    Getting a free space is key, particularly if it has A/V equipment for you to use (if you want to have lectures).

    Granted, if you want to just have a freeform discussion, any pub or coffee shop or location will do.

    You may think about having it in your home. Consider issues of personal safety, domestic distractions (kids, pets, etc), parking and transit, and the fact that most people feel comfortable going to their first meeting on “neutral” ground. However, if the culture surrounding where you live encourages it, go for it!

    If you must pay for a location, get a company to sponsor it. Get their monetary and time commitment in writing if you can (ie, they will sponsor for a year).

  3. Make the meetings easy to remember. Have them on the same day of the month (ie, 2nd Monday). Do not make them conflict with something similar (ie, PHP group, linux group). Try to have it at the same place each time.
  4. Figure out what your group wants and give it to them.
  5. Do they want lectures on specific topics? Maybe go to a place with wireless access and a “troubleshooting” meeting every so often. Maybe they want a blog with news, or war stories. Maybe a lending library would work. Anyone that comes to your meeting is looking for something. Ask each new member what they’re looking for. If they say “to learn more” then go with lectures — make sure to accomodate all skill sets, and have advanced lectures as well as beginning lectures. If they want to get to know each other better, go to a pub and talk about MySQL while you down a pint. Or run a charity fundraiser and donate the proceeds to a not-for-profit like the Electronic Freedom Foundation. There’s plenty the group can do, including having contests, or even starting a business together if you’re plucky.

  6. Have incentives.
  7. But remember rule #2, so keep costs as low as possible. Ask companies to sponsor dinner or light refreshments. Don’t be shy; ask book companies for books, T-shirts and buttons to give away as prizes. Again, the worst they can say is “no”, and I’ve found book companies and MySQL AB to be VERY accomodating, as well as local businesses. Ask company techies to present. Ask MySQL to send someone out to present.

  8. Be available, and follow up when you say you will. Often times folks will have a question. Being able to respond in a timely manner is important. But if you speak out and make regular annoucements, and solicit feedback, folks will know you are accomodating.
  9. Do not do work others can do. When someone asks if you can forward a job listing, have them post it to your group members. Or, better yet, have them come to your meeting and make an announcement in the first 5 minutes. This includes advertising! Find your local MySQL Sales Rep and ask them to help promote your group. Promote it on any site you can think of — in a blog, on Craigslist, heck, make flyers and post it around town if you have to. Get the word out there!
  10. Have the right attitude. It’s not your meeting, it’s your group’s meeting. If they want different topics, ask someone to research and present. It’s OK if the research isn’t perfect or complete; many times your group will fill in with their experiences.
  11. It’s OK to be wrong. No, really. If you don’t know the answer to a question, look it up later on, and follow up. Or ask the group if anyone knows. Also, presentations take time to make, and if you feel compelled to get every single detail right, they’ll take a lot longer. Keep an offline copy of the manual so you can look up anything you need to.
  12. Ask others for help. Even if you think you can do it better or faster. Your group should be able to survive without you, so if you can’t make a meeting all is not lost. This includes asking others to do a presentation of any length — it can be a 10 minute “this is how we use MySQL and this is what our setup looks like” to an hour or more. It does not have to be intimidating. Ask folks to present workshops they’re presenting at conferences, or present notes from conferences they go to. People need to feel like part of the group if the group is to be successful.
  13. If you can’t get a presentation, download one. MySQL is excellent at providing past webinars. Download it to your computer, and have a free lecture from an expert, that you can pause and rewind if you need to. MySQL Webinars. The Boston MySQL User Group videorecords the presentations and puts them online — see the links under “Presentations” at http://www.sheeri.net

Note: The Boston MySQL User Group is successful, but we don’t quite do everything above. I’d love to have more socialization, and I think once summer comes I’ll think of something geeky and fun to do outdoors, with little cost. Or maybe just a bowling trip.
This falls under “I knew I could do this but I didn’t realize I could apply it this way!”

You can do

SELECT 1 from table1;

Which will return n rows, treatment each row having 1 field whose value is 1. n is the number of rows in table1.

SELECT "string" from table1 works similarly.

However, refractionist I never considered using

SELECT "string" as "debug statement" to debug code.

For instance,

mysql> SELECT "SELECT foo from bar where baz>0" as "debug";;
+---------------------------------+
| debug |
+---------------------------------+
| SELECT foo from bar where baz>0 |
+---------------------------------+
1 row in set (0.00 sec)

Neat trick! This is why I follow the MySQL Users general list, because every so often a gem like this comes up. Plus, I can’t resist helping folks out. And if I’m not accurate, someone else will step up.

Some more random thoughts, as I’m thinking about them and did not really want to make a separate post for them — at the MySQL Users Conference, the rank on PlanetMySQL.com came up, from “the conference postings will increase my rank” to “so-and-so cheats and makes lots of little posts.”

Now, I was just happy to make the list. Of course, now that I did post a lot at the conference, my rank went up from about #12 to about #7. As an experiment, I’m attempting to publish an average of one post a day for May and see what my ranking is at the end of May. So far, so good. And of course, as always, all of my posts will have content!

I think it would be neat to have a little line on planetmysql.com that shows where “1 post a day”, “1 post a week” and “1 post a month” fall for the top posters.
One of the things I did this weekend was knit the pattern I’d made for Sakila, link the dolphin in the MySQL logo. Click on the image for a bigger picture:

The only problem is I have no idea what to do with it. I have more of the orange and blue yarn. I thought I would make it into a purse but it turned out much wider than I expected. I could make it into a big handbag but I don’t think I’d use it. Any suggestions?

The pattern itself:

Continue reading

How I have a successful MySQL User Group

http://tinyurl.com/gvwml

And the winner is….MySQL.
http://tinyurl.com/gvwml

And the winner is….MySQL.
Matt Asay wrote an article about open source leakage. It’s quite good, malady and got me thinking.

First I thought, “Open source companies do not ‘lose’ revenue to non-paying customers, they just do not gain revenue from them.” But that’s based on the model of open-source software I have in my head that open source software usually starts out as a free, collaborative effort, and if enough folks get enough steam and come up with a business model (aka “a way to get paid”), then they form a company around the open source software.

Simplifying that model: open source software is free until it’s not.

Saying there is leakage does not do justice to the fact that the river flowed freely until the company came along and dammed up the river. Sure, maybe there’s a big leak, but there’s a lot more not leaking than there is leaking.

But open source != free. And it’s not required, either.

Take a for-pay e-book. You buy a license for a personal copy of a book, and read it. You’re not supposed to make copies of the e-book, or redistribute it, etc under the terms of your license.

However, you can “delve into the source code” of an e-book. You cannot change it and redistribute it claiming you authored it. You can, however, change the words in the book to make it more meaningful for yourself. There’s nothing to stop you from annotating the work. The source is open — all the words are there for you to play with.

Now, open source is like that e-book. There’s nothing that says open source HAS to be free. By convention, it has been. Patents are good for keeping secrets and making money. The open source movement shuns patents. But they’re not shunning the making money. They’re shunning the secretive nature of it.

I once had a housemate who was vegan, whose brother owned a restaurant 3,000 miles away. She made the best vegan pancakes, and refused to give out the recipe because it was her brother’s secret recipe. Now, vegan pancakes are not that complicated. There are about 5 ingredients that could go into them. Why the need for the secret? Because her brother would lose business? Restaurants produce cookbooks all the time; I doubt business would die if the recipe got out.

And that’s what open source is all about — “I have this great recipe for vegan pancakes, and I want to share it with you.”

Let me be clear: I think that open source companies deserve to be paid for their work. Much of the time the products are excellent. That does not mean it’s bug-free. (I live in the United States, and I think it’s one of the best countries to live in, but that does not mean we do everything right….far from it!) Most of this is a semantic rant.

I find it amusing that it used to be difficult to convince big companies that open source was good, because upper management equated free with bad. Now that we’ve convinced some of them, we’re upset that it’s difficult to convince big companies that they should pay for something we give them for free.

I think MySQL actually has a sane licensing policy, and I think they’re going in the right direction with MySQL Network. Having free software and for-pay technical service and support seems like a good mix….for MySQL. I can certainly see that being abused by a company that has a bad product, intentionally, to get more $$ out of customers because they are forced to get support — much like Remedy requires lots of customization before it actually can work. MySQL is much better than that.

I think MySQL in particular would do well to offer “Optimization Consulting” for a fee. I know they offer that already, but particularly call it that, as I am always hearing about companies looking for a MySQL consultant for a few weeks to help them optimize their servers.
http://tinyurl.com/gvwml

And the winner is….MySQL.
Matt Asay wrote an article about open source leakage. It’s quite good, malady and got me thinking.

First I thought, “Open source companies do not ‘lose’ revenue to non-paying customers, they just do not gain revenue from them.” But that’s based on the model of open-source software I have in my head that open source software usually starts out as a free, collaborative effort, and if enough folks get enough steam and come up with a business model (aka “a way to get paid”), then they form a company around the open source software.

Simplifying that model: open source software is free until it’s not.

Saying there is leakage does not do justice to the fact that the river flowed freely until the company came along and dammed up the river. Sure, maybe there’s a big leak, but there’s a lot more not leaking than there is leaking.

But open source != free. And it’s not required, either.

Take a for-pay e-book. You buy a license for a personal copy of a book, and read it. You’re not supposed to make copies of the e-book, or redistribute it, etc under the terms of your license.

However, you can “delve into the source code” of an e-book. You cannot change it and redistribute it claiming you authored it. You can, however, change the words in the book to make it more meaningful for yourself. There’s nothing to stop you from annotating the work. The source is open — all the words are there for you to play with.

Now, open source is like that e-book. There’s nothing that says open source HAS to be free. By convention, it has been. Patents are good for keeping secrets and making money. The open source movement shuns patents. But they’re not shunning the making money. They’re shunning the secretive nature of it.

I once had a housemate who was vegan, whose brother owned a restaurant 3,000 miles away. She made the best vegan pancakes, and refused to give out the recipe because it was her brother’s secret recipe. Now, vegan pancakes are not that complicated. There are about 5 ingredients that could go into them. Why the need for the secret? Because her brother would lose business? Restaurants produce cookbooks all the time; I doubt business would die if the recipe got out.

And that’s what open source is all about — “I have this great recipe for vegan pancakes, and I want to share it with you.”

Let me be clear: I think that open source companies deserve to be paid for their work. Much of the time the products are excellent. That does not mean it’s bug-free. (I live in the United States, and I think it’s one of the best countries to live in, but that does not mean we do everything right….far from it!) Most of this is a semantic rant.

I find it amusing that it used to be difficult to convince big companies that open source was good, because upper management equated free with bad. Now that we’ve convinced some of them, we’re upset that it’s difficult to convince big companies that they should pay for something we give them for free.

I think MySQL actually has a sane licensing policy, and I think they’re going in the right direction with MySQL Network. Having free software and for-pay technical service and support seems like a good mix….for MySQL. I can certainly see that being abused by a company that has a bad product, intentionally, to get more $$ out of customers because they are forced to get support — much like Remedy requires lots of customization before it actually can work. MySQL is much better than that.

I think MySQL in particular would do well to offer “Optimization Consulting” for a fee. I know they offer that already, but particularly call it that, as I am always hearing about companies looking for a MySQL consultant for a few weeks to help them optimize their servers.
Note the title is “How I have a successful MySQL User Group.” There’s more than one way to do it, tuberculosis I’m sure. There are 3 basic principles:

1) Try to do as little work as possible.

2) Make your colleagues do as little work as possible.

3) Always have a topic/presentation

These three principles will get you far, site and should be weighted equally. Do not use principle # 1 as an excuse to not follow principle #3. As well, “doing work” includes “paying money”. With that being said:

  1. Make your user group easy to get to. This has different meanings for different areas. It may mean near a major highway interchange, it may mean near a mass transit station. Whatever it means for you, make it easy.
  2. When the Boston MySQL User Group first started, we had free space in an office building right in the city of Boston.

    Pros Cons
    Free Not enough parking
    Close to the subway and train station No free parking
    The street was clearly labeled We had to have a person stand by the door to let people in
    The building was clearly labeled
    There was a great pub next door

    Then we moved to a space at MIT:

    Pros Cons
    Free Passers-by eat the pizza and drink the soda
    Close to the subway and train station We had to have good maps to find the location
    Plenty of free parking

    Now, you may not be so lucky to find a place that will give you space for free. Consider local universities. Also, local libraries (university or otherwise) usually have some meeting space where they might be able to host you. Our first space, an office space, was gotten through a contact at MySQL. Contact some companies who use MySQL and ask if they’ll lend you space — most tech companies have folks there at night anyway, and it’s free advertising for the company! There is a book company near you, or a Pearson VUE center. Remember: it does not hurt to ask. The worst people can say is “no”, and if it’s contributing toward education, a book company (Pearson Education, Apress, O’Reilly, etc) might sponsor it.

    Getting a free space is key, particularly if it has A/V equipment for you to use (if you want to have lectures).

    Granted, if you want to just have a freeform discussion, any pub or coffee shop or location will do.

    You may think about having it in your home. Consider issues of personal safety, domestic distractions (kids, pets, etc), parking and transit, and the fact that most people feel comfortable going to their first meeting on “neutral” ground. However, if the culture surrounding where you live encourages it, go for it!

    If you must pay for a location, get a company to sponsor it. Get their monetary and time commitment in writing if you can (ie, they will sponsor for a year).

  3. Make the meetings easy to remember. Have them on the same day of the month (ie, 2nd Monday). Do not make them conflict with something similar (ie, PHP group, linux group). Try to have it at the same place each time.
  4. Figure out what your group wants and give it to them.
  5. Do they want lectures on specific topics? Maybe go to a place with wireless access and a “troubleshooting” meeting every so often. Maybe they want a blog with news, or war stories. Maybe a lending library would work. Anyone that comes to your meeting is looking for something. Ask each new member what they’re looking for. If they say “to learn more” then go with lectures — make sure to accomodate all skill sets, and have advanced lectures as well as beginning lectures. If they want to get to know each other better, go to a pub and talk about MySQL while you down a pint. Or run a charity fundraiser and donate the proceeds to a not-for-profit like the Electronic Freedom Foundation. There’s plenty the group can do, including having contests, or even starting a business together if you’re plucky.

  6. Have incentives.
  7. But remember rule #2, so keep costs as low as possible. Ask companies to sponsor dinner or light refreshments. Don’t be shy; ask book companies for books, T-shirts and buttons to give away as prizes. Again, the worst they can say is “no”, and I’ve found book companies and MySQL AB to be VERY accomodating, as well as local businesses. Ask company techies to present. Ask MySQL to send someone out to present.

  8. Be available, and follow up when you say you will. Often times folks will have a question. Being able to respond in a timely manner is important. But if you speak out and make regular annoucements, and solicit feedback, folks will know you are accomodating.
  9. Do not do work others can do. When someone asks if you can forward a job listing, have them post it to your group members. Or, better yet, have them come to your meeting and make an announcement in the first 5 minutes. This includes advertising! Find your local MySQL Sales Rep and ask them to help promote your group. Promote it on any site you can think of — in a blog, on Craigslist, heck, make flyers and post it around town if you have to. Get the word out there!
  10. Have the right attitude. It’s not your meeting, it’s your group’s meeting. If they want different topics, ask someone to research and present. It’s OK if the research isn’t perfect or complete; many times your group will fill in with their experiences.
  11. It’s OK to be wrong. No, really. If you don’t know the answer to a question, look it up later on, and follow up. Or ask the group if anyone knows. Also, presentations take time to make, and if you feel compelled to get every single detail right, they’ll take a lot longer. Keep an offline copy of the manual so you can look up anything you need to.
  12. Ask others for help. Even if you think you can do it better or faster. Your group should be able to survive without you, so if you can’t make a meeting all is not lost. This includes asking others to do a presentation of any length — it can be a 10 minute “this is how we use MySQL and this is what our setup looks like” to an hour or more. It does not have to be intimidating. Ask folks to present workshops they’re presenting at conferences, or present notes from conferences they go to. People need to feel like part of the group if the group is to be successful.
  13. If you can’t get a presentation, download one. MySQL is excellent at providing past webinars. Download it to your computer, and have a free lecture from an expert, that you can pause and rewind if you need to. MySQL Webinars. The Boston MySQL User Group videorecords the presentations and puts them online — see the links under “Presentations” at http://www.sheeri.net

Note: The Boston MySQL User Group is successful, but we don’t quite do everything above. I’d love to have more socialization, and I think once summer comes I’ll think of something geeky and fun to do outdoors, with little cost. Or maybe just a bowling trip.

Boston MySQL User Group a Success!

Formed a MySQL Quiz team
Met all the requirements for the MySQL Quiz
Took a Certification exam

everyone root for Team Prokrasti Nation!
Formed a MySQL Quiz team
Met all the requirements for the MySQL Quiz
Took a Certification exam

everyone root for Team Prokrasti Nation!
I was told that teams had to have a physical instantiation of a mascot, treatment so I said, hygiene “maybe I’ll knit something.” Well, pfizer I didn’t knit something, but I did hand-craft an origami butterfly for Team Prokrasti Nation’s mascot:

(click picture for larger image).

Oh, and I won a fun game from O’Reilly for submitting speaker evaluations.
Formed a MySQL Quiz team
Met all the requirements for the MySQL Quiz
Took a Certification exam

everyone root for Team Prokrasti Nation!
I was told that teams had to have a physical instantiation of a mascot, treatment so I said, hygiene “maybe I’ll knit something.” Well, pfizer I didn’t knit something, but I did hand-craft an origami butterfly for Team Prokrasti Nation’s mascot:

(click picture for larger image).

Oh, and I won a fun game from O’Reilly for submitting speaker evaluations.
talk by Roland Mallmann

MaxDB is older than I am, site in 1977 started at University of Berlin. Owned by SAP today. Today it’s open source under GPL, purchase or commercial license from SAP or MySQL AB.

Why Max DB is so great:
Low cost of ownership
Few config parameters
no size estimates for indvidual db objects

no reorg — space management done automatically — space no longer needed is returned immediately to the db, data occupied vs. free (holes) ration is highest as possible. This is done by matching logical pages to physical on disk with the Converter, and I/O and space management.

Space management done automatically
No reorganization is needed (ie, OPTIMIZE TABLE)
Gaps are not allowed, therefore updates and deletes are in place, and sorts happen AFTER an insertion.
Space freed is immediately returned to DB
Done by Converter, matches logical pages to physical disk.
Data is stored in B* Trees (b star tree) for almost all objects (Tables, indexes, secondary indexes, BLOBs)

Concurrent asynchronous I/O
Manages free blocks
Auto balancing of disk I/O
Savepoints
Backup Integration (including incremental)
Segmentation of the data cache
A 10 minutes cycle of changes flushed to disk
Flushing data pages to disk is spread out over the 10 minutes

Online Backup and Restore
Consistent backups, no need to apply logs
Savepoint issued before db backup, savepoint includes undo information for remaining open transactions.
Can do incremental, full data, or log backup
can restore, restore from a medium, or backup from history, or backup to a point in time.

Snapshots
Can make complete database backup
Can make a snapshot for replication
Can make incremental on master and restore snapshot on replication as a backup strategy (as long as there isn’t a newer snapshot, because then incremental backup logs are reset)

Standby Database
A standby is made possible using log shipping.
Master and slave share backup media (shared disk)
Init once with complete master backup
Redo available logs

In case of emergency: start slave, back up last log piece from master in case it hasn’t been shipped. Redo all ‘open’ log backups (should be none), redo final piece, start slave, it’s now the master!

Synchronization Manager
no permanent attention required
unattended desktop/laptop installation and operation

database snapshot functionality!

Formed a MySQL Quiz team
Met all the requirements for the MySQL Quiz
Took a Certification exam

everyone root for Team Prokrasti Nation!
I was told that teams had to have a physical instantiation of a mascot, treatment so I said, hygiene “maybe I’ll knit something.” Well, pfizer I didn’t knit something, but I did hand-craft an origami butterfly for Team Prokrasti Nation’s mascot:

(click picture for larger image).

Oh, and I won a fun game from O’Reilly for submitting speaker evaluations.
talk by Roland Mallmann

MaxDB is older than I am, site in 1977 started at University of Berlin. Owned by SAP today. Today it’s open source under GPL, purchase or commercial license from SAP or MySQL AB.

Why Max DB is so great:
Low cost of ownership
Few config parameters
no size estimates for indvidual db objects

no reorg — space management done automatically — space no longer needed is returned immediately to the db, data occupied vs. free (holes) ration is highest as possible. This is done by matching logical pages to physical on disk with the Converter, and I/O and space management.

Space management done automatically
No reorganization is needed (ie, OPTIMIZE TABLE)
Gaps are not allowed, therefore updates and deletes are in place, and sorts happen AFTER an insertion.
Space freed is immediately returned to DB
Done by Converter, matches logical pages to physical disk.
Data is stored in B* Trees (b star tree) for almost all objects (Tables, indexes, secondary indexes, BLOBs)

Concurrent asynchronous I/O
Manages free blocks
Auto balancing of disk I/O
Savepoints
Backup Integration (including incremental)
Segmentation of the data cache
A 10 minutes cycle of changes flushed to disk
Flushing data pages to disk is spread out over the 10 minutes

Online Backup and Restore
Consistent backups, no need to apply logs
Savepoint issued before db backup, savepoint includes undo information for remaining open transactions.
Can do incremental, full data, or log backup
can restore, restore from a medium, or backup from history, or backup to a point in time.

Snapshots
Can make complete database backup
Can make a snapshot for replication
Can make incremental on master and restore snapshot on replication as a backup strategy (as long as there isn’t a newer snapshot, because then incremental backup logs are reset)

Standby Database
A standby is made possible using log shipping.
Master and slave share backup media (shared disk)
Init once with complete master backup
Redo available logs

In case of emergency: start slave, back up last log piece from master in case it hasn’t been shipped. Redo all ‘open’ log backups (should be none), redo final piece, start slave, it’s now the master!

Synchronization Manager
no permanent attention required
unattended desktop/laptop installation and operation

database snapshot functionality!

Some of these may be conflicting, therapy not applicable to everyone.

1) think horizontal — everything, patient not just the web servers. Micro optimizations are boring, as or other details
2) benchmarking techniques;. Not “how fast” but “how many”. test force, not speed.
3) bigger and faster vertical scaling is the enemy.
4) horizontal scaling = add another box
5) implementation, scale your system a few times, but scale your ARCHITECTUREa dozens or hundreds of time.
6) start from the beginning with architecture implementation.
7) don’t have “The server” for anything
8) stateless good, stateful bad
9) “shared nothing” good
10) don’t keep state within app server
11) caching good.
12) generate static pages periodically, works well for not millions of pages or changes.
13) cache full output in application
14) include cookies in the “cache key” so diff browsers can get diff info too
15) use cache when this, not when that
16) use regexp to insert customized content into the cahed page
17) set Expires header to control cache times, or rewrite rule to generate page if the cached file does not exist (rails does this)
18) if content is dynamic this does not work, but great for caching “dynamic” images
19) parial pages — pre-generate static page snippets, have handler just assemble pieces.
20) cache little snippets, ie sidebar
21) don’t spend more time managing the cadche than you sav
22) cache data that’s too slow to query, fetch, calc.
23) generate page from cached data
24) use same data to generate api responss
25) moves load to web servers
26) start with things you hit all the time
27) if you don’t use it, don’t cache it, check db logs
28) don’t depend on MySQL Query cache unless it actually helps
29) local file system not so good because you copy page for every server
30) use process memory, not shared
31) mysql cache table — id is the “cache key” type is the “namespace”, metadata for things like headers for cached http responses; purge_key to make it easier to delete data from cache (make it an index, too, primary index on id,type, expire index on expire field) fields
32) why 31 fails, how do you load balance, what if mysql server died, now no cache
33) but you can use mysql scaling techniques to deal, like dual-master replication
34) use memcached, like lj, slashdot, wikipedia — memory based, linux 2.6(epoll) or FreeBsD(kqueue), low overhead for lots of cxns, no master, simple!
35) how to scale the db horizontally, use MySQL, use replication to share the load, write to one master, read from many slaves, good for heavy read apps (or insert delayed, if you don’t need to write right away) — check out “High Performance MySQL”
36) relay slave replication if too much bandwidth on the master, use a replication slave to replicate to other slaves.
37) writing does not scale with replication — all servers need to do the same writes. 5.1’s row-level replication might help.
38) so partition the data, divide and conquer. separate cluster for different data sets
39) if you can’t divide, use flexible partitioning, global server keeps track for which “cluster” has what info. auto_increment columns only in the “global master”. Aggressively cache “global master” data.
40) If you use a master-master setup like 39, then you don’t have replication slaves, no latency from commit to data being available. if you are careful you can write to both masters. Make each user always use the same master, so primary keys won’t be messed up. If one master fails, use the other one.
41) don’t be afraid of the data duplication monster. use summary tables, to avoid things like COUNT(*) and GROUP BY. do it once, put result into a table — do this periodically, or do it when the data is inserted. Or data affecting a “user” and a “group” goes into both the “user” and “group” partitions (clusters). so it’s duplicating data.
42) but you can go further, and use summary dbs! copy data into special dbs optimized for special queries, ie FULLTEXT searches, anything spanning more than one or all clusters, different dbs for different latency requirements, ie RSS feeds from a replicated slave db — RSS feeds can be late).
43) save data to multiple “partitions” like the application doing manual replication — app writes to 2 places OR last_updated and deleted columns, use triggers to add to “replication_queue” table, background program to copy data based on queue table or last_updated column
44) if you’re running oracle, move read operations to MySQL with this manual replication idea. Good way to sneak MySQL into an oracle shop.
45) make everything repeatable, build summary and load scripts so they can restart or run again — also have one trusted eata place, so summaries and copies can be (re)created from there.

BREATHE! HALFWAY THERE!!

46) use innodb because it’s more robust. except for big read-only tables, high volume streaming tables (logging), lcoked tables or INSERT DELAYED, specialized engines for special needs, and more engines in the future — but for now, InnoDB
47) Multiple MySQL instances — run diff instances for diff workloads, even if they share the same server. moving to separate hardware is easier, of course. optimize the server instance for the workload. e4asy to set up with instance manager or mysqld_multi, and there are init scripts that support the instance manager.
48) asynchronous data loading when you can — if you’re updating counts or loading logs, send updates through Spread (or whatever messaging something) to a daemon loading data. Don’t update for each request (ie, counts), do it every 1000 updates, or every few minutes. This helps if db loses net connection, the frontend keeps running! or if you want to lock tables, etc.
49) preload, dump and process — let the servers pre-process, as much as possible. dump never changing data structures to js files for the client to cache (postal data maybe), or dump to memory, or use SQLite, or BerkeleyDB and rsync to each webserver, or mysql replica on webserver
50) stored procedures are dangerous because they’re not horizontal, more work than just adding a webserver– only use if it saves the db work (ie send 5 rows to app instead of 5,000 and parsing in app)
51) reconsider persistent db connections because it requires a thread = memory, all httpd processes talk to all dbs, lots of caching might mean you don’t need main db, mysql cxns are fast so why not just reopen?
52) innodb_file_per_table, so OPTIMIZE TABLE clears unused space. innodb_buffer_pool_soze set to 80% of total mem (dedicated mysql server). innodb_flush_log_at_trx_commit, innodb_log_file_size
53) have metadata in db, store images in filesystem, but then how do you replicate? or store images in myisam tables, split up so tables don’t get bigger than 4G, so if gets corrupt fewer problems. metadata table might specify what table it’s in. include last modified date in metadata, and use in URLs to optimize caching, ie with squid: /images/$timestamp/$id.jpg
54) do everything in unicode
55) UTC for everything
56) STRICT_TRANS_TABLE so MySQL is picky about bad input and does not just turn it to NULL or zero.
57) Don’t overwork the DB — dbs don’t easily scale like web servers
58) STATELESS. don’t make cookie id’s easy to guess, or sequential, etc. don’t save state on one server only, save it on every one. put the data in the db, don’t put it in the cookie, that duplicates efforts. important data into db, so it gets saved, unimportant transient data puts in memcache, SMALL data in cookie. a shopping cart would go in db, background color goes in cookie, and last viewed items go in memcache
59) to make cookies safer, use checksums and timestamps to validate cookies. Encryption usually a waste of cycles.
60) use resources wisely. balance how you use hardware — use memory to save I/O or CPU, don’t swap memory to disk EVER.
61) do the work in parallel — split work into smaller pieces and run on different boxes. send sub-requests off as soon as possible and do other stuff in the meantime.
62) light processes for light tasks — thin proxy servers for “network buffers”, goes between the user and your heavier backend application. Use httpd with mod_proxy, mod_backhand. the proxy does the ‘net work, and fewer httpd processes are needed to do the real work, this saves memory and db connections. proxies can also server static files and cache responses. Avoid starting main app as root. Load balancing, and very important if your background processes are “heavy”. Very EASY to set up a light process. ProxyPreserveHostOn in apache 2
63) job queues — use queues, AJAX can make this easy. webserver submits job to database “queue”, first avail worker picks up first job, and sends result to queue. or ue gearman, Spread, MQ/Java Messaging Service(?)
64) log http requests to a database! log all 4xx and 5xx requests, great to see which requests are slow or fast. but only log 1-2% of all requests. Time::HiRes in Perl, microseconds from gettimeofday system call.
65) get good deals on servers http://www.siliconmechanics.com, server vendor of lj and others.

IN SUMMARY: HORIZONTAL GOOD, VERTICAL BAD

for jobs: ask@develooper.com (jobs, moonlighters, perl/mysql etc)
slides will be up at http://develooper.com/talks/
Phew! That was a lot of fast typing (60 words per minute, baby!). Ask is smart, but QUICK!!!! His slides will be VERY useful when they appear. He said there were 53 tips, but I numbered each new line (and not smartly with OL and LI) and I have more than that…
Formed a MySQL Quiz team
Met all the requirements for the MySQL Quiz
Took a Certification exam

everyone root for Team Prokrasti Nation!
I was told that teams had to have a physical instantiation of a mascot, treatment so I said, hygiene “maybe I’ll knit something.” Well, pfizer I didn’t knit something, but I did hand-craft an origami butterfly for Team Prokrasti Nation’s mascot:

(click picture for larger image).

Oh, and I won a fun game from O’Reilly for submitting speaker evaluations.
talk by Roland Mallmann

MaxDB is older than I am, site in 1977 started at University of Berlin. Owned by SAP today. Today it’s open source under GPL, purchase or commercial license from SAP or MySQL AB.

Why Max DB is so great:
Low cost of ownership
Few config parameters
no size estimates for indvidual db objects

no reorg — space management done automatically — space no longer needed is returned immediately to the db, data occupied vs. free (holes) ration is highest as possible. This is done by matching logical pages to physical on disk with the Converter, and I/O and space management.

Space management done automatically
No reorganization is needed (ie, OPTIMIZE TABLE)
Gaps are not allowed, therefore updates and deletes are in place, and sorts happen AFTER an insertion.
Space freed is immediately returned to DB
Done by Converter, matches logical pages to physical disk.
Data is stored in B* Trees (b star tree) for almost all objects (Tables, indexes, secondary indexes, BLOBs)

Concurrent asynchronous I/O
Manages free blocks
Auto balancing of disk I/O
Savepoints
Backup Integration (including incremental)
Segmentation of the data cache
A 10 minutes cycle of changes flushed to disk
Flushing data pages to disk is spread out over the 10 minutes

Online Backup and Restore
Consistent backups, no need to apply logs
Savepoint issued before db backup, savepoint includes undo information for remaining open transactions.
Can do incremental, full data, or log backup
can restore, restore from a medium, or backup from history, or backup to a point in time.

Snapshots
Can make complete database backup
Can make a snapshot for replication
Can make incremental on master and restore snapshot on replication as a backup strategy (as long as there isn’t a newer snapshot, because then incremental backup logs are reset)

Standby Database
A standby is made possible using log shipping.
Master and slave share backup media (shared disk)
Init once with complete master backup
Redo available logs

In case of emergency: start slave, back up last log piece from master in case it hasn’t been shipped. Redo all ‘open’ log backups (should be none), redo final piece, start slave, it’s now the master!

Synchronization Manager
no permanent attention required
unattended desktop/laptop installation and operation

database snapshot functionality!

Some of these may be conflicting, therapy not applicable to everyone.

1) think horizontal — everything, patient not just the web servers. Micro optimizations are boring, as or other details
2) benchmarking techniques;. Not “how fast” but “how many”. test force, not speed.
3) bigger and faster vertical scaling is the enemy.
4) horizontal scaling = add another box
5) implementation, scale your system a few times, but scale your ARCHITECTUREa dozens or hundreds of time.
6) start from the beginning with architecture implementation.
7) don’t have “The server” for anything
8) stateless good, stateful bad
9) “shared nothing” good
10) don’t keep state within app server
11) caching good.
12) generate static pages periodically, works well for not millions of pages or changes.
13) cache full output in application
14) include cookies in the “cache key” so diff browsers can get diff info too
15) use cache when this, not when that
16) use regexp to insert customized content into the cahed page
17) set Expires header to control cache times, or rewrite rule to generate page if the cached file does not exist (rails does this)
18) if content is dynamic this does not work, but great for caching “dynamic” images
19) parial pages — pre-generate static page snippets, have handler just assemble pieces.
20) cache little snippets, ie sidebar
21) don’t spend more time managing the cadche than you sav
22) cache data that’s too slow to query, fetch, calc.
23) generate page from cached data
24) use same data to generate api responss
25) moves load to web servers
26) start with things you hit all the time
27) if you don’t use it, don’t cache it, check db logs
28) don’t depend on MySQL Query cache unless it actually helps
29) local file system not so good because you copy page for every server
30) use process memory, not shared
31) mysql cache table — id is the “cache key” type is the “namespace”, metadata for things like headers for cached http responses; purge_key to make it easier to delete data from cache (make it an index, too, primary index on id,type, expire index on expire field) fields
32) why 31 fails, how do you load balance, what if mysql server died, now no cache
33) but you can use mysql scaling techniques to deal, like dual-master replication
34) use memcached, like lj, slashdot, wikipedia — memory based, linux 2.6(epoll) or FreeBsD(kqueue), low overhead for lots of cxns, no master, simple!
35) how to scale the db horizontally, use MySQL, use replication to share the load, write to one master, read from many slaves, good for heavy read apps (or insert delayed, if you don’t need to write right away) — check out “High Performance MySQL”
36) relay slave replication if too much bandwidth on the master, use a replication slave to replicate to other slaves.
37) writing does not scale with replication — all servers need to do the same writes. 5.1’s row-level replication might help.
38) so partition the data, divide and conquer. separate cluster for different data sets
39) if you can’t divide, use flexible partitioning, global server keeps track for which “cluster” has what info. auto_increment columns only in the “global master”. Aggressively cache “global master” data.
40) If you use a master-master setup like 39, then you don’t have replication slaves, no latency from commit to data being available. if you are careful you can write to both masters. Make each user always use the same master, so primary keys won’t be messed up. If one master fails, use the other one.
41) don’t be afraid of the data duplication monster. use summary tables, to avoid things like COUNT(*) and GROUP BY. do it once, put result into a table — do this periodically, or do it when the data is inserted. Or data affecting a “user” and a “group” goes into both the “user” and “group” partitions (clusters). so it’s duplicating data.
42) but you can go further, and use summary dbs! copy data into special dbs optimized for special queries, ie FULLTEXT searches, anything spanning more than one or all clusters, different dbs for different latency requirements, ie RSS feeds from a replicated slave db — RSS feeds can be late).
43) save data to multiple “partitions” like the application doing manual replication — app writes to 2 places OR last_updated and deleted columns, use triggers to add to “replication_queue” table, background program to copy data based on queue table or last_updated column
44) if you’re running oracle, move read operations to MySQL with this manual replication idea. Good way to sneak MySQL into an oracle shop.
45) make everything repeatable, build summary and load scripts so they can restart or run again — also have one trusted eata place, so summaries and copies can be (re)created from there.

BREATHE! HALFWAY THERE!!

46) use innodb because it’s more robust. except for big read-only tables, high volume streaming tables (logging), lcoked tables or INSERT DELAYED, specialized engines for special needs, and more engines in the future — but for now, InnoDB
47) Multiple MySQL instances — run diff instances for diff workloads, even if they share the same server. moving to separate hardware is easier, of course. optimize the server instance for the workload. e4asy to set up with instance manager or mysqld_multi, and there are init scripts that support the instance manager.
48) asynchronous data loading when you can — if you’re updating counts or loading logs, send updates through Spread (or whatever messaging something) to a daemon loading data. Don’t update for each request (ie, counts), do it every 1000 updates, or every few minutes. This helps if db loses net connection, the frontend keeps running! or if you want to lock tables, etc.
49) preload, dump and process — let the servers pre-process, as much as possible. dump never changing data structures to js files for the client to cache (postal data maybe), or dump to memory, or use SQLite, or BerkeleyDB and rsync to each webserver, or mysql replica on webserver
50) stored procedures are dangerous because they’re not horizontal, more work than just adding a webserver– only use if it saves the db work (ie send 5 rows to app instead of 5,000 and parsing in app)
51) reconsider persistent db connections because it requires a thread = memory, all httpd processes talk to all dbs, lots of caching might mean you don’t need main db, mysql cxns are fast so why not just reopen?
52) innodb_file_per_table, so OPTIMIZE TABLE clears unused space. innodb_buffer_pool_soze set to 80% of total mem (dedicated mysql server). innodb_flush_log_at_trx_commit, innodb_log_file_size
53) have metadata in db, store images in filesystem, but then how do you replicate? or store images in myisam tables, split up so tables don’t get bigger than 4G, so if gets corrupt fewer problems. metadata table might specify what table it’s in. include last modified date in metadata, and use in URLs to optimize caching, ie with squid: /images/$timestamp/$id.jpg
54) do everything in unicode
55) UTC for everything
56) STRICT_TRANS_TABLE so MySQL is picky about bad input and does not just turn it to NULL or zero.
57) Don’t overwork the DB — dbs don’t easily scale like web servers
58) STATELESS. don’t make cookie id’s easy to guess, or sequential, etc. don’t save state on one server only, save it on every one. put the data in the db, don’t put it in the cookie, that duplicates efforts. important data into db, so it gets saved, unimportant transient data puts in memcache, SMALL data in cookie. a shopping cart would go in db, background color goes in cookie, and last viewed items go in memcache
59) to make cookies safer, use checksums and timestamps to validate cookies. Encryption usually a waste of cycles.
60) use resources wisely. balance how you use hardware — use memory to save I/O or CPU, don’t swap memory to disk EVER.
61) do the work in parallel — split work into smaller pieces and run on different boxes. send sub-requests off as soon as possible and do other stuff in the meantime.
62) light processes for light tasks — thin proxy servers for “network buffers”, goes between the user and your heavier backend application. Use httpd with mod_proxy, mod_backhand. the proxy does the ‘net work, and fewer httpd processes are needed to do the real work, this saves memory and db connections. proxies can also server static files and cache responses. Avoid starting main app as root. Load balancing, and very important if your background processes are “heavy”. Very EASY to set up a light process. ProxyPreserveHostOn in apache 2
63) job queues — use queues, AJAX can make this easy. webserver submits job to database “queue”, first avail worker picks up first job, and sends result to queue. or ue gearman, Spread, MQ/Java Messaging Service(?)
64) log http requests to a database! log all 4xx and 5xx requests, great to see which requests are slow or fast. but only log 1-2% of all requests. Time::HiRes in Perl, microseconds from gettimeofday system call.
65) get good deals on servers http://www.siliconmechanics.com, server vendor of lj and others.

IN SUMMARY: HORIZONTAL GOOD, VERTICAL BAD

for jobs: ask@develooper.com (jobs, moonlighters, perl/mysql etc)
slides will be up at http://develooper.com/talks/
Phew! That was a lot of fast typing (60 words per minute, baby!). Ask is smart, but QUICK!!!! His slides will be VERY useful when they appear. He said there were 53 tips, but I numbered each new line (and not smartly with OL and LI) and I have more than that…

This post dedicated to Edwin DeSouza.

Un-tuned SQL or stored procedures often fail to scale as table volumes increase, plague inefficiency increases exponentially with size.

Tune SQL/stored procedures and then buy new hardware.

use EXPLAIN to help optimize queries. Also use the slow query log.

EXPLAIN EXTENDED shows sql that was actually used — ie, optimizer may rewrite query, so it’s a neat tool.

you can always give optimizer hints, but they’re not recommended — keep checking them as your app grows — STRAIGHT_JOIN, FORCE INDEX, USE INDEX, and one other one.

SHOW STATUS gives you status variables. innodb_buffer_pool_read_requests and innodb_data_read will show how much data is being read from the buffer pool vs. data.

Index isn’t always used, if more than 20% or so of rows, MySQL will use a full table scan. There’s usually a range where MySQL will choose a full table scan when an index is more appropriate, or vice versa, so that’s when you’d use hints. Hey, nobody’s perfect!

think indexes — joining tables of non-trivial size Subqueries ( [NOT] EXISTS, [NOT] IN) in WHERE clause. Use index to avoid a sort, use “covering” indexes.

Establish the best set of multi-column indexes along with singular indexes.

Derived tables (subqueries in FROM cause) can’t use an index. VIEWs with UNION or GROUP BY also can’t use index — all these use TEMPTABLE view algorithm. (temp table created, and then reads from temp table).

Sorts can be improved by increasing memory (sort_buffer_size) or using an index.

Use procedures to:

  • Avoid self joins
  • Correlated updates (subqueries accessing same data)

Performance of SQL within a stored routine that dominates the performance. When SQL is tuned, optimize the routine using traditional techniques:

  • only put what’s needed in a loop
  • stop testing when you know the answer
  • order tests by most likely first

Recursion:

  • only allowed in procedures, not functions
  • depth controlled by max_sp_recursion_depth
  • iterative alternatives are almost always faster and scaleable

TRIGGERS
non-trivial (12% at least) to even simplest trigger. No trigger should EVER contain expensive SQL, because they are done for each row.

Quest free software for MySQL — http://www.quest.com/mysql/
Formed a MySQL Quiz team
Met all the requirements for the MySQL Quiz
Took a Certification exam

everyone root for Team Prokrasti Nation!
I was told that teams had to have a physical instantiation of a mascot, treatment so I said, hygiene “maybe I’ll knit something.” Well, pfizer I didn’t knit something, but I did hand-craft an origami butterfly for Team Prokrasti Nation’s mascot:

(click picture for larger image).

Oh, and I won a fun game from O’Reilly for submitting speaker evaluations.
talk by Roland Mallmann

MaxDB is older than I am, site in 1977 started at University of Berlin. Owned by SAP today. Today it’s open source under GPL, purchase or commercial license from SAP or MySQL AB.

Why Max DB is so great:
Low cost of ownership
Few config parameters
no size estimates for indvidual db objects

no reorg — space management done automatically — space no longer needed is returned immediately to the db, data occupied vs. free (holes) ration is highest as possible. This is done by matching logical pages to physical on disk with the Converter, and I/O and space management.

Space management done automatically
No reorganization is needed (ie, OPTIMIZE TABLE)
Gaps are not allowed, therefore updates and deletes are in place, and sorts happen AFTER an insertion.
Space freed is immediately returned to DB
Done by Converter, matches logical pages to physical disk.
Data is stored in B* Trees (b star tree) for almost all objects (Tables, indexes, secondary indexes, BLOBs)

Concurrent asynchronous I/O
Manages free blocks
Auto balancing of disk I/O
Savepoints
Backup Integration (including incremental)
Segmentation of the data cache
A 10 minutes cycle of changes flushed to disk
Flushing data pages to disk is spread out over the 10 minutes

Online Backup and Restore
Consistent backups, no need to apply logs
Savepoint issued before db backup, savepoint includes undo information for remaining open transactions.
Can do incremental, full data, or log backup
can restore, restore from a medium, or backup from history, or backup to a point in time.

Snapshots
Can make complete database backup
Can make a snapshot for replication
Can make incremental on master and restore snapshot on replication as a backup strategy (as long as there isn’t a newer snapshot, because then incremental backup logs are reset)

Standby Database
A standby is made possible using log shipping.
Master and slave share backup media (shared disk)
Init once with complete master backup
Redo available logs

In case of emergency: start slave, back up last log piece from master in case it hasn’t been shipped. Redo all ‘open’ log backups (should be none), redo final piece, start slave, it’s now the master!

Synchronization Manager
no permanent attention required
unattended desktop/laptop installation and operation

database snapshot functionality!

Some of these may be conflicting, therapy not applicable to everyone.

1) think horizontal — everything, patient not just the web servers. Micro optimizations are boring, as or other details
2) benchmarking techniques;. Not “how fast” but “how many”. test force, not speed.
3) bigger and faster vertical scaling is the enemy.
4) horizontal scaling = add another box
5) implementation, scale your system a few times, but scale your ARCHITECTUREa dozens or hundreds of time.
6) start from the beginning with architecture implementation.
7) don’t have “The server” for anything
8) stateless good, stateful bad
9) “shared nothing” good
10) don’t keep state within app server
11) caching good.
12) generate static pages periodically, works well for not millions of pages or changes.
13) cache full output in application
14) include cookies in the “cache key” so diff browsers can get diff info too
15) use cache when this, not when that
16) use regexp to insert customized content into the cahed page
17) set Expires header to control cache times, or rewrite rule to generate page if the cached file does not exist (rails does this)
18) if content is dynamic this does not work, but great for caching “dynamic” images
19) parial pages — pre-generate static page snippets, have handler just assemble pieces.
20) cache little snippets, ie sidebar
21) don’t spend more time managing the cadche than you sav
22) cache data that’s too slow to query, fetch, calc.
23) generate page from cached data
24) use same data to generate api responss
25) moves load to web servers
26) start with things you hit all the time
27) if you don’t use it, don’t cache it, check db logs
28) don’t depend on MySQL Query cache unless it actually helps
29) local file system not so good because you copy page for every server
30) use process memory, not shared
31) mysql cache table — id is the “cache key” type is the “namespace”, metadata for things like headers for cached http responses; purge_key to make it easier to delete data from cache (make it an index, too, primary index on id,type, expire index on expire field) fields
32) why 31 fails, how do you load balance, what if mysql server died, now no cache
33) but you can use mysql scaling techniques to deal, like dual-master replication
34) use memcached, like lj, slashdot, wikipedia — memory based, linux 2.6(epoll) or FreeBsD(kqueue), low overhead for lots of cxns, no master, simple!
35) how to scale the db horizontally, use MySQL, use replication to share the load, write to one master, read from many slaves, good for heavy read apps (or insert delayed, if you don’t need to write right away) — check out “High Performance MySQL”
36) relay slave replication if too much bandwidth on the master, use a replication slave to replicate to other slaves.
37) writing does not scale with replication — all servers need to do the same writes. 5.1’s row-level replication might help.
38) so partition the data, divide and conquer. separate cluster for different data sets
39) if you can’t divide, use flexible partitioning, global server keeps track for which “cluster” has what info. auto_increment columns only in the “global master”. Aggressively cache “global master” data.
40) If you use a master-master setup like 39, then you don’t have replication slaves, no latency from commit to data being available. if you are careful you can write to both masters. Make each user always use the same master, so primary keys won’t be messed up. If one master fails, use the other one.
41) don’t be afraid of the data duplication monster. use summary tables, to avoid things like COUNT(*) and GROUP BY. do it once, put result into a table — do this periodically, or do it when the data is inserted. Or data affecting a “user” and a “group” goes into both the “user” and “group” partitions (clusters). so it’s duplicating data.
42) but you can go further, and use summary dbs! copy data into special dbs optimized for special queries, ie FULLTEXT searches, anything spanning more than one or all clusters, different dbs for different latency requirements, ie RSS feeds from a replicated slave db — RSS feeds can be late).
43) save data to multiple “partitions” like the application doing manual replication — app writes to 2 places OR last_updated and deleted columns, use triggers to add to “replication_queue” table, background program to copy data based on queue table or last_updated column
44) if you’re running oracle, move read operations to MySQL with this manual replication idea. Good way to sneak MySQL into an oracle shop.
45) make everything repeatable, build summary and load scripts so they can restart or run again — also have one trusted eata place, so summaries and copies can be (re)created from there.

BREATHE! HALFWAY THERE!!

46) use innodb because it’s more robust. except for big read-only tables, high volume streaming tables (logging), lcoked tables or INSERT DELAYED, specialized engines for special needs, and more engines in the future — but for now, InnoDB
47) Multiple MySQL instances — run diff instances for diff workloads, even if they share the same server. moving to separate hardware is easier, of course. optimize the server instance for the workload. e4asy to set up with instance manager or mysqld_multi, and there are init scripts that support the instance manager.
48) asynchronous data loading when you can — if you’re updating counts or loading logs, send updates through Spread (or whatever messaging something) to a daemon loading data. Don’t update for each request (ie, counts), do it every 1000 updates, or every few minutes. This helps if db loses net connection, the frontend keeps running! or if you want to lock tables, etc.
49) preload, dump and process — let the servers pre-process, as much as possible. dump never changing data structures to js files for the client to cache (postal data maybe), or dump to memory, or use SQLite, or BerkeleyDB and rsync to each webserver, or mysql replica on webserver
50) stored procedures are dangerous because they’re not horizontal, more work than just adding a webserver– only use if it saves the db work (ie send 5 rows to app instead of 5,000 and parsing in app)
51) reconsider persistent db connections because it requires a thread = memory, all httpd processes talk to all dbs, lots of caching might mean you don’t need main db, mysql cxns are fast so why not just reopen?
52) innodb_file_per_table, so OPTIMIZE TABLE clears unused space. innodb_buffer_pool_soze set to 80% of total mem (dedicated mysql server). innodb_flush_log_at_trx_commit, innodb_log_file_size
53) have metadata in db, store images in filesystem, but then how do you replicate? or store images in myisam tables, split up so tables don’t get bigger than 4G, so if gets corrupt fewer problems. metadata table might specify what table it’s in. include last modified date in metadata, and use in URLs to optimize caching, ie with squid: /images/$timestamp/$id.jpg
54) do everything in unicode
55) UTC for everything
56) STRICT_TRANS_TABLE so MySQL is picky about bad input and does not just turn it to NULL or zero.
57) Don’t overwork the DB — dbs don’t easily scale like web servers
58) STATELESS. don’t make cookie id’s easy to guess, or sequential, etc. don’t save state on one server only, save it on every one. put the data in the db, don’t put it in the cookie, that duplicates efforts. important data into db, so it gets saved, unimportant transient data puts in memcache, SMALL data in cookie. a shopping cart would go in db, background color goes in cookie, and last viewed items go in memcache
59) to make cookies safer, use checksums and timestamps to validate cookies. Encryption usually a waste of cycles.
60) use resources wisely. balance how you use hardware — use memory to save I/O or CPU, don’t swap memory to disk EVER.
61) do the work in parallel — split work into smaller pieces and run on different boxes. send sub-requests off as soon as possible and do other stuff in the meantime.
62) light processes for light tasks — thin proxy servers for “network buffers”, goes between the user and your heavier backend application. Use httpd with mod_proxy, mod_backhand. the proxy does the ‘net work, and fewer httpd processes are needed to do the real work, this saves memory and db connections. proxies can also server static files and cache responses. Avoid starting main app as root. Load balancing, and very important if your background processes are “heavy”. Very EASY to set up a light process. ProxyPreserveHostOn in apache 2
63) job queues — use queues, AJAX can make this easy. webserver submits job to database “queue”, first avail worker picks up first job, and sends result to queue. or ue gearman, Spread, MQ/Java Messaging Service(?)
64) log http requests to a database! log all 4xx and 5xx requests, great to see which requests are slow or fast. but only log 1-2% of all requests. Time::HiRes in Perl, microseconds from gettimeofday system call.
65) get good deals on servers http://www.siliconmechanics.com, server vendor of lj and others.

IN SUMMARY: HORIZONTAL GOOD, VERTICAL BAD

for jobs: ask@develooper.com (jobs, moonlighters, perl/mysql etc)
slides will be up at http://develooper.com/talks/
Phew! That was a lot of fast typing (60 words per minute, baby!). Ask is smart, but QUICK!!!! His slides will be VERY useful when they appear. He said there were 53 tips, but I numbered each new line (and not smartly with OL and LI) and I have more than that…

This post dedicated to Edwin DeSouza.

Un-tuned SQL or stored procedures often fail to scale as table volumes increase, plague inefficiency increases exponentially with size.

Tune SQL/stored procedures and then buy new hardware.

use EXPLAIN to help optimize queries. Also use the slow query log.

EXPLAIN EXTENDED shows sql that was actually used — ie, optimizer may rewrite query, so it’s a neat tool.

you can always give optimizer hints, but they’re not recommended — keep checking them as your app grows — STRAIGHT_JOIN, FORCE INDEX, USE INDEX, and one other one.

SHOW STATUS gives you status variables. innodb_buffer_pool_read_requests and innodb_data_read will show how much data is being read from the buffer pool vs. data.

Index isn’t always used, if more than 20% or so of rows, MySQL will use a full table scan. There’s usually a range where MySQL will choose a full table scan when an index is more appropriate, or vice versa, so that’s when you’d use hints. Hey, nobody’s perfect!

think indexes — joining tables of non-trivial size Subqueries ( [NOT] EXISTS, [NOT] IN) in WHERE clause. Use index to avoid a sort, use “covering” indexes.

Establish the best set of multi-column indexes along with singular indexes.

Derived tables (subqueries in FROM cause) can’t use an index. VIEWs with UNION or GROUP BY also can’t use index — all these use TEMPTABLE view algorithm. (temp table created, and then reads from temp table).

Sorts can be improved by increasing memory (sort_buffer_size) or using an index.

Use procedures to:

  • Avoid self joins
  • Correlated updates (subqueries accessing same data)

Performance of SQL within a stored routine that dominates the performance. When SQL is tuned, optimize the routine using traditional techniques:

  • only put what’s needed in a loop
  • stop testing when you know the answer
  • order tests by most likely first

Recursion:

  • only allowed in procedures, not functions
  • depth controlled by max_sp_recursion_depth
  • iterative alternatives are almost always faster and scaleable

TRIGGERS
non-trivial (12% at least) to even simplest trigger. No trigger should EVER contain expensive SQL, because they are done for each row.

Quest free software for MySQL — http://www.quest.com/mysql/
So last night, viagra approved during a break in the quiz show (where Prokrasti Nation had a good showing, case as did the other teams — Recreational Evil, neuropathist Peeps, and Safe Hex) we bid on the T-shirt that had the signatures of all the speakers at the conference. All the proceeds were to go to the EFF, so it’s a good cause.

They announced it was cash only, so I looked in my wallet. $33. Well, the bidding quickly went over that, and when it reached about $100 they said it didn’t have to be cash only. Around $300 Brian Aker said that they’d give whoever won credits in a new command, SHOW CONTRIBUTORS. Well, when they said that I knew I HAD to have my name in the source code.

I mean, dude, my NAME in the SOURCE CODE!!! But then again, this is an open source application, I could just spend some time and write a patch.

I’ve been saving for my wedding next June (14 months away) so when I bid $500, I said, “hey, I don’t need flowers for my wedding.” (My entire wedding budget is $5,000, so spending 10% of that on my name in the source code was, I felt, worth it.)

The bidding stalled at $775, so I asked, “Will MySQL match what is raised?” And indeed, if the bidding reached $1,000 then MySQL would donate $800. So then Boyd Hemphill (wearing the “practice safe hex” T-shirt) walked up to the front, plunked down $20 and said, “I’m giving cash to help make up the $225 difference. Who else will help?”

And people started giving cash, and the bidding increased. I bid $900, and Ronald Bradford bid $1,000. That was the top bid, so he won the T-shirt, but the MySQL folks were nice enough to say if I donated the $900 I was willing to, I’d also get my name in the SHOW CONTRIBUTORS function. So I did!

And that is how it happened.

In other news:

40% of the people who took an exam on Tuesday passed. That means 60% failed — which is a lot, although it was mentioned that probably many people took the tutorials, got the free exam, and just tried it, not caring if they failed or not because it was free.

I passed both certification exams, so now I’m MySQL certified! And I stumped Brian Aker with a question about what rpl_recovery_rank was, and won an ipod nano!
Formed a MySQL Quiz team
Met all the requirements for the MySQL Quiz
Took a Certification exam

everyone root for Team Prokrasti Nation!
I was told that teams had to have a physical instantiation of a mascot, treatment so I said, hygiene “maybe I’ll knit something.” Well, pfizer I didn’t knit something, but I did hand-craft an origami butterfly for Team Prokrasti Nation’s mascot:

(click picture for larger image).

Oh, and I won a fun game from O’Reilly for submitting speaker evaluations.
talk by Roland Mallmann

MaxDB is older than I am, site in 1977 started at University of Berlin. Owned by SAP today. Today it’s open source under GPL, purchase or commercial license from SAP or MySQL AB.

Why Max DB is so great:
Low cost of ownership
Few config parameters
no size estimates for indvidual db objects

no reorg — space management done automatically — space no longer needed is returned immediately to the db, data occupied vs. free (holes) ration is highest as possible. This is done by matching logical pages to physical on disk with the Converter, and I/O and space management.

Space management done automatically
No reorganization is needed (ie, OPTIMIZE TABLE)
Gaps are not allowed, therefore updates and deletes are in place, and sorts happen AFTER an insertion.
Space freed is immediately returned to DB
Done by Converter, matches logical pages to physical disk.
Data is stored in B* Trees (b star tree) for almost all objects (Tables, indexes, secondary indexes, BLOBs)

Concurrent asynchronous I/O
Manages free blocks
Auto balancing of disk I/O
Savepoints
Backup Integration (including incremental)
Segmentation of the data cache
A 10 minutes cycle of changes flushed to disk
Flushing data pages to disk is spread out over the 10 minutes

Online Backup and Restore
Consistent backups, no need to apply logs
Savepoint issued before db backup, savepoint includes undo information for remaining open transactions.
Can do incremental, full data, or log backup
can restore, restore from a medium, or backup from history, or backup to a point in time.

Snapshots
Can make complete database backup
Can make a snapshot for replication
Can make incremental on master and restore snapshot on replication as a backup strategy (as long as there isn’t a newer snapshot, because then incremental backup logs are reset)

Standby Database
A standby is made possible using log shipping.
Master and slave share backup media (shared disk)
Init once with complete master backup
Redo available logs

In case of emergency: start slave, back up last log piece from master in case it hasn’t been shipped. Redo all ‘open’ log backups (should be none), redo final piece, start slave, it’s now the master!

Synchronization Manager
no permanent attention required
unattended desktop/laptop installation and operation

database snapshot functionality!

Some of these may be conflicting, therapy not applicable to everyone.

1) think horizontal — everything, patient not just the web servers. Micro optimizations are boring, as or other details
2) benchmarking techniques;. Not “how fast” but “how many”. test force, not speed.
3) bigger and faster vertical scaling is the enemy.
4) horizontal scaling = add another box
5) implementation, scale your system a few times, but scale your ARCHITECTUREa dozens or hundreds of time.
6) start from the beginning with architecture implementation.
7) don’t have “The server” for anything
8) stateless good, stateful bad
9) “shared nothing” good
10) don’t keep state within app server
11) caching good.
12) generate static pages periodically, works well for not millions of pages or changes.
13) cache full output in application
14) include cookies in the “cache key” so diff browsers can get diff info too
15) use cache when this, not when that
16) use regexp to insert customized content into the cahed page
17) set Expires header to control cache times, or rewrite rule to generate page if the cached file does not exist (rails does this)
18) if content is dynamic this does not work, but great for caching “dynamic” images
19) parial pages — pre-generate static page snippets, have handler just assemble pieces.
20) cache little snippets, ie sidebar
21) don’t spend more time managing the cadche than you sav
22) cache data that’s too slow to query, fetch, calc.
23) generate page from cached data
24) use same data to generate api responss
25) moves load to web servers
26) start with things you hit all the time
27) if you don’t use it, don’t cache it, check db logs
28) don’t depend on MySQL Query cache unless it actually helps
29) local file system not so good because you copy page for every server
30) use process memory, not shared
31) mysql cache table — id is the “cache key” type is the “namespace”, metadata for things like headers for cached http responses; purge_key to make it easier to delete data from cache (make it an index, too, primary index on id,type, expire index on expire field) fields
32) why 31 fails, how do you load balance, what if mysql server died, now no cache
33) but you can use mysql scaling techniques to deal, like dual-master replication
34) use memcached, like lj, slashdot, wikipedia — memory based, linux 2.6(epoll) or FreeBsD(kqueue), low overhead for lots of cxns, no master, simple!
35) how to scale the db horizontally, use MySQL, use replication to share the load, write to one master, read from many slaves, good for heavy read apps (or insert delayed, if you don’t need to write right away) — check out “High Performance MySQL”
36) relay slave replication if too much bandwidth on the master, use a replication slave to replicate to other slaves.
37) writing does not scale with replication — all servers need to do the same writes. 5.1’s row-level replication might help.
38) so partition the data, divide and conquer. separate cluster for different data sets
39) if you can’t divide, use flexible partitioning, global server keeps track for which “cluster” has what info. auto_increment columns only in the “global master”. Aggressively cache “global master” data.
40) If you use a master-master setup like 39, then you don’t have replication slaves, no latency from commit to data being available. if you are careful you can write to both masters. Make each user always use the same master, so primary keys won’t be messed up. If one master fails, use the other one.
41) don’t be afraid of the data duplication monster. use summary tables, to avoid things like COUNT(*) and GROUP BY. do it once, put result into a table — do this periodically, or do it when the data is inserted. Or data affecting a “user” and a “group” goes into both the “user” and “group” partitions (clusters). so it’s duplicating data.
42) but you can go further, and use summary dbs! copy data into special dbs optimized for special queries, ie FULLTEXT searches, anything spanning more than one or all clusters, different dbs for different latency requirements, ie RSS feeds from a replicated slave db — RSS feeds can be late).
43) save data to multiple “partitions” like the application doing manual replication — app writes to 2 places OR last_updated and deleted columns, use triggers to add to “replication_queue” table, background program to copy data based on queue table or last_updated column
44) if you’re running oracle, move read operations to MySQL with this manual replication idea. Good way to sneak MySQL into an oracle shop.
45) make everything repeatable, build summary and load scripts so they can restart or run again — also have one trusted eata place, so summaries and copies can be (re)created from there.

BREATHE! HALFWAY THERE!!

46) use innodb because it’s more robust. except for big read-only tables, high volume streaming tables (logging), lcoked tables or INSERT DELAYED, specialized engines for special needs, and more engines in the future — but for now, InnoDB
47) Multiple MySQL instances — run diff instances for diff workloads, even if they share the same server. moving to separate hardware is easier, of course. optimize the server instance for the workload. e4asy to set up with instance manager or mysqld_multi, and there are init scripts that support the instance manager.
48) asynchronous data loading when you can — if you’re updating counts or loading logs, send updates through Spread (or whatever messaging something) to a daemon loading data. Don’t update for each request (ie, counts), do it every 1000 updates, or every few minutes. This helps if db loses net connection, the frontend keeps running! or if you want to lock tables, etc.
49) preload, dump and process — let the servers pre-process, as much as possible. dump never changing data structures to js files for the client to cache (postal data maybe), or dump to memory, or use SQLite, or BerkeleyDB and rsync to each webserver, or mysql replica on webserver
50) stored procedures are dangerous because they’re not horizontal, more work than just adding a webserver– only use if it saves the db work (ie send 5 rows to app instead of 5,000 and parsing in app)
51) reconsider persistent db connections because it requires a thread = memory, all httpd processes talk to all dbs, lots of caching might mean you don’t need main db, mysql cxns are fast so why not just reopen?
52) innodb_file_per_table, so OPTIMIZE TABLE clears unused space. innodb_buffer_pool_soze set to 80% of total mem (dedicated mysql server). innodb_flush_log_at_trx_commit, innodb_log_file_size
53) have metadata in db, store images in filesystem, but then how do you replicate? or store images in myisam tables, split up so tables don’t get bigger than 4G, so if gets corrupt fewer problems. metadata table might specify what table it’s in. include last modified date in metadata, and use in URLs to optimize caching, ie with squid: /images/$timestamp/$id.jpg
54) do everything in unicode
55) UTC for everything
56) STRICT_TRANS_TABLE so MySQL is picky about bad input and does not just turn it to NULL or zero.
57) Don’t overwork the DB — dbs don’t easily scale like web servers
58) STATELESS. don’t make cookie id’s easy to guess, or sequential, etc. don’t save state on one server only, save it on every one. put the data in the db, don’t put it in the cookie, that duplicates efforts. important data into db, so it gets saved, unimportant transient data puts in memcache, SMALL data in cookie. a shopping cart would go in db, background color goes in cookie, and last viewed items go in memcache
59) to make cookies safer, use checksums and timestamps to validate cookies. Encryption usually a waste of cycles.
60) use resources wisely. balance how you use hardware — use memory to save I/O or CPU, don’t swap memory to disk EVER.
61) do the work in parallel — split work into smaller pieces and run on different boxes. send sub-requests off as soon as possible and do other stuff in the meantime.
62) light processes for light tasks — thin proxy servers for “network buffers”, goes between the user and your heavier backend application. Use httpd with mod_proxy, mod_backhand. the proxy does the ‘net work, and fewer httpd processes are needed to do the real work, this saves memory and db connections. proxies can also server static files and cache responses. Avoid starting main app as root. Load balancing, and very important if your background processes are “heavy”. Very EASY to set up a light process. ProxyPreserveHostOn in apache 2
63) job queues — use queues, AJAX can make this easy. webserver submits job to database “queue”, first avail worker picks up first job, and sends result to queue. or ue gearman, Spread, MQ/Java Messaging Service(?)
64) log http requests to a database! log all 4xx and 5xx requests, great to see which requests are slow or fast. but only log 1-2% of all requests. Time::HiRes in Perl, microseconds from gettimeofday system call.
65) get good deals on servers http://www.siliconmechanics.com, server vendor of lj and others.

IN SUMMARY: HORIZONTAL GOOD, VERTICAL BAD

for jobs: ask@develooper.com (jobs, moonlighters, perl/mysql etc)
slides will be up at http://develooper.com/talks/
Phew! That was a lot of fast typing (60 words per minute, baby!). Ask is smart, but QUICK!!!! His slides will be VERY useful when they appear. He said there were 53 tips, but I numbered each new line (and not smartly with OL and LI) and I have more than that…

This post dedicated to Edwin DeSouza.

Un-tuned SQL or stored procedures often fail to scale as table volumes increase, plague inefficiency increases exponentially with size.

Tune SQL/stored procedures and then buy new hardware.

use EXPLAIN to help optimize queries. Also use the slow query log.

EXPLAIN EXTENDED shows sql that was actually used — ie, optimizer may rewrite query, so it’s a neat tool.

you can always give optimizer hints, but they’re not recommended — keep checking them as your app grows — STRAIGHT_JOIN, FORCE INDEX, USE INDEX, and one other one.

SHOW STATUS gives you status variables. innodb_buffer_pool_read_requests and innodb_data_read will show how much data is being read from the buffer pool vs. data.

Index isn’t always used, if more than 20% or so of rows, MySQL will use a full table scan. There’s usually a range where MySQL will choose a full table scan when an index is more appropriate, or vice versa, so that’s when you’d use hints. Hey, nobody’s perfect!

think indexes — joining tables of non-trivial size Subqueries ( [NOT] EXISTS, [NOT] IN) in WHERE clause. Use index to avoid a sort, use “covering” indexes.

Establish the best set of multi-column indexes along with singular indexes.

Derived tables (subqueries in FROM cause) can’t use an index. VIEWs with UNION or GROUP BY also can’t use index — all these use TEMPTABLE view algorithm. (temp table created, and then reads from temp table).

Sorts can be improved by increasing memory (sort_buffer_size) or using an index.

Use procedures to:

  • Avoid self joins
  • Correlated updates (subqueries accessing same data)

Performance of SQL within a stored routine that dominates the performance. When SQL is tuned, optimize the routine using traditional techniques:

  • only put what’s needed in a loop
  • stop testing when you know the answer
  • order tests by most likely first

Recursion:

  • only allowed in procedures, not functions
  • depth controlled by max_sp_recursion_depth
  • iterative alternatives are almost always faster and scaleable

TRIGGERS
non-trivial (12% at least) to even simplest trigger. No trigger should EVER contain expensive SQL, because they are done for each row.

Quest free software for MySQL — http://www.quest.com/mysql/
So last night, viagra approved during a break in the quiz show (where Prokrasti Nation had a good showing, case as did the other teams — Recreational Evil, neuropathist Peeps, and Safe Hex) we bid on the T-shirt that had the signatures of all the speakers at the conference. All the proceeds were to go to the EFF, so it’s a good cause.

They announced it was cash only, so I looked in my wallet. $33. Well, the bidding quickly went over that, and when it reached about $100 they said it didn’t have to be cash only. Around $300 Brian Aker said that they’d give whoever won credits in a new command, SHOW CONTRIBUTORS. Well, when they said that I knew I HAD to have my name in the source code.

I mean, dude, my NAME in the SOURCE CODE!!! But then again, this is an open source application, I could just spend some time and write a patch.

I’ve been saving for my wedding next June (14 months away) so when I bid $500, I said, “hey, I don’t need flowers for my wedding.” (My entire wedding budget is $5,000, so spending 10% of that on my name in the source code was, I felt, worth it.)

The bidding stalled at $775, so I asked, “Will MySQL match what is raised?” And indeed, if the bidding reached $1,000 then MySQL would donate $800. So then Boyd Hemphill (wearing the “practice safe hex” T-shirt) walked up to the front, plunked down $20 and said, “I’m giving cash to help make up the $225 difference. Who else will help?”

And people started giving cash, and the bidding increased. I bid $900, and Ronald Bradford bid $1,000. That was the top bid, so he won the T-shirt, but the MySQL folks were nice enough to say if I donated the $900 I was willing to, I’d also get my name in the SHOW CONTRIBUTORS function. So I did!

And that is how it happened.

In other news:

40% of the people who took an exam on Tuesday passed. That means 60% failed — which is a lot, although it was mentioned that probably many people took the tutorials, got the free exam, and just tried it, not caring if they failed or not because it was free.

I passed both certification exams, so now I’m MySQL certified! And I stumped Brian Aker with a question about what rpl_recovery_rank was, and won an ipod nano!
by Mitch Kapor

Wikipedia uses MySQL as their backend. Wikipedia is known among geeks, sick but hasn’t quite hit society at large, more about but probably will soon. What lessons can we learn from Wikipedia? People who hear about the concept of wikipedia say “It can’t possibly work — an encyclopedia written by volunteers, that is completely open?”

Continue reading

MySQL Users Group BOF

Why didn’t I think of this? Tom Limoncelli was nice enough to create a livejournal feed for this site — http://www.livejournal.com/users/sheericom_feed/

Direct link to add as a ‘friend’ if you’re logged in — http://www.livejournal.com/friends/add.bml?user=sheericom_feed

Why didn’t I think of this? Tom Limoncelli was nice enough to create a livejournal feed for this site — http://www.livejournal.com/users/sheericom_feed/

Direct link to add as a ‘friend’ if you’re logged in — http://www.livejournal.com/friends/add.bml?user=sheericom_feed

The MySQL User Group meeting on Monday, there January 9th will focus on backups — I will give a 30-45 minute presentation on backups and we will then delve into a discussion — how folks within the group are backing up, how they’re not backing up, how they’d like to back up. If there’s time, we’ll do a “lessons learned from backup horror stories”.

Afterwards, we’ll head a few doors down to Boston Beer Works for more chatting.

You can see a video of last month’s presentation by Philip Antionades of MySQL AB on the new features in MySQL 5.0 at Google Video:

http://video.google.com/videosearch?q=Mysql+5.0+by+Philip+Antoniades

(we will video this month’s presentation but not the discussion)

More details, including the event location and directions, are at: http://mysql.meetup.com/137/events/

Any questions, comments, etc should be sent to me. We’re currently looking for a space better than North Station — something around MIT might be nice, and we’re trying to get an MIT grad student/faculty/staff member/organization to sponsor it. (We want a location that’s good for people driving AND taking the T, and when the Garden has an event, it’s not feasible to park there). If you can help out, please let me know.

(You may forward this announcement to other groups, lists, blogs, whatever.)

I’m quite excited about the presentation, as I’m writing down a lot of information from different sources that really wants to be together, but as far as I can tell is not yet, at least not in a public place.
Why didn’t I think of this? Tom Limoncelli was nice enough to create a livejournal feed for this site — http://www.livejournal.com/users/sheericom_feed/

Direct link to add as a ‘friend’ if you’re logged in — http://www.livejournal.com/friends/add.bml?user=sheericom_feed

The MySQL User Group meeting on Monday, there January 9th will focus on backups — I will give a 30-45 minute presentation on backups and we will then delve into a discussion — how folks within the group are backing up, how they’re not backing up, how they’d like to back up. If there’s time, we’ll do a “lessons learned from backup horror stories”.

Afterwards, we’ll head a few doors down to Boston Beer Works for more chatting.

You can see a video of last month’s presentation by Philip Antionades of MySQL AB on the new features in MySQL 5.0 at Google Video:

http://video.google.com/videosearch?q=Mysql+5.0+by+Philip+Antoniades

(we will video this month’s presentation but not the discussion)

More details, including the event location and directions, are at: http://mysql.meetup.com/137/events/

Any questions, comments, etc should be sent to me. We’re currently looking for a space better than North Station — something around MIT might be nice, and we’re trying to get an MIT grad student/faculty/staff member/organization to sponsor it. (We want a location that’s good for people driving AND taking the T, and when the Garden has an event, it’s not feasible to park there). If you can help out, please let me know.

(You may forward this announcement to other groups, lists, blogs, whatever.)

I’m quite excited about the presentation, as I’m writing down a lot of information from different sources that really wants to be together, but as far as I can tell is not yet, at least not in a public place.
This article is somewhat long. Interestingly, seek it does not actually cover my entire talk, prostate as there is much to talk about besides the mechanics of each backup option. I wonder what I’d need to do to make this into a white paper or an article?

The backup presentation was finished last night. I may decide to go back and put some extra stuff in there, but that would be syntax and code and stuff. The logic is all in there, and the notes have been printed. I will post the slides (in .pdf and .swf (flash, the file is very small that way) formats) after the talk on Monday, as I may yet revise them.

I am very excited about one slide in particular, and I’ll share it here. It’s really a slide that I end with, but I feel as though it’s a great starting point as well as a summary point. I haven’t seen this information encapsulated this way before, so here goes:

Comparison Table of MySQL Backup Methods

Continue reading

Boston MySQL User Group

Why didn’t I think of this? Tom Limoncelli was nice enough to create a livejournal feed for this site — http://www.livejournal.com/users/sheericom_feed/

Direct link to add as a ‘friend’ if you’re logged in — http://www.livejournal.com/friends/add.bml?user=sheericom_feed

Why didn’t I think of this? Tom Limoncelli was nice enough to create a livejournal feed for this site — http://www.livejournal.com/users/sheericom_feed/

Direct link to add as a ‘friend’ if you’re logged in — http://www.livejournal.com/friends/add.bml?user=sheericom_feed

The MySQL User Group meeting on Monday, there January 9th will focus on backups — I will give a 30-45 minute presentation on backups and we will then delve into a discussion — how folks within the group are backing up, how they’re not backing up, how they’d like to back up. If there’s time, we’ll do a “lessons learned from backup horror stories”.

Afterwards, we’ll head a few doors down to Boston Beer Works for more chatting.

You can see a video of last month’s presentation by Philip Antionades of MySQL AB on the new features in MySQL 5.0 at Google Video:

http://video.google.com/videosearch?q=Mysql+5.0+by+Philip+Antoniades

(we will video this month’s presentation but not the discussion)

More details, including the event location and directions, are at: http://mysql.meetup.com/137/events/

Any questions, comments, etc should be sent to me. We’re currently looking for a space better than North Station — something around MIT might be nice, and we’re trying to get an MIT grad student/faculty/staff member/organization to sponsor it. (We want a location that’s good for people driving AND taking the T, and when the Garden has an event, it’s not feasible to park there). If you can help out, please let me know.

(You may forward this announcement to other groups, lists, blogs, whatever.)

I’m quite excited about the presentation, as I’m writing down a lot of information from different sources that really wants to be together, but as far as I can tell is not yet, at least not in a public place.
Why didn’t I think of this? Tom Limoncelli was nice enough to create a livejournal feed for this site — http://www.livejournal.com/users/sheericom_feed/

Direct link to add as a ‘friend’ if you’re logged in — http://www.livejournal.com/friends/add.bml?user=sheericom_feed

The MySQL User Group meeting on Monday, there January 9th will focus on backups — I will give a 30-45 minute presentation on backups and we will then delve into a discussion — how folks within the group are backing up, how they’re not backing up, how they’d like to back up. If there’s time, we’ll do a “lessons learned from backup horror stories”.

Afterwards, we’ll head a few doors down to Boston Beer Works for more chatting.

You can see a video of last month’s presentation by Philip Antionades of MySQL AB on the new features in MySQL 5.0 at Google Video:

http://video.google.com/videosearch?q=Mysql+5.0+by+Philip+Antoniades

(we will video this month’s presentation but not the discussion)

More details, including the event location and directions, are at: http://mysql.meetup.com/137/events/

Any questions, comments, etc should be sent to me. We’re currently looking for a space better than North Station — something around MIT might be nice, and we’re trying to get an MIT grad student/faculty/staff member/organization to sponsor it. (We want a location that’s good for people driving AND taking the T, and when the Garden has an event, it’s not feasible to park there). If you can help out, please let me know.

(You may forward this announcement to other groups, lists, blogs, whatever.)

I’m quite excited about the presentation, as I’m writing down a lot of information from different sources that really wants to be together, but as far as I can tell is not yet, at least not in a public place.
This article is somewhat long. Interestingly, seek it does not actually cover my entire talk, prostate as there is much to talk about besides the mechanics of each backup option. I wonder what I’d need to do to make this into a white paper or an article?

The backup presentation was finished last night. I may decide to go back and put some extra stuff in there, but that would be syntax and code and stuff. The logic is all in there, and the notes have been printed. I will post the slides (in .pdf and .swf (flash, the file is very small that way) formats) after the talk on Monday, as I may yet revise them.

I am very excited about one slide in particular, and I’ll share it here. It’s really a slide that I end with, but I feel as though it’s a great starting point as well as a summary point. I haven’t seen this information encapsulated this way before, so here goes:

Comparison Table of MySQL Backup Methods

Continue reading

So You’ve Inherited a MySQL Instance

Why didn’t I think of this? Tom Limoncelli was nice enough to create a livejournal feed for this site — http://www.livejournal.com/users/sheericom_feed/

Direct link to add as a ‘friend’ if you’re logged in — http://www.livejournal.com/friends/add.bml?user=sheericom_feed

Why didn’t I think of this? Tom Limoncelli was nice enough to create a livejournal feed for this site — http://www.livejournal.com/users/sheericom_feed/

Direct link to add as a ‘friend’ if you’re logged in — http://www.livejournal.com/friends/add.bml?user=sheericom_feed

The MySQL User Group meeting on Monday, there January 9th will focus on backups — I will give a 30-45 minute presentation on backups and we will then delve into a discussion — how folks within the group are backing up, how they’re not backing up, how they’d like to back up. If there’s time, we’ll do a “lessons learned from backup horror stories”.

Afterwards, we’ll head a few doors down to Boston Beer Works for more chatting.

You can see a video of last month’s presentation by Philip Antionades of MySQL AB on the new features in MySQL 5.0 at Google Video:

http://video.google.com/videosearch?q=Mysql+5.0+by+Philip+Antoniades

(we will video this month’s presentation but not the discussion)

More details, including the event location and directions, are at: http://mysql.meetup.com/137/events/

Any questions, comments, etc should be sent to me. We’re currently looking for a space better than North Station — something around MIT might be nice, and we’re trying to get an MIT grad student/faculty/staff member/organization to sponsor it. (We want a location that’s good for people driving AND taking the T, and when the Garden has an event, it’s not feasible to park there). If you can help out, please let me know.

(You may forward this announcement to other groups, lists, blogs, whatever.)

I’m quite excited about the presentation, as I’m writing down a lot of information from different sources that really wants to be together, but as far as I can tell is not yet, at least not in a public place.
Why didn’t I think of this? Tom Limoncelli was nice enough to create a livejournal feed for this site — http://www.livejournal.com/users/sheericom_feed/

Direct link to add as a ‘friend’ if you’re logged in — http://www.livejournal.com/friends/add.bml?user=sheericom_feed

The MySQL User Group meeting on Monday, there January 9th will focus on backups — I will give a 30-45 minute presentation on backups and we will then delve into a discussion — how folks within the group are backing up, how they’re not backing up, how they’d like to back up. If there’s time, we’ll do a “lessons learned from backup horror stories”.

Afterwards, we’ll head a few doors down to Boston Beer Works for more chatting.

You can see a video of last month’s presentation by Philip Antionades of MySQL AB on the new features in MySQL 5.0 at Google Video:

http://video.google.com/videosearch?q=Mysql+5.0+by+Philip+Antoniades

(we will video this month’s presentation but not the discussion)

More details, including the event location and directions, are at: http://mysql.meetup.com/137/events/

Any questions, comments, etc should be sent to me. We’re currently looking for a space better than North Station — something around MIT might be nice, and we’re trying to get an MIT grad student/faculty/staff member/organization to sponsor it. (We want a location that’s good for people driving AND taking the T, and when the Garden has an event, it’s not feasible to park there). If you can help out, please let me know.

(You may forward this announcement to other groups, lists, blogs, whatever.)

I’m quite excited about the presentation, as I’m writing down a lot of information from different sources that really wants to be together, but as far as I can tell is not yet, at least not in a public place.
This article is somewhat long. Interestingly, seek it does not actually cover my entire talk, prostate as there is much to talk about besides the mechanics of each backup option. I wonder what I’d need to do to make this into a white paper or an article?

The backup presentation was finished last night. I may decide to go back and put some extra stuff in there, but that would be syntax and code and stuff. The logic is all in there, and the notes have been printed. I will post the slides (in .pdf and .swf (flash, the file is very small that way) formats) after the talk on Monday, as I may yet revise them.

I am very excited about one slide in particular, and I’ll share it here. It’s really a slide that I end with, but I feel as though it’s a great starting point as well as a summary point. I haven’t seen this information encapsulated this way before, so here goes:

Comparison Table of MySQL Backup Methods

Continue reading

February Boston MySQL User Group

Why didn’t I think of this? Tom Limoncelli was nice enough to create a livejournal feed for this site — http://www.livejournal.com/users/sheericom_feed/

Direct link to add as a ‘friend’ if you’re logged in — http://www.livejournal.com/friends/add.bml?user=sheericom_feed

Why didn’t I think of this? Tom Limoncelli was nice enough to create a livejournal feed for this site — http://www.livejournal.com/users/sheericom_feed/

Direct link to add as a ‘friend’ if you’re logged in — http://www.livejournal.com/friends/add.bml?user=sheericom_feed

The MySQL User Group meeting on Monday, there January 9th will focus on backups — I will give a 30-45 minute presentation on backups and we will then delve into a discussion — how folks within the group are backing up, how they’re not backing up, how they’d like to back up. If there’s time, we’ll do a “lessons learned from backup horror stories”.

Afterwards, we’ll head a few doors down to Boston Beer Works for more chatting.

You can see a video of last month’s presentation by Philip Antionades of MySQL AB on the new features in MySQL 5.0 at Google Video:

http://video.google.com/videosearch?q=Mysql+5.0+by+Philip+Antoniades

(we will video this month’s presentation but not the discussion)

More details, including the event location and directions, are at: http://mysql.meetup.com/137/events/

Any questions, comments, etc should be sent to me. We’re currently looking for a space better than North Station — something around MIT might be nice, and we’re trying to get an MIT grad student/faculty/staff member/organization to sponsor it. (We want a location that’s good for people driving AND taking the T, and when the Garden has an event, it’s not feasible to park there). If you can help out, please let me know.

(You may forward this announcement to other groups, lists, blogs, whatever.)

I’m quite excited about the presentation, as I’m writing down a lot of information from different sources that really wants to be together, but as far as I can tell is not yet, at least not in a public place.
Why didn’t I think of this? Tom Limoncelli was nice enough to create a livejournal feed for this site — http://www.livejournal.com/users/sheericom_feed/

Direct link to add as a ‘friend’ if you’re logged in — http://www.livejournal.com/friends/add.bml?user=sheericom_feed

The MySQL User Group meeting on Monday, there January 9th will focus on backups — I will give a 30-45 minute presentation on backups and we will then delve into a discussion — how folks within the group are backing up, how they’re not backing up, how they’d like to back up. If there’s time, we’ll do a “lessons learned from backup horror stories”.

Afterwards, we’ll head a few doors down to Boston Beer Works for more chatting.

You can see a video of last month’s presentation by Philip Antionades of MySQL AB on the new features in MySQL 5.0 at Google Video:

http://video.google.com/videosearch?q=Mysql+5.0+by+Philip+Antoniades

(we will video this month’s presentation but not the discussion)

More details, including the event location and directions, are at: http://mysql.meetup.com/137/events/

Any questions, comments, etc should be sent to me. We’re currently looking for a space better than North Station — something around MIT might be nice, and we’re trying to get an MIT grad student/faculty/staff member/organization to sponsor it. (We want a location that’s good for people driving AND taking the T, and when the Garden has an event, it’s not feasible to park there). If you can help out, please let me know.

(You may forward this announcement to other groups, lists, blogs, whatever.)

I’m quite excited about the presentation, as I’m writing down a lot of information from different sources that really wants to be together, but as far as I can tell is not yet, at least not in a public place.
This article is somewhat long. Interestingly, seek it does not actually cover my entire talk, prostate as there is much to talk about besides the mechanics of each backup option. I wonder what I’d need to do to make this into a white paper or an article?

The backup presentation was finished last night. I may decide to go back and put some extra stuff in there, but that would be syntax and code and stuff. The logic is all in there, and the notes have been printed. I will post the slides (in .pdf and .swf (flash, the file is very small that way) formats) after the talk on Monday, as I may yet revise them.

I am very excited about one slide in particular, and I’ll share it here. It’s really a slide that I end with, but I feel as though it’s a great starting point as well as a summary point. I haven’t seen this information encapsulated this way before, so here goes:

Comparison Table of MySQL Backup Methods

Continue reading

MySQL Backup Presentation

Why didn’t I think of this? Tom Limoncelli was nice enough to create a livejournal feed for this site — http://www.livejournal.com/users/sheericom_feed/

Direct link to add as a ‘friend’ if you’re logged in — http://www.livejournal.com/friends/add.bml?user=sheericom_feed

Why didn’t I think of this? Tom Limoncelli was nice enough to create a livejournal feed for this site — http://www.livejournal.com/users/sheericom_feed/

Direct link to add as a ‘friend’ if you’re logged in — http://www.livejournal.com/friends/add.bml?user=sheericom_feed

The MySQL User Group meeting on Monday, there January 9th will focus on backups — I will give a 30-45 minute presentation on backups and we will then delve into a discussion — how folks within the group are backing up, how they’re not backing up, how they’d like to back up. If there’s time, we’ll do a “lessons learned from backup horror stories”.

Afterwards, we’ll head a few doors down to Boston Beer Works for more chatting.

You can see a video of last month’s presentation by Philip Antionades of MySQL AB on the new features in MySQL 5.0 at Google Video:

http://video.google.com/videosearch?q=Mysql+5.0+by+Philip+Antoniades

(we will video this month’s presentation but not the discussion)

More details, including the event location and directions, are at: http://mysql.meetup.com/137/events/

Any questions, comments, etc should be sent to me. We’re currently looking for a space better than North Station — something around MIT might be nice, and we’re trying to get an MIT grad student/faculty/staff member/organization to sponsor it. (We want a location that’s good for people driving AND taking the T, and when the Garden has an event, it’s not feasible to park there). If you can help out, please let me know.

(You may forward this announcement to other groups, lists, blogs, whatever.)

I’m quite excited about the presentation, as I’m writing down a lot of information from different sources that really wants to be together, but as far as I can tell is not yet, at least not in a public place.
Why didn’t I think of this? Tom Limoncelli was nice enough to create a livejournal feed for this site — http://www.livejournal.com/users/sheericom_feed/

Direct link to add as a ‘friend’ if you’re logged in — http://www.livejournal.com/friends/add.bml?user=sheericom_feed

The MySQL User Group meeting on Monday, there January 9th will focus on backups — I will give a 30-45 minute presentation on backups and we will then delve into a discussion — how folks within the group are backing up, how they’re not backing up, how they’d like to back up. If there’s time, we’ll do a “lessons learned from backup horror stories”.

Afterwards, we’ll head a few doors down to Boston Beer Works for more chatting.

You can see a video of last month’s presentation by Philip Antionades of MySQL AB on the new features in MySQL 5.0 at Google Video:

http://video.google.com/videosearch?q=Mysql+5.0+by+Philip+Antoniades

(we will video this month’s presentation but not the discussion)

More details, including the event location and directions, are at: http://mysql.meetup.com/137/events/

Any questions, comments, etc should be sent to me. We’re currently looking for a space better than North Station — something around MIT might be nice, and we’re trying to get an MIT grad student/faculty/staff member/organization to sponsor it. (We want a location that’s good for people driving AND taking the T, and when the Garden has an event, it’s not feasible to park there). If you can help out, please let me know.

(You may forward this announcement to other groups, lists, blogs, whatever.)

I’m quite excited about the presentation, as I’m writing down a lot of information from different sources that really wants to be together, but as far as I can tell is not yet, at least not in a public place.
This article is somewhat long. Interestingly, seek it does not actually cover my entire talk, prostate as there is much to talk about besides the mechanics of each backup option. I wonder what I’d need to do to make this into a white paper or an article?

The backup presentation was finished last night. I may decide to go back and put some extra stuff in there, but that would be syntax and code and stuff. The logic is all in there, and the notes have been printed. I will post the slides (in .pdf and .swf (flash, the file is very small that way) formats) after the talk on Monday, as I may yet revise them.

I am very excited about one slide in particular, and I’ll share it here. It’s really a slide that I end with, but I feel as though it’s a great starting point as well as a summary point. I haven’t seen this information encapsulated this way before, so here goes:

Comparison Table of MySQL Backup Methods

Continue reading

Boston MySQL User Group: Backups!

Why didn’t I think of this? Tom Limoncelli was nice enough to create a livejournal feed for this site — http://www.livejournal.com/users/sheericom_feed/

Direct link to add as a ‘friend’ if you’re logged in — http://www.livejournal.com/friends/add.bml?user=sheericom_feed

Why didn’t I think of this? Tom Limoncelli was nice enough to create a livejournal feed for this site — http://www.livejournal.com/users/sheericom_feed/

Direct link to add as a ‘friend’ if you’re logged in — http://www.livejournal.com/friends/add.bml?user=sheericom_feed

The MySQL User Group meeting on Monday, there January 9th will focus on backups — I will give a 30-45 minute presentation on backups and we will then delve into a discussion — how folks within the group are backing up, how they’re not backing up, how they’d like to back up. If there’s time, we’ll do a “lessons learned from backup horror stories”.

Afterwards, we’ll head a few doors down to Boston Beer Works for more chatting.

You can see a video of last month’s presentation by Philip Antionades of MySQL AB on the new features in MySQL 5.0 at Google Video:

http://video.google.com/videosearch?q=Mysql+5.0+by+Philip+Antoniades

(we will video this month’s presentation but not the discussion)

More details, including the event location and directions, are at: http://mysql.meetup.com/137/events/

Any questions, comments, etc should be sent to me. We’re currently looking for a space better than North Station — something around MIT might be nice, and we’re trying to get an MIT grad student/faculty/staff member/organization to sponsor it. (We want a location that’s good for people driving AND taking the T, and when the Garden has an event, it’s not feasible to park there). If you can help out, please let me know.

(You may forward this announcement to other groups, lists, blogs, whatever.)

I’m quite excited about the presentation, as I’m writing down a lot of information from different sources that really wants to be together, but as far as I can tell is not yet, at least not in a public place.

First Boston MySQL User Group Meeting

To contact me via e-mail:

awfief@gmail.com
To contact me via e-mail:

awfief@gmail.com
To contact me via e-mail:

awfief@gmail.com
Having used Oracle, buy more about DB2, Postgres, Sybase, Informix, and MSSQL, I always enjoyed that MySQL just named everything “MySQL”. Sure, it can get confusing — there’s MySQL the server, MySQL the client, MySQL the database instance. . . .MySQL the flamethrower (the kids love this one). . . .But seriously, the ‘big guys’ have all this complicated jargon for really simple ideas.

MySQL has joined them. Granted, I’d been out of the MySQL world for about a year, and some wonderful things have happened in that year. Even a year ago, the company I worked for wasn’t using the most recent software nor taking advantage of all the features their versions of MySQL did have to offer. But I digress.

I’ve been working on MySQL knowledge, particularly with the free webinars. Today I attended the “MySQL Network and MySQL 5.0” webinar, where I learned that MySQL is packaging (better) software, support, tools, access to developers, and a knowledgebase into what they call “MySQL Network.” I was completely unclear on the concept of MySQL Network from the description, and from the name I figured it would have something to do with technical networking, not business to business networking.

Meanwhile, yesterday I realized that the “Pluggable Storage Engines” in MySQL just mean “you can use different table types, and turn off the ones you don’t want to use.” I was familiar with the concept, but not the buzz-phrase used to describe it.
To contact me via e-mail:

awfief@gmail.com
To contact me via e-mail:

awfief@gmail.com
Having used Oracle, buy more about DB2, Postgres, Sybase, Informix, and MSSQL, I always enjoyed that MySQL just named everything “MySQL”. Sure, it can get confusing — there’s MySQL the server, MySQL the client, MySQL the database instance. . . .MySQL the flamethrower (the kids love this one). . . .But seriously, the ‘big guys’ have all this complicated jargon for really simple ideas.

MySQL has joined them. Granted, I’d been out of the MySQL world for about a year, and some wonderful things have happened in that year. Even a year ago, the company I worked for wasn’t using the most recent software nor taking advantage of all the features their versions of MySQL did have to offer. But I digress.

I’ve been working on MySQL knowledge, particularly with the free webinars. Today I attended the “MySQL Network and MySQL 5.0” webinar, where I learned that MySQL is packaging (better) software, support, tools, access to developers, and a knowledgebase into what they call “MySQL Network.” I was completely unclear on the concept of MySQL Network from the description, and from the name I figured it would have something to do with technical networking, not business to business networking.

Meanwhile, yesterday I realized that the “Pluggable Storage Engines” in MySQL just mean “you can use different table types, and turn off the ones you don’t want to use.” I was familiar with the concept, but not the buzz-phrase used to describe it.
To contact me via e-mail:

awfief@gmail.com
Having used Oracle, buy more about DB2, Postgres, Sybase, Informix, and MSSQL, I always enjoyed that MySQL just named everything “MySQL”. Sure, it can get confusing — there’s MySQL the server, MySQL the client, MySQL the database instance. . . .MySQL the flamethrower (the kids love this one). . . .But seriously, the ‘big guys’ have all this complicated jargon for really simple ideas.

MySQL has joined them. Granted, I’d been out of the MySQL world for about a year, and some wonderful things have happened in that year. Even a year ago, the company I worked for wasn’t using the most recent software nor taking advantage of all the features their versions of MySQL did have to offer. But I digress.

I’ve been working on MySQL knowledge, particularly with the free webinars. Today I attended the “MySQL Network and MySQL 5.0” webinar, where I learned that MySQL is packaging (better) software, support, tools, access to developers, and a knowledgebase into what they call “MySQL Network.” I was completely unclear on the concept of MySQL Network from the description, and from the name I figured it would have something to do with technical networking, not business to business networking.

Meanwhile, yesterday I realized that the “Pluggable Storage Engines” in MySQL just mean “you can use different table types, and turn off the ones you don’t want to use.” I was familiar with the concept, but not the buzz-phrase used to describe it.
The first Boston MySQL User Group meeting went swimmingly. About 1/2 the people who RSVP’s yes or maybe showed up, anaemia which meant that the fine Optaros folks hosting us (thanx again to Stephen Walli) got pizza as a thank-you gift.

My boss offered me a ride home, click otherwise I would have taken Stephen up on his offer to get a beer. Next time, public health definitely — I’ll just go into work later, and not be tempted by a ride home.

The demographics of the group was really amazing:

about 15% female
those with no experience with any database
those with experience with databases but not MySQL
those who’ve been using MySQL for weeks
those who’ve been using MySQL for months
those who’ve been using MySQL for years
those who are trying to convince their company to switch
about 10% Indian
about 20% other-Asian
(I didn’t notice anyone that was recognizably Hispanic or black)
job titles ranging from developer, dba, all the way up to the vice president and president level
The publishing sector was represented by O’Reilly, Addison-Wesley (which is owned by Pearson, which handles the MySQL Press imprint), and Apress. O’Reilly and Apress solicited authors.

Corrections always welcome, and special thanks to Mike Kruckenberg, and Mark Rubin of MySQL AB.

I cannot wait for next month. . .