This could be a serious problem when replicating between MySQL 8.0 and MariaDB 10.x.
The default (for good technical reasons) COLLATION for the 8.0 is utf8mb4_0900_ai_ci. Note the "255" associated with it. MariaDB has not yet adopted the Unicode 9.0 collations.
Furthermore, Oracle (MySQL 8.0) did a major rewrite of the collation code, thereby possibly ...
First step is to VACUUM ANALYZE the table to make sure the table isn't full of dead tuples and the statistics are up to day.
For a btree index to be maximally efficient, all but one of the conditions on it need to be equality. You have one equality, one inequality, and one max, which is pretty much the same as an inequality. Also, all the equality ...
here are two ideas that can be tried..
Run a script or other little app in the background that scans through the killing connections that do not match the established rules
it fires off every few seconds ..
Or create a system event trigger that fires off checks the user IP address and any other information that needs to be checked when the connection is ...
Here is a query what will generate all the necessary update statements.
It temporarily disables foreign key checks so that the update statements succeed.
It updates the default character set for each database that needs it.
It updates the default character set of each table:
If it doesn't have the right default character set.
If it contains text columns ...
force manually an autovacumm policy on mergency situations
This is not going to work. hot_standby_feedback doesn't prevent autovacuum from running. It lets it run but prevents it from removing rows that are not "dead enough". No amount of vacuuming is going to help if you don't get the long running queries on the replicas to go away first.
You can use ...
Yes, that is the idea. In the case of a replication conflict PostgreSQL has only two options:
cancel the query
delay the application of replicated changes.
Setting max_standby_streaming_delay to -1 will delay replication indefinitely long.
There are ways to reduce replication conflicts:
Set hot_standby_feedback = on to remove replication conflicts caused ...
Single-threading is very likely to be the cause of getting "behind".
A Master can execute multiple transactions at the same time. But a single-threaded Slave is limited to one transaction at a time. This is the old, simple, way of doing Replication.
Newer replication techniques are more complex. Depending on what version of MySQL you are running, multi-...