Oct
31
2013
--

Percona XtraDB Cluster/ Galera with Percona Monitoring Plugins

The Percona Monitoring Plugins (PMP) provide some free tools to make it easier to monitor PXC/Galera nodes.  Monitoring broadly falls into two categories: alerting and historical graphing, and the plugins support Nagios and Cacti, respectively, for those purposes.

Graphing

An update to the PMP this summer (thanks to our Remote DBA team for supporting this!) added a Galera-specific host template that includes a variety of Galera-related stats, including:

  • Replication traffic and transaction counts and average trx size
  • Inbound and outbound (Send and Recv) queue sizes
  • Parallelization efficiency
  • Write conflicts (Local Cert Failures and Brute Force Aborts)
  • Cluster size
  • Flow control

You can see examples and descriptions of all the graphs in the manual.

Alerting

There is not a Galera-specific Nagios plugin in the PMP yet, but there does exist a check that can pretty universally check any status variable you like called pmp-check-mysql-status.  We can pretty easily adapt this to check some key action-worthy Galera stats, but I hadn’t worked out the details until a customer requested it recently.

Checking for a Primary Cluster

Technically this is a cluster or cluster-partition state for whatever part of the cluster the queried node is a part of.  However, any single node could be disconnected from the rest of the cluster, so checking this on each node should be fine.  We can verify this with this check:

$ /usr/lib64/nagios/plugins/pmp-check-mysql-status -x wsrep_cluster_status -C == -T str -c non-Primary
OK wsrep_cluster_status (str) = Primary | wsrep_cluster_status=Primary;;non-Primary;0;

Local node state

We also want to verify the given node is ‘Synced’ into the cluster and not in some other state:

/usr/lib64/nagios/plugins/pmp-check-mysql-status -x wsrep_local_state_comment -C '!=' -T str -w Synced
OK wsrep_local_state_comment (str) = Synced | wsrep_local_state_comment=Synced;;Synced;0;

Note that we are only  warning when the state is not Synced — this is because it is perfectly valid for a node to be in the Donor/Desynced state.  This warning can alert us to a node in a less-than-ideal state without screaming about it, but you could certainly go critical instead.

Verify the Cluster Size

This is a bit of a sanity check, but we want to know how many nodes are in the cluster and either warn if we’re down a single node or go critical if we’re down more.  For a three node cluster, your check might look like this:

# /usr/lib64/nagios/plugins/pmp-check-mysql-status -x wsrep_cluster_size -C '<=' -w 2 -c 1
OK wsrep_cluster_size = 3 | wsrep_cluster_size=3;2;1;0;

This is OK when we have 3 nodes, warns at 2 nodes and goes critical at 1 node (when we have no redundancy left).   You could certainly adjust thresholds differently depending on your normative cluster size.   This check is likely meaningless unless we’re also in a Primary cluster, so you could set a service dependency on the Primary Cluster check here.

Check for Flow Control

Flow control is really something to keep an eye on in your cluster. We can monitor the recent state of flow control like this:

/usr/lib64/nagios/plugins/pmp-check-mysql-status -x wsrep_flow_control_paused -w 0.1 -c 0.9
OK wsrep_flow_control_paused = 0.000000 | wsrep_flow_control_paused=0.000000;0.1;0.9;0;

This warns when FC exceeds 10% and goes critical after 90%.  This may need some fine tuning, but I believe it’s a general principle that some small amount of FC might be normal, but you want to know when it starts to get more excessive.

Conclusion

Alerting with Nagios and Graphing with Cacti tend to work best with per-host checks and graphs, but there are aspects of a PXC cluster that you may want to monitor from a cluster-wide perspective.  However, most of the things that can “go wrong” are easily detectable with per-host checks and you can get by without needing a custom script that is Galera-aware.

I’d also always recommend what I call a “service check” that connects through your VIP or load balancer to ensure that MySQL is available (regardless of underlying cluster state) and can do a query.  As long as that works (proving there is at least 1 Primary cluster node), you can likely sleep through any other cluster event.  :)

The post Percona XtraDB Cluster/ Galera with Percona Monitoring Plugins appeared first on MySQL Performance Blog.

Oct
30
2013
--

Talking Drupal #021 – Multisite

Show Topics
– What is multisite?
– Benefits of multisite
– Single Database and Multiple Databases
– Multi-site vs Domain module
– Security (SLL Cert)
Modules
– Login Toboggan – https://drupal.org/project/logintoboggan
– Domain module – https://drupal.org/project/domain
Links
– https://drupal.org/documentation/install/multi-site
– https://twitter.com/buildamodule
Hosts
– Stephen Cross – www.ParallaxInfoTech.com @stephencross
– Jason Pamental – www.hwdesignco.com @jpamental
– John Picozzi – www.RubicDesign.com @johnpicozzi 
– Nic Laflin – www.nLightened.net @nicxvan
Oct
30
2013
--

Talking Drupal #021 – Multisite

Show Topics
– What is multisite?
– Benefits of multisite
– Single Database and Multiple Databases
– Multi-site vs Domain module
– Security (SLL Cert)
Modules
– Login Toboggan – https://drupal.org/project/logintoboggan
– Domain module – https://drupal.org/project/domain
Links
– https://drupal.org/documentation/install/multi-site
– https://twitter.com/buildamodule
Hosts
– Stephen Cross – www.ParallaxInfoTech.com @stephencross
– Jason Pamental – www.hwdesignco.com @jpamental
– John Picozzi – www.RubicDesign.com @johnpicozzi 
– Nic Laflin – www.nLightened.net @nicxvan
Oct
30
2013
--

InnoDB adaptive flushing in MySQL 5.6: checkpoint age and io capacity

In MySQL 5.6 InnoDB has a dedicated thread (page_cleaner) that’s responsible for performing flushing operations. Page_cleaner performs flushing of the dirty pages from the buffer pool based on two factors:
access pattern  –  the least recently used pages will be flushed by LRU flusher from LRU_list when buffer pool has no free pages anymore;
age – the oldest modified non-flushed pages are part of flush_list structure and will be flushed by flush_list flusher based on several heuristics.

There is a good overview of the page_cleaner and also here you may find some details about flushing in MySQL 5.6. Below I describe several additional aspects of the flush_list flushing that was not really covered yet.

flush_list flushing and checkpoint age

The amount of the aged pages that is possible to keep in the flush_list is limited by the combined size of the innodb log files. So the main purpose of the flush_list flushing is to flush pages from this list with such a rate that will also always allow enough free space in the log files. On the other hand, too aggressive flushing means less write combining, unnecessary load on the I/O subsystem, in the end undoing performance benefits of having larger redo logs.  In MySQL 5.6 the amount of pages to flush is calculated in the InnoDB adaptive routine based on the current checkpoint age with the following formula:

 
percentage of the IO capacity that should be used for flushing =
        ((srv_max_io_capacity / srv_io_capacity) * (lsn_age_factor * sqrt(lsn_age_factor))) / 7.5;

We modeled that formula in R and found that it’s possible to improve it such a way that the curve becomes more flat and as a result flushing becomes less aggressive. That new formula is enabled in Percona Server 5.6 by default.

Rplot04

flush_list flushing and io_capacity

InnoDB provides two variables that allow the control of the background flushing rate – innodb_io_capacity and innodb_io_capacity_max. There is quite a detailed description for these vars. However there are several things that are not really covered in the documentation:

innodb_io_capacity_max is the most important variable in case of adaptive flushing as only that variable actually limiting the flushing rate. See above formula and charts.

innodb_io_capacity is used for limiting IO operations during merging of the insert buffer and flushing in cases of server inactivity/shutdown.

For practical needs, the above means the following:

– if  the MySQL server is in an active state (serving user requests) you need to adjust innodb_io_capacity_max to increase/decrease flushing rate.
– if the MySQL server is in an idle state or performing shutdown flushing of the pages from flush_list will be limited by innodb_io_capacity value only.

– if change_buffering is ON and server is in active state it will allow to use either 5% of innodb_io_capacity or vary rate from 5% to 55%  if more than 50% of insert buffer size was already used.
– if change_buffering is ON and server is idle it will use 100% of innodb_io_capacity for merge operations

The post InnoDB adaptive flushing in MySQL 5.6: checkpoint age and io capacity appeared first on MySQL Performance Blog.

Oct
28
2013
--

MySQL on Windows: A survival guide for Linux-based DBAs

MySQL on Windows: A survival guide for Linux-based DBAsNext week, on Nov. 6, I will be delivering a webinar about running MySQL on Windows, with a strong focus on Linux-based sysadmins and DBAs – and how not to go crazy in the process.

An interesting (and challenging!) part of working for Percona is that you never know what kind of setup a customer will have, and even though MySQL is still strongly tied to the LAMP stack and therefore Linux, more people are running it on Windows these days.

As someone who last used Windows on a daily basis in 1999, my first reaction was usually not nice. But over time, I have learned to embrace these kind of cases as an opportunity to get out of my comfort zone and learn. I still personally prefer a Unix derivative, but over time, I have gathered some knowledge that I think can be useful to others who arrive at MySQL on Windows from a Linux/Unix background. And who knows? Perhaps I can even give some insight to longtime Windows admins who are newcomers to the world of MySQL!

If you’re interested, register here to attend. The webinar starts at 10 a.m. PST on Nov. 6. It will also be recorded and the replay available using that same link.

The post MySQL on Windows: A survival guide for Linux-based DBAs appeared first on MySQL Performance Blog.

Oct
28
2013
--

MySQL 5.6 New Replication Features: Webinar followup Q&A

Percona MySQL webinar Q&A: 5.6 New Replication FeaturesI want to thank all attendees of my webinar, “MySQL 5.6 New Replication Features: Benefits, Challenges and Limitations“. We had questions that I didn’t have the time to answer:

Q: If I run on Amazon’s RDS, do I need to worry about enabling crash-safe slaves, or is that already in place?

A: Crash-safe replication is already configured for read replicas using MySQL 5.6.

Q: How the relay log purge will manage in case of multiple db’s replication running on multiple threads?

A: Same thing as with single-threaded replication: when all event in a relay log file have been executed, the relay log is removed. The only difference is that executing the last event of a file no longer means that all previous events have been executed, because execution gaps can happen with multi-threaded replication. However a checkpoint is performed from time to time (see slave_checkpoint_period setting, default is 300ms) to make sure that no event is left behind. In practice, you should not notice any difference between the purge of relay logs with single-threaded replication and with multi-threaded replication.

Q: How can we make slave only for read purpose similar to AWS RDS MASTER- SLAVE Replication where slave is read only?

A: You can set read_only = 1 on the slave. The slave won’t be strictly read-only because all users with the SUPER privilege will be able to write to the slave anyway. But if you don’t grant the SUPER privilege to your users, the slave will act as a true read-only server. This is what happened on RDS read replicas: you don’t have the SUPER privilege so you can’t write on replicas.

Q: How can binlog position be higher on a slave compared to the master – for position-based replication?

A: Each time you restart MySQL, a new binary log file will be created. So let’s say that we start a master and its slave (the slave being configured with log_slave_updates to write events received by replication in its own binary logs), both binary logs will be mysql-bin.0000001. If we now restart the slave twice, the slave will write in mysql-bin.0000003 while the master will still be writing on mysql-bin.0000001.

Q: Can we change statement-based replication to mixed replication after 1000+ transactions or not? What will be the impact?

A: You can easily switch to mixed replication as the binlog_format setting is a dynamic variable. Mixed replication means using statement-based replication by default and switching to row-based replication only for queries that are not safe for statement-based replication. So it is usually quite safe to switch from statement-based to mixed replication.

Q: server_id and server UUID – what is the difference? Do we need both simultaneously?

A: server_id and server_uuid are both identifiers of each server in a replication topology. server_id is used by replication and server_uuid is used to generate GTIDs (server_uuid has been added in MySQL 5.6). You need both.

Q: How to clarify compatibility of GTID and multi-threaded; is there any plans to fix it by Percona?

A: GTID and multi-threaded replication are compatible. The only concern is that the monitoring tools (SHOW SLAVE STATUS and the mysql.slave_relay_log_info table) are confusing when using both. This could make quite hard to fix replication if you have a replication error. We don’t have any plan to fix that at the moment.

Q: What will happen if GTID is used and a transaction that creates a temporary table is run on the master?

A: When enforce-gtid-consistency is set to ON, temporary tables are only allowed if autocommit = 1. Otherwise this will generate an error.

Q: How could remote binary log be used for backups?

A: It can allow you to mirror the binary logs in real time. However this doesn’t replace backups. You can find an example here.

Q: What is the difference between semi-synchrous replication and gtid replication?

A: By default, replication is asynchronous and doesn’t use GTIDs. Optionally, you can enable semi-sync replication to make sure at least one slave has acknowledged the writes from the master, and you can also enable GTIDs (with or without semi-sync replication) to make replication reconfiguration easier.

The post MySQL 5.6 New Replication Features: Webinar followup Q&A appeared first on MySQL Performance Blog.

Oct
28
2013
--

Percona Server 5.5.34-32.0 is now available

Percona Server version 5.5.34-32.0

Percona Server version 5.5.34-32.0

Percona is glad to announce the release of Percona Server 5.5.34-32.0 on October 28th, 2013 (Downloads are available here and from the Percona Software Repositories). Based on MySQL 5.5.34, including all the bug fixes in it, Percona Server 5.5.34-32.0 is now the current stable release in the 5.5 series. All of Percona‘s software is open-source and free, all the details of the release can be found in the 5.5.34-32.0 milestone at Launchpad.

New Features:

  • Percona Server has extended the SELECT INTO ... OUTFILE and SELECT INTO DUMPFILE to add the support for UNIX sockets and named pipes.
  • Percona Server now provides additional information in the slow query log when log_slow_rate_limit variable is enabled.
  • A new variable slow_query_log_always_write_time has been introduced. It can be used to specify an additional execution time threshold for the slow query log, that, when exceeded, will cause a query to be logged unconditionally, that is, log_slow_rate_limit will not apply to it.
  • Utility user feature has been extended by adding a new utility_user_privileges that allows a comma separated value list of extra access privileges that can be granted to the utility user.

Bugs Fixed:

  • Due to an incompatible upstream change that went in unnoticed, the log tracker thread would attempt to replay any file operations it encountered. In most cases this were a no-op, but there were race conditions for certain DDL operations that would have resulted in server crash. Bug fixed #1217002.
  • apt-get upgrade of Percona Server would fail in post-installation step if server failed to start. Bug fixed #1002500.
  • Fixed the libssl.so.6 dependency issues in binary tarballs releases. Bug fixed #1172916.
  • Error in install_layout.cmake could cause that some library files, during the build, end up in different directories on x86_64 environment. Bug fixed #1174300.
  • Percona Server could crash while accessing BLOB or TEXT columns in InnoDB tables if Support for Fake Changes was enabled. Bug fixed #1188168.
  • Memory leak was introduced by the fix for bug #1132194. Bug fixed #1204873.
  • The unnecessary overhead from persistent InnoDB adaptive hash index latching has been removed, potentially improving stability of the Multiple Adaptive Hash Search Partitions feature as well. Upstream bug fixed #70216, bug fixed #1218347.
  • Fixed the incorrect dependency with libmysqlclient18-dev from Percona Server 5.5.33-31.1. Bug fixed #1237097.
  • A memory leak in Utility user feature has been fixed. Bug fixed #1166638.
  • Expanded Program Option Modifiers did not deallocate memory correctly. Bug fixed #1167487.
  • A server could crash due to a race condition between a INNODB_CHANGED_PAGES query and a bitmap file delete by PURGE CHANGED_PAGE_BITMAP or directly on the file system. Bug fixed #1191580.
  • Percona Server could not be built with Thread Pool feature and -DWITH_PERFSCHEMA_ENGINE=OFF option. Bug fixed #1196383.
  • Building Percona Server with -DHAVE_PURIFY option would result in an error. Fixed by porting the close_socket function from MariaDB. Bug fixed #1203567.
  • Adaptive hash index memory size was incorrectly calculated in SHOW ENGINE INNODB STATUS and Innodb_mem_adaptive_hash status variable. Bug fixed #1218330.
  • Some Expanded Program Option Modifiers didn’t have an effect if they were specified in non-normalized way (innodb_io_capacity vs innodb-io-capacity). Bug fixed #1233294.
  • Enabling Enforcing Storage Engine feature could lead to error on Percona Server shutdown. Bug fixed #1233354.
  • Storage engine enforcement (enforce_storage_engine) is now ignored when the server is started in either bootstrap or skip-grant-tables mode. Bug fixed #1236938.
  • Fixed the build warnings caused by User Statistics code on non-Linux platforms. Bug fixed #711817.
  • Adaptive hash indexing partitioning code has been simplified, potentially improving performance. Bug fixed #1218321.

Other bugs fixed: bug fixed #1239630, bug fixed #1191589, bug fixed #1200162, bug fixed #1214449, and bug fixed #1190604.

Release notes for Percona Server 5.5.34-32.0 are available in our online documentation. Bugs can be reported on the launchpad bug tracker.

The post Percona Server 5.5.34-32.0 is now available appeared first on MySQL Performance Blog.

Oct
28
2013
--

Percona Server 5.1.72-14.10 is now available

Percona Server version 5.1.72-14.10

Percona Server version 5.1.72-14.10

Percona is glad to announce the release of Percona Server 5.1.72-14.10 on October 28th, 2013 (Downloads are available here and from the Percona Software Repositories). Based on MySQL 5.1.72, including all the bug fixes in it, Percona Server 5.1.72-14.10 is now the current stable release in the 5.1 series. All of Percona‘s software is open-source and free, all the details of the release can be found in the 5.1.72-14.10 milestone at Launchpad.

Bugs Fixed:

  • Due to an incompatible upstream change that went in unnoticed, the log tracker thread would attempt to replay any file operations it encountered. In most cases this were a no-op, but there were race conditions for certain DDL operations that would have resulted in server crash. Bug fixed #1217002.
  • apt-get upgrade of Percona Server would fail in post-installation step if server failed to start. Bug fixed #1002500.
  • Fixed the libssl.so.6 dependency issues in binary tarballs releases. Bug fixed #1172916.
  • Percona Server could crash server could crash while accessing BLOB or TEXT columns in InnoDB tables if Support for Fake Changes was enabled. Bug fixed #1188168.
  • A server could crash due to a race condition between a INNODB_CHANGED_PAGES query and a bitmap file delete by PURGE CHANGED_PAGE_BITMAP or directly on the file system. Bug fixed #1191580.

Other bug fixes: bug fixed #1191589.

Release notes for Percona Server 5.1.72-14.10 are available in our online documentation. Bugs can be reported on the launchpad bug tracker.

The post Percona Server 5.1.72-14.10 is now available appeared first on MySQL Performance Blog.

Oct
26
2013
--

Ocean of Dust: Glossary

Final147x220Have you read Ocean of Dust and wondered what all those strange words meant? I thought about including a glossary in the book, and might add one for a future revision. Meanwhile, for your edification, here it is. It includes characters and a handy pronunciation guide. Isn’t it funny when you pronounce something one way, and then realize the author intended something entirely different. Let me know which ones you got wrong in the comments. Enjoy. :) Oh, and don’t miss the link to some piccies at the end.

Adilo  – (a-DEE-low) Base star of the Drakbar constellation. Brightest star in the sky, a deep orange colour.

Aggleberry  – Blackberry-like fruit used to make pies.

Alice  – 16-year old galley girl.

Anjan  – Main God of the people.

Azk-ore  – Radioactive stone that can be heated to high temperatures if agitated by Flux energy. Perfect for ovens.

Bandit  – Popular card game.

Bardas  – Sailor with bulging eyes and a serpent tattoo on his cheek.

Bell  – One hour.

Bem-spice – Sweet flavouring, a little like ginger.

Blab  – Burly, bald sailor.

Branda  – (BRAN-da) 12-year old Valinese girl. Lissa’s best friend.

Carg  – Scrawny sailor.

Cook  – Her real name is Madam Margaret, but most people call her Cook. Gaunt, skeletal woman.

Coy  – 13-year old boy.

Crawlie  – Spider.

Crew Chief  – See Sam.

Criandor  – (cree-AN-door) Ship’s Physiker. Elderly man with grey air, spectacles and a cane.

Dajech  – (da-JEK) Herb that induces sleep.

Deckbones  – Dice game played with cubes carved from bone.

Drakbar  – A star constellation shaped like a double V.

Druja — (DREW-ja) Country on the western continent. Drujans are obvious by their curly hair, dazzling yellow eyes and that men and women wear ear and hair jewelry.

Echpla  – (ESCH-pla) Valinese curse word.

Dujin  – Coin.

Edap  – Third largest of the 4 moons.

Eight-day  – One week.

Eldap  – Smallest of the 4 moons.

Eldrar  – Larger of the twin suns, blue/white in colour.

Etra  – Country north west of Markka, home of the University of Flux Navigation.

Fair Maiden of Yamin, The  – Captain Porrensa’s trading ship on the Dust Ocean.

Fak  – Red powder, sweet, addictive, often used to flavour Gej-juice.

Farq  – (FARK) Ship Master. Weasely-faced , cruel man. Wears a single brunette braid that reaches the middle of his back.

Flux  – Electro-magnetic currents that flow beneath the Dust Ocean, harnessed by ships using metal plates called Flux Vanes, and then used to power and move the ship.

Gal-mas  – A fealty that one person swears to another, to serve them until the end of their days.

Gardens of Eternity  – A sanctuary for the dead, prior to travelling to Heaven. Dead souls are ferried by the servants of Anjan to the second moon, Labago.

Gej-juice  – Yellow/green coloured cold drink.

Gilli-grass  – Used in the care of livestock, a hay-like grass.

Globelight  – A crystal-like orb that can store power when charged by Flux, and release it as light.

Goballian  – Principality west of Pelen.

Gobar  – Chief port city of Goballian.

Gowser-monkeys  – Agile apes that swing through trees.

Grad  – Large sailor with a thick brown beard.

Hoobin  – Beet vegetable.

Hossiw  – (HOSS-eww) Fortified, spiced wine.

Imyan  – (IM-yan) The native people of Us-imyan.

Indar  – Smaller of the twin suns, yellow in colour.

Jab-bird  – Tasty, turkey-like birds.

Jalak  – Its leaf is used to make a hot, stimulating drink, like tea.

Jaleraj  – (JAL-eh-RAJ) Chief port in Patraj.

Jancid  – (JAN-sid) Elderly, white-haired sailor.

Jeffsa  – 12-year old boy, one of Mampalo’s navigation students.

Jeranda  – Kingdom in which lies Lissa’s home town of Pelen.

Jherodan – Large nut, like a coconut with yellow, edible flesh inside.

Kee-shar  – Klynak phrase for the ship’s Captain, literally “leader”.

Klynaks  – Squid-like creatures that live in the Dust Ocean. They have brown domed heads with 4 stumpy horns that glow green from within.

Labago  – (la-BAY-go) Second largest of the 4 moons, white, about twice the brightness of Venus.

Lan – Tuber vegetable.

Lanaling  – Herb used to soothe pain.

Logay  – Stew.

Lyndon  – (LIN-dun) 14-yr old son of a rich merchant of Pelen.

Lyssa  – (LISS-a) Heroine. 14-year old girl with long, auburn hair.

Mampalo  – (mam-PAH-low) Also referred to as Mamp. 18-year old ship’s officer. A Drujan.

Margaret, Madam  – See Cook.

Markka  – Country to the west of Goballian.

Medepo  – (meh-DEEP-o) Largest of the 4 moons, orange in colour and about 1/4 size of Earth’s moon.

Moon-cycle  – One month, or 45 days.

Mulan  – Hairless livestock, larger than a goat but smaller than a cow.

Mursch  – (MURSH) “Amazing” in Valinese.

Nab  – Sailor.

Nib  – Sam’s second. Cocky and mean and disliked among the crew.

Oban  – (oh-BARN) Ship’s navigator. Haggard, with weathered skin and horrible, pulsing blue veins. Dirty, almost purple eyes.

Oglon  – Bison-like animals that can be eaten or used to pull carts.

Oodspal  – A breakfast something like grits or porridge.

Pastoy  – Spicy, creamy dip that resembles hummus.

Patraj  – (peh-TRAJ) Country north-east of the uninhabited island.

Pecknut  – Green-shelled nut that tastes like a pecan. Often used to make pies.

Pelen  – Town where Lissa, Pete and Lyndon are from, in the country of Jerranda.

Pete  – 13-year old boy.

Physiker  – (FIZZ-ick-ker) See Criandor.

Porrensa  – (puh-REN-sah) Captain of The Fair Maiden of Yamin. Wears a pair of brunette braids that reach his waist.

Pwam – Mango-like fruit. The green-blotched rind is inedible and gives the runs. The pale, chewy interior is delicious.

Quarter  – 15 minutes.

Sakdra  – Woodwind instrument like an oboe. Valinese women play a unique version of this instrument fashioned entirely from crystal.

Sam  – Crew Chief on board ship. Huge, giant of a man with a drooping black beard tied into two braids with purple ribbons.

Sawall  – (sah-WALL) Young, balding sailor.

Sebar  – Canine.

Seben  – (SEE-ben) Young sailor.

Shee-amar  – “tit for tat” in Valinese.

Ship Master  – First officer that reports only to the Captain. See Farq.

Sigilits  – (SIJ-ee-lits) Guitar-like instrument.

Soapsand  – Sand that foams and cleans when damp.

Solag  – Brown-haired, pig-like livestock.

Spoola  – Root vegetable with a buttery taste.

Sunturn  – One year, or 15 Moon-cycles, or 675 days.

Sweet-crystals  – Sugar.

Tagrak  – Mountain lion.

Tarba  – Ship’s officer, wears a short, blonde ponytail.

Totalamon  – God of the sea or ocean, often abbreviated to “Totey”.

Us-imyan  – (OOS-IM-yan) Small island in middle of the Dust Ocean, acts as a trading center.

Valin  – (VAH-lin) Country on southern continent. Valinese (like Branda) are short, almost elfin people. Girls usually have short-cut blonde hair and tattoos on their forehead.

Vraschatta  – (vra-SHAT-tah) “Good Night” in Valinese.

War-blit  – Huge, hornet-like insect, its body covered in red stripes.

Y’Seliche  – (EE-sell-EESH) Tall and thin creatures of enormous intelligence, often used as advisors and ambassadors.

Yat  – Fat and ugly sailor.

Zrak  – (zz-RACK) Large lizard, about 4 feet long with a sharp horn in its forehead. Its eyes seem to glow green.

 

Pictures of Lissa and Alice drawn by Jilliane, a friend of the family.

 

Oct
25
2013
--

PHP Summit 2013

PHP Summit 2013 – 12 Trainer mit 18 Workshops zu allen wichtigen PHP-Themen

Die Entwickler Akademie präsentiert in Kooperation mit dem PHP Magazin vom 2. bis 4. Dezember 2013 den nächsten PHP Summit, diesmal in Berlin. Und ich habe die Ehre dieses Mal beim PHP Summit gleich 2 Workshops zu halten.

Der erste Workshop wird die Twig-Template-Engine behandeln (ohne Symfony), im zweiten Workshop wird es um Symfony2 gehen.

Das große PHP Trainingesevent bietet innerhalb von drei Tagen 18 Workshops und zwei Abendvorträge. Alle Workshops beziehen sich auf eine gemeinsame Zielanwendung. Alle Trainer lösen Teile, der sich aus der Spezifikation ergebenden Aufgabe mit ihrer jeweiligen Technologie bzw. ihres Frameworks. Die Teilnehmer können auf diese Weise perfekt vergleichen, wie man in unterschiedlichen Frameworks tendenziell die gleiche Herausforderungen löst. Zwölf der bekannte PHP-Experten vermitteln im PHP Summit ihr Wissen: Sebastian Bergmann, Arne Blankerts, Benjamin Eberlei, Ralf Eggert, Jens Grochtdreis, Sebastian Heuer, Timo Haberkern, Sebastian Heuer, Robert Lemke, Stefan Priebsch, Ulf Wendel und Jakob Westhoff. Alle Infos zum PHP Summit finden Interessenten auf: www.php-summit.de.

 

flattr this!

Powered by WordPress | Theme: Aeros 2.0 by TheBuckmaker.com