Tag: Point-in-Time-Recovery

While working on our project titled “PostgreSQL for Dolphins and Sea Lions,” I pored over the PostgreSQL documentation on replication. What struck me was that PostgreSQL does NOT support artificially delayed replication—at least according to this documentation.

After I’d already been thinking about how one might possibly cobble together artificially delayed replication using PostgreSQL’s built-in tools, I decided to give my go-to search engine another try—and lo and behold, on the second attempt, it finally …

We recently tested the PostgreSQL backup tool pg_basebackup and were very impressed with its remote backup functionality, which allows for both physical local and physical remote backups.

This led us to wonder whether a physical remote backup is also possible using the “new” MySQL Server Clone feature, which was introduced in MySQL 8.0.17 (July 2019).

The MySQL Clone operation can be used to create both a local and a remote copy of the database. The original idea behind this feature was likely to …

While working on the topic “PostgreSQL for Dolphins and Sea Lions,” I discovered that in the PostgreSQL universe, the topic of point-in-time recovery tends to be sidestepped when it comes to specific statements or transactions. And when examples are provided, they primarily focus on DDL statements rather than DML statements.

If you want to recover to some previous point in time (say, right before the junior DBA dropped your main transaction table), just specify the required stopping point. You can specify …

It is Saturday night at 23:19. Time to go to bed after a hard migration day. Just a last clean-up query before finishing: Tap tap tap. Enter! - Oops!

SQL> UPDATE prospect_lists_prospects
    SET prospect_list_id = '73ae6cca-7b34-c4a3-5500-5d0e2674dbb6';
Query OK, 4686 rows affected (0.21 sec)
Rows matched: 5666  Changed: 4686  Warnings: 0

A verification query to make sure I am in the mess:

SQL> SELECT prospect_list_id, COUNT(*)
  FROM prospect_lists_prospects
 GROUP BY prospect_list_id; …

Sometimes we face the situation where we have a full MySQL database backup done with mysqldump and then we have to restore and recover just one single table out of our huge mysqldump file.
Further our mysqldump backup was taken hours ago so we want to recover all the changes on that table since our backup was taken up to the end.

In this blog article we cover all the steps needed to achieve this goal for MySQL and MariaDB.

Recommendation: It is recommended to do theses steps on a testing system and then …