http://www.perlmonks.org?node_id=11100437


in reply to Re^3: Tracking and deploying changes in (MySql/Maria) DB schema ...
in thread Tracking and deploying changes in (MySql/Maria) DB schema ...

Maybe I should have been more explicit about needing the incremental steps (i.e. ALTER TABLEs)

So you need auditing. The audit plugin [1] seems to be made for this. As expected it has a QUERY_DDL setting which is pretty much what you seem to need.

[1] https://mariadb.com/kb/en/library/mariadb-audit-plugin-log-settings/

Replies are listed 'Best First'.
Re^5: Tracking and deploying changes in (MySql/Maria) DB schema ...
by LanX (Saint) on May 23, 2019 at 21:34 UTC
    This looks good, will try it out, thanks! :)

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

      And what are you going to tell the client in order to get him to install, configure and maintain this thing that he probaply doesn't want? I mean, it's a database plugin right, so it must run on the server.


      holli

      You can lead your users to water, but alas, you cannot drown them.

        If the client is making ad-hoc ALTER TABLE statements on important databases/tables then they probably do want auditing even if they don't know it yet. It is the job of the consultant (which is what I am assuming LanX is in this case) to persuade the client that this is indeed what they want. Plenty of arguments: DR, intrusion detection, the initial use case of this thread, etc.

        The plugin would run on a dev server.

        You don't need a plugin to run alter table on production servers.

        And it would only be manually triggered ....

        ...like if a difference to a "master" table is reported.

        Ideally...

        Cheers Rolf
        (addicted to the Perl Programming Language :)
        Wikisyntax for the Monastery FootballPerl is like chess, only without the dice