• Q1, Will the definition sql of the triggers be replicated?
• Q2, Will the data manipulation sqls triggered by triggers be replicated?
• Q3, Will the data manipulation sqls on this table that issued by applications be replicated?

It’s basically not an issue if you have some understandings of MySQL. But sometimes things are a little different in real world, and it may mess you up.
The answers of these questions depend on which version of MySQL you are running.

MySQL 5.0

The answers are as below.

Q1: Triggers that exist on master side must be re-created on the slave server. Once this is done, the replication flow works as any other standard DML statement that participates in replication.
Q2: NO. SQLs generated by Triggers are not replicated.
Q3: Yes. There is no side effect to triggers.
Reference:  MySQL 5.0 FAQ: Triggers

MySQL 5.1, 5.5 and 5.6

Q1: Re-create of the trigger definition is needed.
Q2: YES for row-based replication, but NO for statement-based replication.
Q3: Yes

The answers depend on whether you are using statement-based or row-based replication. For statement-based replication, it works the same MySQL-5.0. While on row-based replication, the answer for Q2 is YES, the changes caused by executing the trigger on master side are applied on the slave.

Mind that the triggers are not actually executed on slave under row-based replication, in case of being applied twice. In other words, the outcome is the same for both row-based and statement-based replication.

Accordingly, if you have different triggers defined on master and slave, you cannot use row-based replication.

References:

• MySQL 5.1 FAQ: Triggers
• MySQL 5.5 FAQ: Triggers
• MySQL 5.6 FAQ: Triggers

Functionality Added or Changed

Bugs Fixed

• InnoDB Storage Engine: A failed CREATE INDEX operation for an InnoDB table could result in some memory being allocated and not freed. This memory leak could affect tables created with the ROW_FORMAT=DYNAMIC and ROW_FORMAT=COMPRESSED settings. (Bug #12699505)
• Partitioning: Auto-increment columns of partitioned tables were checked even when they were not being written to. In debug builds, this could lead to a crash of the server. (Bug #11765667, Bug #58655)
• Partitioning: The UNIX_TIMESTAMP() function was not treated as a monotonic function for purposes of partition pruning. (Bug #11746819, Bug #28928)
• Replication: If a LOAD DATA INFILE statement—replicated using statement-based replication—featured a SET clause, the name-value pairs were regenerated using a method (Item::print()) intended primarily for generating output for statements such as EXPLAIN EXTENDED, and which cannot be relied on to return valid SQL. This could in certain cases lead to a crash on the slave.To fix this problem, we now name each value in its original, user-supplied form, and use that to create LOAD DATA INFILEstatements for statement-based replication. (Bug #11902767, Bug #60580)See also Bug #34283, Bug #11752526, Bug #43746.
• Compiling the server with maintainer mode enabled failed for gcc 4.6 or higher. (Bug #12727287)
• The option-parsing code for empty strings leaked memory. (Bug #12589928)
• Previously, an inappropriate error message was produced if a multiple-table update for an InnoDB table with a clustered primary key would update a table through multiple aliases, and perform an update that may physically move the row in at least one of these aliases. Now the error message is: Primary key/partition key update is not permitted since the table is updated both as ‘tbl_name1‘ and ‘tbl_name2‘(Bug #11882110)See also Bug #11764529.
• ALTER TABLE {MODIFY|CHANGE} … FIRST did nothing except rename columns if the old and new versions of the table had exactly the same structure with respect to column data types. As a result, the mapping of column name to column data was incorrect. The same thing happened for ALTER TABLE DROP COLUMN, ADD COLUMN statements intended to produce a new version of table with exactly the same structure as the old version. (Bug #61493, Bug #12652385)
• Incorrect handling of metadata locking for FLUSH TABLES WITH READ LOCKfor statements requiring prelocking caused two problems:
  • Execution of any data-changing statement that required prelocking (that is, involved a stored function or trigger) as part of transaction slowed down somewhat all subsequent statements in the transaction. Performance in a transaction that periodically involved such statements gradually degraded over time.
  • Execution of any data-changing statement that required prelocking as part of transaction prevented a concurrent FLUSH TABLES WITH READ LOCK from proceeding until the end of transaction rather than at the end of the particular statement.

  (Bug #61401, Bug #12641342)

• The fractional part of the “Queries per second” value in MySQL status output could be displayed incorrectly. (Bug #61205, Bug #12565712)
• LOAD DATA INFILE incorrectly parsed relative data file path names that ascended more than three levels in the file system and as a consequence was unable to find the file. (Bug #60987, Bug #12403662)
• For unknown users, the native password plugin reported incorrectly that no password had been specified even when it had. (Bug #59792, Bug #11766641)
• For MyISAM tables, attempts to insert incorrect data into an indexed GEOMETRY column could result in table corruption. (Bug #57323, Bug #11764487)
• In debug builds, Field_new_decimal::store_value() was subject to buffer overflows. (Bug #55436, Bug #11762799)
• A race condition between loading a stored routine using the name qualified by the database name and dropping that database resulted in a spurious error message: The table mysql.proc is missing, corrupt, or contains bad data (Bug #47870, Bug #11756013)

NOTE: On a MySQL replication environment, users must be careful in deleting binary logs. If slaves are lagging behind the server SOME days, the binary log purge might cause replication to fail. Make sure the logs file are not in use before removing them!

In any case here are some useful examples for purging binary log files easiliy. We’ll show you two quick ways on deleting the expired bin-log files.

As the purge work here is issued by mysql itself, please make sure you have MySQL-4.1 and later version installed. For version 4.0 and 3.xx, it does not support the following feathers.

1, Delete MySQL bin-log files by PURGE statement

For example, if you need to delete all binary logs older than 7 days, you just need to run this sql:

mysql> PURGE BINARY LOGS BEFORE DATE_SUB( NOW( ), INTERVAL 7 DAY);

To purge all logs before a specific date:

mysql> PURGE MASTER LOGS BEFORE '2010-03-01 00:00:00';

To purge logs automatically (every Monday at 3am) you could use a cron job like this:

0 3 * * mon mysql -uroot -e 'PURGE BINARY LOGS BEFORE DATE_SUB( NOW( ), INTERVAL 7 DAY)'

2, Remove bin-log by the variable expire_log_days

An alternative option is to set “expire_log_days” as MySQL server parameter. The default values for expire_log_days is not to purge logs. You can either set it in MySQL’s configuration file or in a command terminal like below:

mysql> SET GLOBAL expire_logs_days = 7;
Query OK, 0 rows affected (0.00 sec)

mysql> show variables like 'expire_%';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| expire_logs_days |  7    |
+------------------+-------+
1 row in set (0.00 sec)

When this vavirable takes effect, the log files will be removed automatically on a weekly basis.
For any issues, don’t forget to raise a thread at our database support forum here.

Reset user password in MySQL
Let’s assume the normal user’s name is fatman, follow these steps to start:
1), Login to MySQL server, type following command at shell prompt to login as root

$ mysql -u root -p

2), Choose the right database mysql database, it’s mysql:

mysql> use mysql;

3), Change password for user fatman:

mysql> update user set password=PASSWORD("NEW-PASSWORD-HERE") where User='fatman';

4), Finally,dont forget to flush privileges:

mysql> flush privileges;

You can also use grant to reset a user’s password, the command is like this:

mysql> grant select,update,delete,insert on somedb.* to fatman@'somehost' identified by 'NEW-PASSWORD-HERE';

Reset DBA password in MySQL
When the DBA’s password lost, things become a little difficult, a restart might needed which is not so good for productive servers. There still have some possibilites to retrieval it without restart mysql service:

1), Is there any user has insert permission on the database “mysql”?
If so, he can insert into mysql.user and create another DBA account.

2), Is there any user has super user permissions?
For example, when the user was create like “GRANT ALL ON *.* TO user@’localhost’ WITH GRANT OPTION“, then this use is actually another DBA, you can ask him to reset root’s password.

If you got no luck till now, we have a common way here to fix the password. We can ask mysql server to bypass its grant tables when starting it. Thus it will not verify user passwords and permissions when they logon. That means all users will have full access to all databases as a database administrator.

$ /usr/sbin/mysqld --verbose --help | grep skip-grant-tables -A1
  --skip-grant-tables Start without grant tables. This gives all users FULL
                      ACCESS to all tables!
--
skip-grant-tables                 FALSE
skip-slave-start                  FALSE

Before making this changes, you need to make sure there’s no queries running on mysql. Then shutdown mysql instance first (mysql’s control script will help do that. In RPM based systems, it’s /etc/init.d/mysql) , and apply this option in the script, and start the service again.

When the DBA password got reset, do forget to remove the changes in mysql’s control script. If there any issue occures, please dont hesitate to create a topic in our support forum!

Basically what you need to do is to retrival a snapshot of your master database. It covers three types of information, a snapshot of your current mysql database, and master log file name and its running position when this snapshot created.

You can achieve these information on a running DB like this:

Firstly, frozen your database, in order to disable any writes/updates on the databases. It affects your service for sure. Run two sql queries on a terminal:

mysql> FLUSH TABLES WITH READ LOCK;
Query OK, 0 rows affected (0.53 sec)

mysql> SHOW MASTER STATUS;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| binlog-db.000004 |  88689   |              |                  |
+------------------+----------+--------------+------------------+
1 row in set (0.01 sec)

Keep this session open.  Note that when this session closes, READ LOCK will vanish, and your database will keep changing again.

Then open another terminal to create a copy of your current database files. There are three common ways to do that depending on your system environment. Either of these methods is okay.

1, Use mysqldump to copy all the data.

The disadvantage for mysqldump is that it uses very long time for dumpping large databases. It’s really unacceptable on productive servers.

shell$ mysqldump --database db1 db2 > fullbackup-timestamp.sql

2, Use a LVM snapshot

It only takes some seconds to create a LVM snapshot. When your snapshot created, you can copy the snapshot to the slave server.
As all the database files are exactly the same as master DB, you need to make sure the configuration files are similar as well.

3, Use XFS’ frozen feature to do that

SYSTEM xfs_freeze -f /var/lib/mysql;
SYSTEM YOUR_SCRIPT_TO_CREATE_SNAPSHOT.sh;
SYSTEM xfs_freeze -u /var/lib/mysql;

After the snapshot createed, you either leave the first session, or submit this query directly:

mysql> UNLOCK TABLES;

Finally you need to restore these databases from mysql dump file or the snapshot at slave side. When recovering a large database, time make lots of sense. it might take you one or more days to finish a recovery.
To speed up a mysql recovery, there’re always some valuable advises from wise man (The wise man here is … my friend). for example you can disable binlog when importing large sql files.

mysql> SET SQL_LOG_BIN=0;
Query OK, 0 rows affected (0.00 sec)

mysql> SOURCE /PATH/TO/MYSQL-BACKUP.SQL

When the files are importing, you need to make sure there are enough disk space avaiable, otherwise, it would crashed again. After importing all data files at slave side,  you need to tell the slave at which point it should read binlog from master:

mysql> SLAVE STOP;

mysql> SLAVE RESET;

mysql> CHANGE MASTER TO MASTER_HOST='pub.admon.org',MASTER_LOG_FILE='binlog-db.000004',MASTER_LOG_POS=88689;

myql> SLAVE START;

If all your recovery work is a remote operation, using Screen is highly suggested.

1 – Identifying The Problem

To find out whether replication is working or not, and check mysql logs
to make sure what caused it to stop. On Debian, MySQL logs to
/var/log/syslog:

admon:/home/admin# grep mysql /var/log/syslog
server1:/home/admin# grep mysql /var/log/syslog
Jun 29 09:16:08 http2 mysqld[14380]: 080629 9:16:08 [ERROR] Slave: Error
'Table 'mydb.taggregate_temp_1212347876' doesn't exist' on query. Default database: 'mydb'. Query: 'UPDATE thread AS thread,taggregate_temp_1212347876 AS aggregate
Jun 29 09:16:08 http2 mysqld[14380]: ^ISET thread.views = thread.views + aggregate.views
Jun 29 09:16:08 http2 mysqld[14380]: ^IWHERE thread.threadid = aggregate.threadid', Error_code: 1146
Jun 29 09:16:08 http2 mysqld[14380]: 080629 9:56:08 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'mysql-bin.001079' position 203015142

Now, you can see the query that caused the error, and the stop position. To determine the exact query:

mysql> SHOW SLAVE STATUSG
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
....
Last_Errno: 1146
Last_Error: Error 'Table 'mydb.taggregate_temp_1212347876' doesn't exist' on query. Default database: 'mydb'.
Query: 'UPDATE thread AS thread,taggregate_temp_1212347876 AS aggregate
SET thread.views = thread.views + aggregate.views
WHERE thread.threadid = aggregate.threadid'
Skip_Counter: 0
......
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: NULL
1 row in set (0.00 sec)
mysql>

New we are prepare to fix this issue.
2 – Repairing The Replication
we need to stop the slave first, by running:

mysql> STOP SLAVE;

To Fix the issue is quite easy. We tell the slave to simply skip the invalid SQL query here:

mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;

This tells the slave to skip one query (which is the invalid one that
caused the replication to stop). If you wanna skip two queries, you’d
use SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 2; instead and so on.

Now the issue has been fixed, we can start the slave again by running:

mysql> START SLAVE;

and then,check if replication is working smoothly again.

MySQLPerformanceBlog has issue “Several days ago MySQL AB made new storage engine Falcon available for wide auditory. We cannot miss this event and executed several benchmarks to see how Falcon performs in comparison to InnoDB and MyISAM.
The second goal of benchmark was a popular myth that MyISAM is faster than InnoDB in reads, as InnoDB is transactional, supports Foreign Key and has an operational overhead. As you will see it is not always true.”

For benchmarks I used our PHPTestSuite which allows to test wide range tables and queries.
The script and instruction are available here at mysqlperformanceblog.com, it’s posted by Vadim at January 8, 2007.

These thought base on my understanding, reading docs, speaking to Jim, Monty, Arjen and other people so I might miss something, something might be planned to be changed or not 100% correct but anyway you might find it
interesting.

In many cases what I find good or bad would base of my MySQL use with existing applications – if you design new
applications which are done specially for Falcon you might find those aspects positive.

[-] No Spinlocks Falcon does not use Spinlocks. It has its own lock implementation which does operation system wait if resource is unavailable. We’ll see where this leads us but I believe on multiple CPU systems you need some spinning done,at least for some types of locks where conflicts will be frequent. And now even laptops are getting multi cores so we can forget about spinlocks wasting CPU time on single CPU boxes without much of the gain. Spinlocks need to be wise though.

[+] Row Cache The fact Falcon has separate row cache is great as it means it can have much more data cached in the same cache size. You might need only single row from 8-16K page but page cache requires you to cache whole page, so needing
1000 of 100 bytes rows cached, which are all on different pages you need 100K of memory not 8-16M as you need with page cache. There are design techniques though to improve page cache efficiency in this respect, so in practice difference can be less.

[-] Not fixed cache size, but size range This is minor one. Unlike you would typically see Falcon uses minimum and maximum sizes for row cache instead of single size, this is complicated. If I have 8GB of RAM I can assume I want 4GB allocated to row cache and I do not really care about how these 4GB will be managed, to keep it the most efficient. Should I specify min size of 3GB or 3.8GB ? What is the difference ? Will purge run well too frequently if I keep them close. Manual does not say much on this matter at this point.

[-] Few configuration options This one is probably a bit contradicting to previous one but I put on my experimentator Hat here, not one of general user. I would like to see more configuration options to adjust database behavior to match my needs. I love this Zero administration thing and I would like database to manage things for me but it should first prove it can do it better than I do, and this can be only checked by comparing performance with your own optimized settings and one database engine would like to use itself. At this point I have not seen auto-configuration algorithms to be able to cover all kinds of workloads – they may deal well with something typical but not if you’re doing something unusual, which people do quite frequently with MySQL.

[+] Compact Indexes Compact Indexes are great. Huge indexes is where large portion of Innodb performance problems come however. We should however see how “compact” they would be in real world cases and how much performance it will give. As “SHOW TABLE STATUS” is not showing index sized in the release we tested it is hard to see how small indexes really are.

[-] No “using index” Falcon always have to check the row data even if you retrieve only columns which are in the index. I think this is big gotcha as having index covered queries is great optimization for wide range of queries.

[+] Ordered data reads Unlike other storage engines which will read row data as they traverse the index Falcon can optimize it by reading index first (possibly many indexes) and only then reading row data in sorted order. This can help a lot if you traverse significant portion of the table (or data which is locally stored but in random order). In my opinion this however should have been implemented outside of MySQL Storage Engine level for MySQL – reading rows in their physical order can be applied to most storage engines, it certainly can be applied for MyISAM and Innodb. I remember there were plans to implement such handler interface but I’m not sure there they are now.

[-] No Clustering Index support Unlike Innodb Falcon does not cluster data by Primary Key or any other key.This is good for some applications bad for others. There is large amount of applications out where which are optimized for Innodb which does have clustering, this is why I have it with Minus sign. In my opinion Optional clustering is best, in fact this is what you can get in Innodb (by using its internal hidden primary key) but this functionality is not exported well as it requires you to get rid of primary keys etc. Some presentations say Falcon does not need clustering because of optimized read by the index. This is not the case. If you access small primary key ranges with Innodb you will need to perform just couple of page reads, with Falcon if rows were inserted in different times a lot of scattered reads will be needed. Think about typical use of Innodb clustering – users mailbox, clustered by (user_id,message_id).

[+] Row compression Falcon uses some nice fast row compression methods, for example using only as many bytes for
integer as it requires, not storing column value if it is default etc. This is nice even though may show strange effects if you do not know about this feature, for example changing default value needs table rebuild even though for other storage engines it often could be done simply by changing meta data (it is not implemented in MySQL anyway
though). Very interesting to see how this one will compare to transparent gzip page compression which is being implemented for Innodb right now.

[-] Tablespace per database You may notice right now each database in Falcon gets its own tablespace and its own set of
logs. With typical for MySQL use of Databases just as directories it can be the problem – if transaction spawns multiple databases you need multiple log flushes on commit, plus ether you use XA to synchronize these which is expensive or it will be possible for your transaction changes to commit in one database and not in the other. The other issue you will see is having consistent snapshots being consistent for database only, so if you have started transaction accessed table in database A and a while after accessed table in database B, you will see records in B which were modified/inserted after you started transaction.

[-] Isolation Modes So far limited amount of isolation modes is supported, including no support for SELECT FOR UPDATE. This is also why Falcon has Optimistic locking concurrency which can give you problems if you have lock intensive workload so many update queries have to wait for row level locks. With Falcon at this point situation is rather funny, it will still wait for other transaction which updated the row to commit and then fail with ERROR 1020 (HY000): Record has changed since last read in table ‘t’ error message. If you find Falcon or Innodb behavior better still prepare for this to be area where things are different and your application may need to be changed. This is also area where detailed documentation is missing so far.

[-] No protection from partial page writes This means if single page write was not atomic, so only part of page was changed while other part remains old your database may end up in non-recoverable stage. This is why Innodb has “innodb double write buffer”. Jim does not believe this is the problem but I remember having problem not the once and twice before Innodb Double Write Buffer was implemented and seeing some pages recovered from it after it was implemented. Speaking with Oracle and PostgreSQL developers it looks like they all acknowledge this problem and have techniques to deal with it, so I’m a bit surprised why Jim does not believe in it.

[+/-] Only committed changes go to the disk Innodb modifies data in the database when you change it, Falcon only
when it is committed. This has some good sides such as no problem with very long rollbacks on recovery but also means you should have enough memory to hold all transaction changes. I agree most transactions are small and should be fine but if you have long running transactions, for example batch jobs you may end up in trouble or be forced to rewrite
them to commit often.

[+] Blob handling optimizations Jim loves BLOBs as his own child, so Falcon is optimized in Blob handling for example having direct blob writes to the database and probably some others. This would be very interesting to see how these optimizations will show themselves in practice.

The other interesting point which I have not found much information about is regarding handling fragmentation – what happens on row updates, are they stored in the same position or in another location ? Does row ever split into multiple parts like with MyISAM or always stored as single piece ?
These are going to be pretty important for IO bound workloads.