We are developing a cloud solution with two tiers where all the user data will save in the same mysql schema in the server. But, for users from diferents companies, we prefer that symmetric engine will be different. So, in the server will have only one application schema, but some symmetric squema (one for engine).
The question is if a application table will have one database trigger from engine or only one trigger can propagate the data over all engines. In the first case, will be the performance acceptable?
I answer to myself. This solutions doesn't work! It not possible public two symmetric triggers from two symmetric engines in the same application data schema. The last engine triggers replace previous ones, and only works the last engine, at least with MySQL.
Hmmm. You'd have to override the code that builds the triggers. If each engine had its own catalog and user, and the trigger had some conditional in there which wrote into the relevant sym_data table, it might work. (The routing and batching features run off of the inserts into sym_data and not off of your application table triggers directly.)
I'm not sure about the impact on the trigger history table though. That would require more study.
You can set up different node groups and you can do conditional routing out of the box, so I'm not sure why you'd want to have separate engines for different routing rules. After all the data is already commingled in your database. (Unless you are giving the end users direct access to the REST API, or embedded API and don't want them able to extract the other user's data through SymmetricDS...)
We are design a cloud complex solution, that works for diferents companys with differents group of users.
One symmetric engine for each company is a "good and elegant" aproach for maintenance and security.