Remind customers of an event 7 days before the event based on a date
A database is a place to store data.  An application is where that data is manipulated.

MySQL cannot "send email" or otherwise reach outside of itself.

So...  I would have a daily 'cron' job in the OS open the "events" table, read all the rows, compute who needs a reminder, send out the emails, and remove any expired rows from the table.

If you have only thousands of entries in the table, this is quite manageable; if you have millions, then there needs to be some way for the SELECT to filter out most of the table, thereby lightening the load on the app.

To accommodate February, you might want to say 'last' instead of '30th'.  That can be computed as "go forward 1 month, then back up 1 day".  Or, in MySQL, date + INTERVAL 1 MONTH - INTERVAL 1 DAY.

Your definition of Event Reminders table is confusing -- is it a list of future reminders to issue?  Or a list of past reminders sent out.  Pick one.  You seem to need to remember that you have already sent out a reminder; so I prefer that.  Pre-computing the 'future' is not worth the effort (as I already pointed out).