The mysqlbinlog are not new. We often reference it and all of the valuable information that it provides. I thought it might be useful to show some simple examples on how to get some of that information, for those unfamiliar with the mysqlbinlog tool.
For this example, I used the MySQL benchmark tools to populate data.
You can review binary log events a couple if different ways.
You can use the command line :
mysqlbinlog mysql56rc-bin.000010
or within MySQL via a simple query.
SHOW BINLOG EVENTS IN 'mysql56rc-bin.000010' ;
These will both dump out all of the data, and this demo currently has 2284725 rows of data, to much to review one by one.
Keep in mind that some of the differences between these two options. You will gather more information via the command line mysqlbinlog versus just the query "SHOW BINLOG EVENTS".
example: If we wanted to get an idea of how long a query took to run?
# mysqlbinlog mysql56rc-bin.000010
....
# at 915
#121031 7:52:49 server id 1 end_log_pos 1029 CRC32 0xd3201bdc Query thread_id=47 exec_time=0 error_code=0
...
insert into bench1 values ('C',2,9997,6)
....
I could also be more direct and check the logs for just that bin log position:
# mysqlbinlog mysql56rc-bin.000010 --start-position=915 --stop-position=1029
The mysqlbinlog will also allow you to gather an idea of the execution time a query took on a master server. It is not perfect when checking the same query on a slave. Baron has a blog about this if you want to learn more.
We are unable to see execution time via the "SHOW BINLOG EVENTS".
MySQL 5.6 RC> SHOW BINLOG EVENTS IN 'mysql56rc-bin.000010' FROM 915 LIMIT 1\G
*************************** 1. row ***************************
Log_name: mysql56rc-bin.000010
Pos: 915
Event_type: Query
Server_id: 1
End_log_pos: 1029
Info: use `test`; insert into bench1 values ('C',2,9997,6)
1 row in set (0.00 sec)
The mysqlbinlog also allows you to be able to search within a date range.
# mysqlbinlog mysql56rc-bin.000010 --start-datetime="2012-10-31 07:52:49" --stop-datetime="2012-10-31 07:52:50"
# at 915
#121031 7:52:49 server id 1 end_log_pos 1029 CRC32 0xd3201bdc Query thread_id=47 exec_time=0 error_code=0
SET TIMESTAMP=1351695169/*!*/;
insert into bench1 values ('C',2,9997,6)
/*!*/;
This is just a simple small sample intro into MySQL Binlog. Find more information via these great blogs and sites.
http://dev.mysql.com/doc/refman/5.6/en/mysqlbinlog.html
http://www.pythian.com/news/1174/mysqlbinlog-tips-and-tricks/
http://ronaldbradford.com/blog/tag/mysqlbinlog/
http://dev.mysql.com/doc/refman/5.6/en/mysqlbinlog-backup.html
http://flylib.com/books/en/2.304.1.130/1/
http://www.databasejournal.com/features/mysql/article.php/3903646/Inside-MySQL-Binary-Logs.htm
http://www.mysqlperformanceblog.com/2011/01/31/what-is-exec_time-in-binary-logs/
Wednesday, October 31, 2012
Friday, October 26, 2012
Keyser Soze in MySQL?
Who is Keyser Soze?
Some recall:
"...a rarely seen, nearly mythical kingpin... Most believe he is not real, but rather boogeyman story or name-drop to intimidate people."
Some people think of it as :
"Keyser Soze – DBA or developer who looks ordinary but has insanely good skills, hardly anybody knows about it."
What does any of this have to do with MySQL ?
Well for this blog post, "Keyser Soze" is the nearly mythical query that most believe is not real, but rather a "boogeyman sql query" that wastes resources in a MySQL Database. Typically, every application has at least one. Your developers blame the database for being slow and they have caught the ear of the CEO. It is time to resolve the boogeyman issue and find out. The difference is we want a better agent than Dave Kujan, so we have the MySQL Query Analyzer and Enterprise Monitor.
First, we get them on the case:
./mysqlmonitor-2.3.12.2175-linux-x86_64-installer.bin
FYI: Requires MySQL Server version 5.1.43 or later with partitioning and InnoDB storage engine enabled is required.
The install is very straight forward and just follow the prompts.
You will be asked:
Database Installation
Please select which database configuration you wish to use
[1] I wish to use the bundled MySQL database
[2] I wish to use an existing MySQL database
It is up to you which database you decide. In my opinion, a monitor should not alter the environment of what is is monitoring. I would choose option 1. It would not hurt to still backup this database, just in case.
Once this is installed we start to look over our graphs and advisor...
Very mellow server load here.
( granted this is a demo)
The MySQL Query Analyzer can shed more light on curious queries.
It will take a couple edits to the ../enterprise/agent/etc/mysql-monitor-agent.ini file. I prefer the server method because it is quick and simple and catches all default interactions with the database.
So now if an event was to hit your database you are aware whenever it happens. You will be able to scroll back overnight for example to see not only what ran, but how it ran. If someone decided to put a small query into a infinite loop by mistake, you will find it here.
Once you do see something you are curious about... (Maybe it is "Keyser Soze" or maybe it is a planned query)
You can then highlight the graph and then pull up all queries related to that time frame.
You will then be allowed to see the explain (as long as it meets time thresholds) as well as graphs of how the selected query was executed via your server.
If you find yourself not getting the explains like you expected make sure to check your configuration and adjust the threshold.
While this is just a demo, this tool is very useful for exploring trends in your data, as well as find the critical events. The advisers can help you fine tune the server per the data that has been executed on it. The Enterprise monitor will allow you to do a deep dive into the system and explore all options as you look for the "Keyser Soze" in your application.
Of course don't forget, the monitor also delivers replication information. So you can keep track of topology, server type, position, errors, and log space.
While all this might not make an interesting movie like the Usual Suspects did, it does show that while a DBA might have a list of usual suspects when it comes to a problem, they also can lean on the tools available for a wealth of additional information.
More Reference urls:
Some recall:
"...a rarely seen, nearly mythical kingpin... Most believe he is not real, but rather boogeyman story or name-drop to intimidate people."
Some people think of it as :
"Keyser Soze – DBA or developer who looks ordinary but has insanely good skills, hardly anybody knows about it."
What does any of this have to do with MySQL ?
Well for this blog post, "Keyser Soze" is the nearly mythical query that most believe is not real, but rather a "boogeyman sql query" that wastes resources in a MySQL Database. Typically, every application has at least one. Your developers blame the database for being slow and they have caught the ear of the CEO. It is time to resolve the boogeyman issue and find out. The difference is we want a better agent than Dave Kujan, so we have the MySQL Query Analyzer and Enterprise Monitor.
First, we get them on the case:
./mysqlmonitor-2.3.12.2175-linux-x86_64-installer.bin
FYI: Requires MySQL Server version 5.1.43 or later with partitioning and InnoDB storage engine enabled is required.
The install is very straight forward and just follow the prompts.
You will be asked:
Database Installation
Please select which database configuration you wish to use
[1] I wish to use the bundled MySQL database
[2] I wish to use an existing MySQL database
It is up to you which database you decide. In my opinion, a monitor should not alter the environment of what is is monitoring. I would choose option 1. It would not hurt to still backup this database, just in case.
Once this is installed we start to look over our graphs and advisor...
Very mellow server load here.
( granted this is a demo)
The MySQL Query Analyzer can shed more light on curious queries.
It will take a couple edits to the ../enterprise/agent/etc/mysql-monitor-agent.ini file. I prefer the server method because it is quick and simple and catches all default interactions with the database.
So now if an event was to hit your database you are aware whenever it happens. You will be able to scroll back overnight for example to see not only what ran, but how it ran. If someone decided to put a small query into a infinite loop by mistake, you will find it here.
Once you do see something you are curious about... (Maybe it is "Keyser Soze" or maybe it is a planned query)
You can then highlight the graph and then pull up all queries related to that time frame.
You will then be allowed to see the explain (as long as it meets time thresholds) as well as graphs of how the selected query was executed via your server.
If you find yourself not getting the explains like you expected make sure to check your configuration and adjust the threshold.
While this is just a demo, this tool is very useful for exploring trends in your data, as well as find the critical events. The advisers can help you fine tune the server per the data that has been executed on it. The Enterprise monitor will allow you to do a deep dive into the system and explore all options as you look for the "Keyser Soze" in your application.
Of course don't forget, the monitor also delivers replication information. So you can keep track of topology, server type, position, errors, and log space.
While all this might not make an interesting movie like the Usual Suspects did, it does show that while a DBA might have a list of usual suspects when it comes to a problem, they also can lean on the tools available for a wealth of additional information.
MySQL Enterprise Edition
- Online DEMOS are available here
- MySQL Enterprise Backup
- MySQL Enterprise Monitor
- MySQL Enterprise HA
- MySQL Enterprise Scalability
- MySQL Enterprise Security
- MySQL Enterprise Audit
- White Papers
- Try Now
- Contact MySQL Sales
- Buy Now
More Reference urls:
- http://www.urbandictionary.com/define.php?term=keyser%20soze
- http://www.brentozar.com/archive/2012/10/learn-speak-dba-slang-terms/
- http://dev.mysql.com/doc/refman/5.5/en/mysql-benchmarks.html
- http://dev.mysql.com/doc/mysql-monitor/2.3/en/mem-query-analyzer-enabling-mysql.html
- http://dev.mysql.com/doc/mysql-monitor/2.3/en/mem-install.html
Friday, October 19, 2012
Amsterdam, MySQL User Group
A comment was recently posted on the MySQL User Group Wiki page about a new user group in the Netherlands available via Meetup.com.
I wanted to take a moment and say thank you and ask everyone to support this new user group.
If people are aware of any user groups not listed, please feel free to post on the wiki page this information.
I wanted to take a moment and say thank you and ask everyone to support this new user group.
If people are aware of any user groups not listed, please feel free to post on the wiki page this information.
Wednesday, October 17, 2012
MySQL Failover Utility
I was giving a replication talk at Ohio Linux Fest last week and we touched a little bit on the MySQL Failover Utility and how it works with MySQL 5.6 .
The first thing that this along with Innodb and other replication enhancements are big GPL offerings from Oracle to the community.
First the usage:
So I set up a test, I will monitor the master @ 192.168.0.17 and have a slave @ 192.168.0.7 all from a server @ 192.168.0.34.
Personally I would run this in screen, with a password on it, so I can have access to it easily from any location.
# screen
# ./mysqlfailover --master=root:<PASSWORD>@192.168.0.17 --discover-slaves-login=root --candidates=root:<PASSWORD>@192.168.0.7
Keep in mind that the password would be easily found in history and ps -ef views.
Now once it executes you realize that you never had GTID on in the first place.....
ERROR: Topology must support global transaction ids and have GTID_MODE=ON
This is simple enough but 'gtid_mode' is a read only variable so it must be done via the my.cnf file.
vi /etc/my.cnf
[mysqld]
gtid_mode =ON
disable-gtid-unsafe-statements =1
show variables like '%gtid%';
+--------------------------------+-----------+
| Variable_name | Value |
+--------------------------------+-----------+
| disable_gtid_unsafe_statements | ON |
| gtid_done | |
| gtid_lost | |
| gtid_mode | ON |
| gtid_next | AUTOMATIC |
| gtid_owned | |
+--------------------------------+-----------+
So now that those are all updated...
Again if your not in a screen this might be a good point to do so..
#screen
# ./mysqlfailover --master=root:<PASSWORD>@192.168.0.17 --discover-slaves-login=root --candidates=root:<PASSWORD>@192.168.0.7
# Discovering slaves for master at 192.168.0.17:3306
# Checking privileges.
# Checking privileges on candidates.
We get a simple display to start
MySQL Replication Failover Utility
Failover Mode = auto Next Interval = Wed Oct 3 13:52:01 2012
Master Information
------------------
Binary Log File Position Binlog_Do_DB Binlog_Ignore_DB
mysql56rc-bin.000016 151
Replication Health Status
+---------------+-------+---------+--------+------------+---------+
| host | port | role | state | gtid_mode | health |
+---------------+-------+---------+--------+------------+---------+
| 192.168.0.17 | 3306 | MASTER | UP | ON | OK |
+---------------+-------+---------+--------+------------+---------+
Q-quit R-refresh H-health G-GTID Lists U-UUIDs
Transactions executed on the servers:
+---------------+-------+---------+-----------------------------------------+
| host | port | role | gtid |
+---------------+-------+---------+-----------------------------------------+
| 192.168.0.17 | 3306 | MASTER | 98CCBD8A-EB09-11E1-B4D5-08002701A7D7:1 |
+---------------+-------+---------+-----------------------------------------+
UUIDs
+---------------+-------+---------+---------------------------------------+
| host | port | role | uuid |
+---------------+-------+---------+---------------------------------------+
| 192.168.0.17 | 3306 | MASTER | 98ccbd8a-eb09-11e1-b4d5-08002701a7d7 |
+---------------+-------+---------+---------------------------------------+
Since we are in screen we can control-A D and exit the screen and resume it later whenever we want to check on the status.
# screen -r
Now lets crash the master... a quick power off of the virtual box should do it.
The output now refreshes and soon displays the new master.
# Discovering slaves for master at 192.168.0.7:3306
MySQL Replication Failover Utility
Failover Mode = auto Next Interval = Wed Oct 17 08:50:19 2012
Master Information
------------------
Binary Log File Position Binlog_Do_DB Binlog_Ignore_DB
mysql56rc-bin.000020 191
Replication Health Status
+--------------+-------+---------+--------+------------+---------+
| host | port | role | state | gtid_mode | health |
+--------------+-------+---------+--------+------------+---------+
| 192.168.0.7 | 3306 | MASTER | UP | ON | OK |
+--------------+-------+---------+--------+------------+---------+
Now if you added the
Test it out with the new MySQL 5.6 RC... Oracle would love your feedback.
The first thing that this along with Innodb and other replication enhancements are big GPL offerings from Oracle to the community.
First the usage:
[root@mysql-master python]# ./mysqlfailover --help
Usage: mysqlfailover --master=roo@localhost --discover-slaves-login=root --candidates=root@host123:3306,root@host456:3306
mysqlfailover - automatic replication health monitoring and failover....
--candidates=CANDIDATES
connection information for candidate slave servers for
failover in the form:
<user>:<password>@<host>:<port>:<socket>. Valid only
with failover command. List multiple slaves in comma-
separated list.
--discover-slaves-login=DISCOVER
at startup, query master for all registered slaves and
use the user name and password specified to connect.
Supply the user and password in the form
user:password. For example, --discover-slaves-
login=joe:secret will use 'joe' as the user and
'secret' as the password for each discovered slave.
--exec-after=EXEC_AFTER
name of script to execute after failover or switchoverSo I set up a test, I will monitor the master @ 192.168.0.17 and have a slave @ 192.168.0.7 all from a server @ 192.168.0.34.
Personally I would run this in screen, with a password on it, so I can have access to it easily from any location.
# screen
# ./mysqlfailover --master=root:<PASSWORD>@192.168.0.17 --discover-slaves-login=root --candidates=root:<PASSWORD>@192.168.0.7
Keep in mind that the password would be easily found in history and ps -ef views.
Now once it executes you realize that you never had GTID on in the first place.....
ERROR: Topology must support global transaction ids and have GTID_MODE=ON
This is simple enough but 'gtid_mode' is a read only variable so it must be done via the my.cnf file.
vi /etc/my.cnf
[mysqld]
gtid_mode =ON
disable-gtid-unsafe-statements =1
show variables like '%gtid%';
+--------------------------------+-----------+
| Variable_name | Value |
+--------------------------------+-----------+
| disable_gtid_unsafe_statements | ON |
| gtid_done | |
| gtid_lost | |
| gtid_mode | ON |
| gtid_next | AUTOMATIC |
| gtid_owned | |
+--------------------------------+-----------+
So now that those are all updated...
Again if your not in a screen this might be a good point to do so..
#screen
# ./mysqlfailover --master=root:<PASSWORD>@192.168.0.17 --discover-slaves-login=root --candidates=root:<PASSWORD>@192.168.0.7
# Discovering slaves for master at 192.168.0.17:3306
# Checking privileges.
# Checking privileges on candidates.
We get a simple display to start
MySQL Replication Failover Utility
Failover Mode = auto Next Interval = Wed Oct 3 13:52:01 2012
Master Information
------------------
Binary Log File Position Binlog_Do_DB Binlog_Ignore_DB
mysql56rc-bin.000016 151
Replication Health Status
+---------------+-------+---------+--------+------------+---------+
| host | port | role | state | gtid_mode | health |
+---------------+-------+---------+--------+------------+---------+
| 192.168.0.17 | 3306 | MASTER | UP | ON | OK |
+---------------+-------+---------+--------+------------+---------+
Q-quit R-refresh H-health G-GTID Lists U-UUIDs
Transactions executed on the servers:
+---------------+-------+---------+-----------------------------------------+
| host | port | role | gtid |
+---------------+-------+---------+-----------------------------------------+
| 192.168.0.17 | 3306 | MASTER | 98CCBD8A-EB09-11E1-B4D5-08002701A7D7:1 |
+---------------+-------+---------+-----------------------------------------+
UUIDs
+---------------+-------+---------+---------------------------------------+
| host | port | role | uuid |
+---------------+-------+---------+---------------------------------------+
| 192.168.0.17 | 3306 | MASTER | 98ccbd8a-eb09-11e1-b4d5-08002701a7d7 |
+---------------+-------+---------+---------------------------------------+
Since we are in screen we can control-A D and exit the screen and resume it later whenever we want to check on the status.
# screen -r
Now lets crash the master... a quick power off of the virtual box should do it.
The output now refreshes and soon displays the new master.
# Discovering slaves for master at 192.168.0.7:3306
MySQL Replication Failover Utility
Failover Mode = auto Next Interval = Wed Oct 17 08:50:19 2012
Master Information
------------------
Binary Log File Position Binlog_Do_DB Binlog_Ignore_DB
mysql56rc-bin.000020 191
Replication Health Status
+--------------+-------+---------+--------+------------+---------+
| host | port | role | state | gtid_mode | health |
+--------------+-------+---------+--------+------------+---------+
| 192.168.0.7 | 3306 | MASTER | UP | ON | OK |
+--------------+-------+---------+--------+------------+---------+
Now if you added the
"--exec-after= " Test it out with the new MySQL 5.6 RC... Oracle would love your feedback.
Tuesday, October 16, 2012
RMOUG Training Days 2013 & MySQL
Call for Abstracts Deadline Extended until October 22!
MySQL Sessions are needed ! Submit an abstract for RMOUG Training Days 2013! They have extended the abstract submission deadline to Monday, October 22.
They are looking for presentations on the following topics:
- Application Development
- Business Intelligence
- Database Administration
- DBA Deep Dive
- Database Tools of the Trade
- Middleware
Visit www.rmoug.org for topic descriptions and details on how to submit your abstract online.
Sunday, October 14, 2012
MySQL Cluster - Web Scalability with Carrier Grade Availability
Just a quick note that the Colorado MySQL User Group will be have Craig Sylvester in town November 7th 2012 for a MySQL Cluster talk. Please feel free to RSVP and join us!
Thursday, October 11, 2012
SCREEN
Many of us know the joys of the "Screen" command. I did notice that this topic became a point of many questions at the recent Ohio LinuxFest, so I thought I could touch more on it here.
Being able to detach and reattach to a shell is a wonderful thing. It is very useful when executing long query transactions like MySQL data exports or even running backups at times. It is also very useful to be able to change computers or locations and keep the same working shell environment. I often used Screen when I started a shell script that executed a full compressed backup, scp the files to a remote slave, and then would start to uncompress the backup onto the new slave. The entire process for this was around 24hrs easily so being able to reattached and monitor the progress was very helpful.
Being able to have a visual display that is quick and clear as to what host your connected on is of course critical. A fast an easy way to know MySQL Hosts is also very valuable. At the very least you can change the mysql prompt in the my.cnf file
( ie my.cnf --> mysql --prompt=" this is a mysql box>" )
or just via your session
( mysql> prompt MySQL Master>
PROMPT set to 'MySQL Master> '
MySQL Master> show master status\G
).
Screen becomes helpful keeping the shells organized. Personally, I do not like to have a different colors in my shell backgrounds. A simple white or black is just fine for me.
Here are a few other things I do with Screen:
1st create or edit a file for yourself vi ~/.screenrc
I like to enhance my status line at the bottom with the following:
hardstatus string '%{gk}[ %{G}%H %{g}][%= %{wk}%?%-Lw%?%{=b kR}(%{W}%n*%f %t%?(%u)%?%{=b kR})%{= kw}%?%+Lw%?%?%= %{g}][%{Y}%l%{g}]%{=b C}[ %m/%d %c ]%{W}'
You end up with something like the following on the bottom of all screen windows.
[ Remote Hostname ][ (0*$ bash) ][1.00 1.00 1.00][ 03/07 0:20 ]
if you have multiple screens you get this:
[ Remote Hostname ][ (0*$ bash) (1*$ bash) ][1.00 1.00 1.00][ 03/07 0:20 ]
Yes you can have multiple screens just type screen when your inside a current screen to start another.
It is always best to name your screens as well.
Cntrl A then :
Then type "Title < title name>" of what you want to label the tab window. Your results are similar to below.
[ Remote Hostname ][ 0-$ MySQL_Master (1*$ MySQL_Slave) ][1.00 1.00 1.00][ 03/07 0:25 ]
Then Cntrl A <0--9> to switch between tab windows.
You can access a screen session via any computer that is allowed to connect to the screen host. So always keep in mind to lock your screen sessions.
Cntrl A password -- So you can lock with a password of your choice.
You might have several different Screen sessions so try to also name your screen sessions. You might be executing a MySQL dump in one Screen session and working with a data export in another.
ie:
screen -S MySQL_dump
-S sockname Name this session <pid>.sockname instead of <pid>.<tty>.<host>.
This naming comes in very handy when you have to reattach.
I often use the handy shell script found here: https://github.com/cep21/jackbash/blob/master/bin/screens
Another big advantage of Screen is being able to work with remote workers in training or just reviewing MySQL queries. For example, you can have a few different developers on the same screen session and execute explain on their recent queries so you can all review the best index options together.
If you want to learn more about that here is a nice article.
Some good tips on screen are also available here
http://www.softpanorama.org/Utilities/Screen/tips.shtml
http://polishlinux.org/howtos/screen-tips-tricks/
Being able to detach and reattach to a shell is a wonderful thing. It is very useful when executing long query transactions like MySQL data exports or even running backups at times. It is also very useful to be able to change computers or locations and keep the same working shell environment. I often used Screen when I started a shell script that executed a full compressed backup, scp the files to a remote slave, and then would start to uncompress the backup onto the new slave. The entire process for this was around 24hrs easily so being able to reattached and monitor the progress was very helpful.
Being able to have a visual display that is quick and clear as to what host your connected on is of course critical. A fast an easy way to know MySQL Hosts is also very valuable. At the very least you can change the mysql prompt in the my.cnf file
( ie my.cnf --> mysql --prompt=" this is a mysql box>" )
or just via your session
( mysql> prompt MySQL Master>
PROMPT set to 'MySQL Master> '
MySQL Master> show master status\G
).
Screen becomes helpful keeping the shells organized. Personally, I do not like to have a different colors in my shell backgrounds. A simple white or black is just fine for me.
Here are a few other things I do with Screen:
1st create or edit a file for yourself vi ~/.screenrc
I like to enhance my status line at the bottom with the following:
hardstatus string '%{gk}[ %{G}%H %{g}][%= %{wk}%?%-Lw%?%{=b kR}(%{W}%n*%f %t%?(%u)%?%{=b kR})%{= kw}%?%+Lw%?%?%= %{g}][%{Y}%l%{g}]%{=b C}[ %m/%d %c ]%{W}'
You end up with something like the following on the bottom of all screen windows.
[ Remote Hostname ][ (0*$ bash) ][1.00 1.00 1.00][ 03/07 0:20 ]
if you have multiple screens you get this:
[ Remote Hostname ][ (0*$ bash) (1*$ bash) ][1.00 1.00 1.00][ 03/07 0:20 ]
Yes you can have multiple screens just type screen when your inside a current screen to start another.
It is always best to name your screens as well.
Cntrl A then :
Then type "Title < title name>" of what you want to label the tab window. Your results are similar to below.
[ Remote Hostname ][ 0-$ MySQL_Master (1*$ MySQL_Slave) ][1.00 1.00 1.00][ 03/07 0:25 ]
Then Cntrl A <0--9> to switch between tab windows.
You can access a screen session via any computer that is allowed to connect to the screen host. So always keep in mind to lock your screen sessions.
Cntrl A password -- So you can lock with a password of your choice.
You might have several different Screen sessions so try to also name your screen sessions. You might be executing a MySQL dump in one Screen session and working with a data export in another.
ie:
screen -S MySQL_dump
-S sockname Name this session <pid>.sockname instead of <pid>.<tty>.<host>.
This naming comes in very handy when you have to reattach.
I often use the handy shell script found here: https://github.com/cep21/jackbash/blob/master/bin/screens
Another big advantage of Screen is being able to work with remote workers in training or just reviewing MySQL queries. For example, you can have a few different developers on the same screen session and execute explain on their recent queries so you can all review the best index options together.
If you want to learn more about that here is a nice article.
Some good tips on screen are also available here
http://www.softpanorama.org/Utilities/Screen/tips.shtml
http://polishlinux.org/howtos/screen-tips-tricks/
Monday, October 8, 2012
Thanks for the support!
I wanted to post a big thanks to the Chinese MySQL Bloggers. Almost a month ago we published the Chinese version of Planet ( my previous blog post ). In the last month, we have collected 68 different blog posts about MySQL across 8 different MySQL Bloggers.
Thanks for the support, this is an encouraging start.
Thanks for the support, this is an encouraging start.
Subscribe to:
Posts (Atom)