You could store the original lesson record in one table, and consider it immutable. Then you could store all changes in a lesson-modifications table. When you want to view the current state of any lesson, you will need code to look at the original lesson and then look at all the modifications and apply them to figure out when the current lesson is, and if it's cancelled or not.
The schema could look like this:
lesson_mods table stores only the modifications made to a base lesson. Problems with this are that
new_value: it will be difficult to enforce that these only refer to valid fields that can be changed, and values that are valid for those fields (there are ways to do this, but I don't want to get into that here).
Or you could do something like this:
is_cancelled (in case you want to un-cancel a lesson)
cancel_created_time (to know when this record was created - in case there are multiple cancellations/un-cancellations you will need to know the most recent)
rescehedule_created_time (to know when this record was created - in case there are multiple reschedules you will need to know the most recent)
This is still pretty complicated and I'm not sure what benefit you would get by storing the cancellations and schedule changes this way.
A simpler way to do it (though it would require more storage) is simply record each image of a lesson after a change is made, and all images in the same table. You'll need additional metadata to keep track of which version of a lesson record is the most current.
original_lesson_id (FK to lessons.id - id of lesson that this modification was based on - NULL for new lessons that are not modifications of existing lessons)
created_time (used for versioning)
I personally would go with the second option as it is much simpler and if you want you can still do image-by-image comparisons. I'd only consider the first if the number of modifications is large enough to create concerns for storage.