Triggers for a table are currently stored in
.TRG files, with one such file one per
table.

A.5.8:
Can a trigger call a stored procedure?

Yes.

A.5.9:
Can triggers access tables?

A trigger can access both old and new data in its own table. A
trigger can also affect other tables, but it is not permitted to
modify a table that is already being used (for reading or
writing) by the statement that invoked the function or trigger.

A.5.10:
Can a table have multiple triggers with the same trigger event
and action time?

As of MySQL 5.7.2, it is possible to define multiple triggers
for a given table that have the same trigger event and action
time. For example, you can have two BEFORE
UPDATE triggers for a table. By default, triggers that
have the same trigger event and action time activate in the
order they were created. To affect trigger order, specify a
clause after FOR EACH ROW that indicates
FOLLOWS or PRECEDES and
the name of an existing trigger that also has the same trigger
event and action time. With FOLLOWS, the new
trigger activates after the existing trigger. With
PRECEDES, the new trigger activates before
the existing trigger.

A.5.11:
Can triggers call an external application through a UDF?

Yes. For example, a trigger could invoke the
sys_exec() UDF.

A.5.12:
Is it possible for a trigger to update tables on a remote
server?

Yes. However, the way in which they work depends whether you are
using MySQL's “classic” statement-based
replication available in all versions of MySQL, or the row-based
replication format introduced in MySQL 5.1.

When using statement-based replication, triggers on the slave
are executed by statements that are executed on the master (and
replicated to the slave).

When using row-based replication, triggers are not executed on
the slave due to statements that were run on the master and then
replicated to the slave. Instead, when using row-based
replication, the changes caused by executing the trigger on the
master are applied on the slave.

A.5.14:
How are actions carried out through triggers on a master
replicated to a slave?

Again, this depends on whether you are using statement-based or
row-based replication.

Statement-based replication.
First, the triggers that exist on a master 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. For example, consider a table
EMP that has an AFTER
insert trigger, which exists on a master MySQL server. The
same EMP table and AFTER
insert trigger exist on the slave server as well. The
replication flow would be:

The replication slave picks up the
INSERT statement to
EMP and executes it.

The AFTER trigger on
EMP that exists on the slave activates.

Row-based replication.
When you use row-based replication, the changes caused by
executing the trigger on the master are applied on the slave.
However, the triggers themselves are not actually executed on
the slave under row-based replication. This is because, if
both the master and the slave applied the changes from the
master and—in addition—the trigger causing these
changes were applied on the slave, the changes would in effect
be applied twice on the slave, leading to different data on
the master and the slave.

In most cases, the outcome is the same for both row-based and
statement-based replication. However, if you use different
triggers on the master and slave, you cannot use row-based
replication. (This is because the row-based format replicates
the changes made by triggers executing on the master to the
slaves, rather than the statements that caused the triggers to
execute, and the corresponding triggers on the slave are not
executed.) Instead, any statements causing such triggers to be
executed must be replicated using statement-based replication.