W. Curtis Preston: Hi, and welcome to Backup Central's Restore All podcast.
I'm a host w Curtis Preston, a k a, Mr.
Backup, and I have with me my Monday morning melancholy
minimizer Prasanna Malaiyandi?
Prasanna Malaiyandi: Wow.
How's it going?
So we won't get into your melancholy, but here, here's some good news for you.
You know what this, you know what today is.
There's two important things that happened today.
W. Curtis Preston: It's, no, I got nothing.
Prasanna Malaiyandi: So the first one is I now
W. Curtis Preston: Oh, do you?
Prasanna Malaiyandi: year.
W. Curtis Preston: You know the day you're three actually.
Prasanna Malaiyandi: It was actually a couple of weeks ago.
It was, it's actually two weeks ago.
Right.
But I do now have a three-year-old beard and three-year-old hair.
I don't know what you call three-year-old
W. Curtis Preston: what I call three.
Prasanna Malaiyandi: Yeah.
W. Curtis Preston: In need of a haircut.
That's what I, that's what I call that.
Prasanna Malaiyandi: No, it's fine.
And.
The second one is, this is our 200th
W. Curtis Preston: Are we really recording our 200th episode?
Wow.
That's almost four years of podcasts.
That's a lot of talking.
Prasanna Malaiyandi: And thank you to the listeners for listening
to us for these last like four
W. Curtis Preston: I'm, um, I'm on another podcast that
doesn't have as many listeners.
Um, and I mean, it has very, very few listeners and it's not, you
know, it's just not the same.
Like if you, if you're producing a podcast and no one's listening to it, it's gonna.
You're like, why am I doing this?
But yeah, we've got, we've got, um, you know, um, thousands of you out there that
are listening to it and we appreciate it.
And without that, uh, this would seem like a lot of effort for nothing.
So, um, definitely, um,
Prasanna Malaiyandi: Yeah.
W. Curtis Preston: Well, that's good.
You know what?
See,
Prasanna Malaiyandi: make your Monday a little
W. Curtis Preston: brought, that, brought that, that helped me out.
I'm having, I'm, I'm not having the greatest Monday here and see this.
What, this, why, you know, you're my Monday morning melancholy
minimizer, but, But the, but the beard, the beard and the hair thing.
I know, man.
I mean, it, it's funny for those of you watching on the, on the, you know, you
can see the video of this if you go to backup central.com or you can listen to
it on, you know, on any of the places.
And, uh, but those of you looking, you, you see me, I just got a new
haircut talking about this nice trim saying, I've got this nice
trim, trim kept to my face, beard.
And then we have Prasanna.
Uh, that is the complete opposite.
Prasanna Malaiyandi: Yeah, I, I, I once had a friend, hi Jane, who
referred to me as the caveman.
And this is what I had a normal beer too.
Not like this.
W. Curtis Preston: opposites in so many different ways.
Um, you know, like when it comes to movies and, you know, when it comes to
the things we enjoy eating, what, there's some stuff we like eating that's similar.
Um, but, and I, and
Prasanna Malaiyandi: And this is why we get along so well,
W. Curtis Preston: whole opposite attract thing.
Um, well, uh, we're gonna continue our, uh, backup to basic series,
uh, today, talking about databases.
Before I do that, I'll throw out our usual disclaimer.
I and Prasanna work at different companies.
He works for Zoom, I work for Druva.
This is not a podcast of either company.
Uh, the opinions that you hear ours.
If you'd like to join the conversation, just, uh, reach out to me, w Curtis
Preston gmail, or at WC preston on Twitter and also linkedin.com/iin/mr.
Backup.
You'll find me there as well.
And, uh, you know, um, join the conversation, right?
We'd love to have you on.
And also please rate us, uh, go to your favorite podcast or scroll down
to the, to the comments and um, you know, give us some stars and some
comments we love that keeps us going.
Uh, except for that one guy or the, gave us one star.
I don't know what his deal was, but, um, it's one person.
It's one person that gave us one star.
And he doesn't say why.
I'm like, Hmm, that was harsh.
Um, Who that is.
Yeah,
Prasanna Malaiyandi: tell us so we can
W. Curtis Preston: I think, you know, if you want to say, listen, I would
really like to listen to that podcast, but Prasanna needs to cut his hair.
All
Prasanna Malaiyandi: Not gonna happen.
I'm sorry
W. Curtis Preston: know, it is what it is.
Well, we are continuing our, um, our backup to basic series, which
is based on this, uh, latest book that I wrote, which of course I
had lots of help from Prasanna on.
Um, and it's, uh, modern Data Protection from O'Reilly and Associates, and, you
know, you can find it at, uh, wherever.
Wherever books are sold, um, you can get both, uh, an ebook
version and a printed version.
And, um, So let's talk about, uh, th this is about protecting databases.
So I, I know I've told this story on the podcast, but it was a broken database
that basically started my career, right?
Um, that, yeah.
Um, it was the, the name of the database was Paris.
It was my, uh, my bank's purchasing database.
And, uh, we were backing it.
Via what I would now refer to as the hot backup method where you put the
da, you put the data files into backup mode, and then you back them up.
Except that we had moved, um, we had moved the server over to another, we
had moved the database over to another server, and nobody had told me that,
that I needed to put the script in place so that I could do the backups.
And we had been backing it up for months without, you know,
without getting a decent backup.
it was inconsistent.
And, um, I remember sitting there and the, the boss was like, so
let me, let me get this straight.
We have absolutely no backups of Paris whatsoever.
And I'm like, that is what I'm saying.
Uh, and she didn't fire me tr you know, chalked it up to bad training.
Uh, Ron Rodriguez, all your fault to this day, I'm gonna
throw you under the bus for that.
Prasanna Malaiyandi: You're like, you're like a name That sticks in my head.
W. Curtis Preston: good guy.
But yeah, just he left that out of the training.
So, uh, so I think it's important for you to understand databases
because they are, you know, I think for, for many environments they're
more than 50% of the data center.
Isn't that, isn't that normal?
Like for structured data essentially to be,
Prasanna Malaiyandi: I think that's changing these days.
Oh, sorry.
For structured data for most of it to be stored in databases.
I think that would be a
W. Curtis Preston: So you're not necessarily agreeing that
most of the data in the, in the data center is structured data.
You're thinking that nowadays unstructured data is more because we're just, yeah.
Okay.
Yeah, yeah.
We
Prasanna Malaiyandi: data.
Yeah.
And, and if, and when you, but if you do caveat it with saying in the
data center, I think that statement
W. Curtis Preston: You know what's funny?
The phrases like that come out of this old mouth, and I don't
even mean it when I say it.
Prasanna Malaiyandi: Yeah.
W. Curtis Preston: I don't, I mean, in the computing environment.
Um, so you, you're thinking that there's a lot of stuff up there.
Prasanna Malaiyandi: Just because of the amount, large amount.
Oh yeah.
Just the large amount of data that's out there in the world.
Right.
And unstructured
W. Curtis Preston: There was a time when structured data, data
and databases specifically was the king of the data center.
Right.
Um, and then, um, then we just started storing on just all kinds of nonsense.
Um, we just, we as a, as a human race, we have seemed to have a
never ending desire to store stuff.
Prasanna Malaiyandi: Pack rats.
Pack rats.
That's what we
W. Curtis Preston: Um, so I, so the, you know, if, if you don't know anything
about databases, the, you know, you should learn a lot in this episode.
If you know a a lot about databases, you may know more than I do.
I am not a dba, uh, I have never been a dba.
Uh, I have often been at war with DBAs, um, but.
Prasanna Malaiyandi: That is a database admin who, yeah, from a
backup admin perspective, probably
W. Curtis Preston: uh, I, I've run into a few fights, you know, I've had
a few fights, but, um, so I think it's important to sort of divvy up the,
you know, the computing world into these different buckets so that we
understand what we're talking about.
And the first thing that I talked about was database delivery model.
And the first is, uh, is traditional database software.
What would you think I would mean by that Prasanna?
And maybe give an example.
Prasanna Malaiyandi: Yeah, so the biggest is you basically take the software, you
download it from the vendor, you deploy it on your servers, you're managing
it, you're doing everything else.
This traditionally has always been like Microsoft sql.
You have your Oracle databases.
I think those are probably the two biggest,
W. Curtis Preston: Still, still Cybase.
Informix is out there and, well, and of course, yeah.
Yeah.
I don't know.
MySQL might actually be the biggest database out there.
Um, in terms of just certainly number of deployments, but many, many, you know, but
I wonder if we added up all the gigabytes of all the little tiny MySQL databases.
Um, I mean, the Backup Central has a bunch of MySQL databases behind it.
Uh, but yeah, that's basically, you know, that's normally what I think
many people think of when they think.
Databases, right?
But then if we take that database and someone else runs the database
application itself, right?
And then all I have to deal with, so basically they're gonna manage the
storage, the patching of, you know, Oracle, MySQL, uh, the security, perhaps
the security administration of it.
And then all I have to do is add database, add table, um, then that.
Prasanna Malaiyandi: Mm-hmm.
W. Curtis Preston: Exactly, and then start using the database.
That would be what we call a PaaS database or platform as a service.
You get the database platform, and the best example I have
of that is aws, r d s, right?
Relational database service.
From a backup perspective, the main difference between these two is that
you don't, you, you can't necessarily install, like if you want to back up,
um, Let's say, uh, SQL Server, you can install a SQL Server backup, uh,
uh, a agent right it on it, right.
You, you don't
observe it,
Prasanna Malaiyandi: And just quickly on that, I don't know if we'll talk about
this later, but, and, but I think that's where a lot of these vendors who are
providing PAs databases sort of try to bake in backup and some of these recovery
operations into the platform itself
W. Curtis Preston: yeah, they, they do, they do tend to build in backup features.
You often need to actually execute those features.
You need to actually, uh, Drive the backup, but they give you the tools, they
give you the car, you gotta drive it.
Um, there is one interesting one, and I'll pick up on Amazon.
I'll pick on Amazon here for a minute.
Amazon, r d s does support, um, uh, RMAN for Oracle.
Let me, let me rephrase.
They support Armand backups for Oracle.
You know what?
They don't support.
Prasanna Malaiyandi: S B T
W. Curtis Preston: No, they don't support rman restores for Oracle.
Prasanna Malaiyandi: oh oh.
That's.
W. Curtis Preston: You
can make, you can make Rman backups with Oracle, with Amazon rds.
But the last time I checked you cannot do am you cannot do, uh,
rman restores, which is just odd.
Uh, it is
Prasanna Malaiyandi: but I think that's where they hope that you're
using like their built-in snapshot and capabilities and everything else like
that to if you need to actually restore.
Otherwise it's like, hey, you have an Armand backup and you
could take it offsite or to your
own instance, if you will, to do your restores.
W. Curtis Preston: I guess it's more, yeah.
Yeah.
Um, just a weird one.
So then the next one we have here is serverless databases.
You want to tackle, tackle that one?
Prasanna Malaiyandi: Yeah, so we just talked about, okay, you have.
Sort of someone else managing the server, but you're still
managing all the databases.
You also typically are involved in sort of performance tuning
at that point as well, right?
With serverless, you're sort of getting away from all of that.
It's like, Hey, here's a database endpoint.
You don't even do sort of the normal, basic operations other than sort of
accessing the data, and it automatically sort of scales up, scales down on its own.
You don't have to worry about it.
Now, it's funny that everyone talks about serverless, even like serverless.
In the end,
there's still a server somewhere, right?
W. Curtis Preston: Right.
But you are not
managing it right.
Yeah.
Um, and the, the biggest example here I would have would be DynamoDB.
I mean, there are a bunch of serverless databases, both on Amazon and
other, other, uh, cloud providers.
But the idea with, with Amazon db, I think, I think it, it,
it's a perfect example of how, how you can make it very simple.
With Dynamo DB , you just give it a key in value.
Right.
You have an account, you have a authentication, you give it a key and
value pair and it will store it somewhere.
You're not creating that table, you're not creating a database,
you're not creating any of that stuff.
You're just say, Hey, here's a key and a value.
Uh, store it for me and I'll ask for it later.
So that's what I'm calling the database delivery models.
And then we've got the database models, which are, which are like
the different, that's how you would, that's how you might get a database.
This is what kind of database you might get.
Um, and the biggest category, what would the biggest category be?
What do you think?
And by the
Prasanna Malaiyandi: Well, it depends.
It
W. Curtis Preston: not even.
Prasanna Malaiyandi: Well, I think it depends on what
you mean by biggest, right?
Is it the number of deployments?
Is it the sizes?
Right.
W. Curtis Preston: I don't know.
I'm just talking about the, the db engines.com, the most
popular
Prasanna Malaiyandi: relational databases.
W. Curtis Preston: databases.
Yeah.
It looks to be over 75% of, of the other ones.
There are other types.
One of them is the one I just mentioned, the key value pair database.
Right.
There's time series, there's graph databases, document databases, a
database just for search engines, right?
Th these are the different types of databases and they tend
to behave differently from a backup and recovery perspective.
And I do think it's important for you to understand, um, you know, the
type of database that you're backing up when you're backing it up, right?
That's
Prasanna Malaiyandi: Because they each have their own nuances and differences.
It's not like a database is a database because from backup
and restores, they're completely
different.
W. Curtis Preston: Exactly.
And then this is where I think we really get into, you really need to understand
this when you're doing a backup and recovery, and that is the different
consistency models of a database.
Prasanna Malaiyandi: What do you mean by consistency models?
W. Curtis Preston: So immediate.
Right versus eventual versus hybrid.
These are the, the, the different consistency models, right?
Immediate is the one that most of us think of when we, um, When we take a
databases, at least, I'm, I'm gonna say it's probably the most popular,
again, relational database management systems, RDBMSs, those are, I'm
pretty sure those are all immediate.
Wouldn't they be all immediate?
Prasanna Malaiyandi: I think so.
yeah,
W. Curtis Preston: yeah.
But then eventual is the one that I struggle with.
It's like, why would you want that?
But,
Prasanna Malaiyandi: yeah.
Well, I
W. Curtis Preston: sense once you realize how they're
typically deployed.
Prasanna Malaiyandi: Yeah.
Well, and here's a good example, right?
So you have a bank, you go make a deposit with immediate, it's like, Hey,
the transaction shows up immediately.
You can use it, right?
With like eventual, it's like, Hey, you made a deposit.
Sometime in the next 24 hours or so, your bank balance will, or
your bank account will balance out.
But until then, you may be able to withdraw funds.
Sometimes you may not be able to if it hasn't cleared, right?
So,
W. Curtis Preston: Yeah.
Prasanna Malaiyandi: That's kind of how I like to think about it.
W. Curtis Preston: The example that I used in, um, the book was I used
DNS as an example of the concept of eventual consistency, where, um,
you're gonna get a different answer depending on who you ask and when,
Prasanna Malaiyandi: Yep.
W. Curtis Preston: right?
You, you create a, a DNS entry and it takes a while for that entry
Prasanna Malaiyandi: to.
Propagate
W. Curtis Preston: Propagate throughout the system.
Uh, and the same is true of, of, of an eventually consistent database.
And the thing is, you can't use the eventually consistent model.
If getting a wrong answer will will break the, I was gonna say, yeah, we'll break
everything.
um, but.
You know, it, it is weird though, right?
It, it's weird.
It's, I struggle with this idea of eventual consistency, um, and,
um, how it would be okay for you to get essentially a wrong answer.
Prasanna Malaiyandi: but I think it depends on the
application, right?
Where
W. Curtis Preston: it absolutely
Prasanna Malaiyandi: if it's, yeah, like if it's okay for you,
cuz there is a trade-off, right?
With, uh, immediate consistency.
Typically there is some sort of latency associated with committing
a transaction, especially if you're talking about multiple nodes, right?
Which is typically where
you see the eventual.
W. Curtis Preston: Yeah.
You look at dns, for example.
DNS would break if
Prasanna Malaiyandi: Could you
W. Curtis Preston: to be, if it had to be
immediately consistent across the entire world, right?
That's the thing.
Immediate consistency is very tight, right?
You've got to have it right.
And then I also listen hybrid, which is, um, somewhere between the two.
So here's an example I have.
So for example, DynamoDB users can tell DynamoDB they want a
strongly consistent read, and it will always read from the leader.
Um, where the right was initial, which is the leader is where the
right was initially made, even if it is still being replicated elsewhere.
So that's hybrid.
It's an, it's eventually consistent database, but you could say when
you create a key value pair in Dynamo DB upon read, always read
from the first person, right?
Um, yeah.
There, there's a bunch of a MongoDB Couchbase, uh, that support that.
Um, I had listed here of immediate are all the ones that we, the, the
ones that everybody knows their name, Oracle Sequel, you know,
uh, I have, uh, eventual consistency.
Uh, I have Cassandra and Neo four J.
And then I have, as hybrid, I have Mongo and DynamoDB.
Those are just an example.
Um, by the way, all that stuff comes from a great website,
um, called uh, db-engines.com.
Um, they list all that stuff in there.
So, um, The next one, I have a bunch of terminologies here, and I'm not
gonna go through a lot of them, but, um, I think one that people
struggle with is the difference between an instance and a database.
Um,
Prasanna Malaiyandi: What, what is the difference
between an instance and a database?
W. Curtis Preston: well, an instance is essentially the way I, the way I
would describe it is, In many cases it's the same, but an instance is a set
of processes to talk to the database.
And the database is, well, what we normally mean when we say database, right?
Um, so, uh, so let me, lemme just read here, because I, I, I got this like,
check, you know, 50 times, you know, uh, there can be multiple databases within
an instance, and a database can also be distributed across multiple instances.
Right.
Um, on the same machine or on separate machines within a cluster.
Therefore, an instance in a database are two entirely different concepts.
Historically, an instance ran within a server, but modern database
platforms have instances that span multiple servers and node, right?
Um, so the instance is basically the thing that runs inside a server or a bm.
Talks to this thing, but a database could be across multiple
instances or multiple databases.
That instance, um, it is
complicated.
See, this is why, this is why
Prasanna Malaiyandi: but, but, here's here, here's a
W. Curtis Preston: go ahead.
Prasanna Malaiyandi: though.
As a backup person,
what do I need to worry about in that case?
Do I worry about more of the instance or the
database?
W. Curtis Preston: Well, you just need to know.
You need to know that there, yeah.
It depends.
You need to know that there are different things because.
It, it's going to dictate how you communicate with the thing that
you're trying to back up, right?
Um, in many cases, I'm, I'm gonna throw you prob again.
I'm gonna say in most cases they're the same, right?
They're not the same, but they're in the same place.
There's one instance and there's one database.
Most of the databases that I worked with, it was one
instance of one database, right?
Um, The, um, but you just need to know that that's not always the case, right?
We all know what a table is, right?
Um, you know, I, I liken it, I liken it to a spreadsheet, uh, but it's not the same.
The, um, and then there's this concept of a data file, which is where we stored the.
Right where the database stores the data.
Um, and this concept of a table space, which is what it sounds like, it's
a space where you put tables, so you could put many tables in this database.
Um,
Prasanna Malaiyandi: And each database does it
slightly differently.
W. Curtis Preston: yeah, I'm, I'm trying to be very, very general here,
Prasanna Malaiyandi: Yeah.
And I think the other question, and I know we talked about this at the
very beginning, talking about the problem you ran into with Paris, right?
It's just because you have a database doesn't mean you could just take all the
database
files and copy them out
W. Curtis Preston: No, you can't because the data, those data files
are what you're trying to back up quite often.
And if you're backing it up outside the world of the database, the database
is changing those data files while you're, while you're backing it up.
And it's, it's not gonna be consistent, you know, part, part of the, part
of this file that you backed up.
Part of it's gonna be for one point in time, part of the file is gonna
be from another point in time.
No, no.
Good.
And then, Again, going for a very generic term.
Here I have this concept of a master file, and that is sort
of the database of the database.
Um, a perfect example is the Oracle control file, right?
The, um, uh, again, this is most databases.
Not every database has this, um, it, it might be a J S O N file, right?
Um, go, what were you gonna.
Prasanna Malaiyandi: does it ever feel like inception when you're working on
databases where it's like a database
within a database, you know?
W. Curtis Preston: Yeah.
Uh, by the way, SQL Servers master Database has this concept.
Essentially it's the thing that's keeping track of all the
things that we're talking about.
What are all the data files?
What point are they at?
What if we have a eventually consistent, you know, what,
what change level are we at?
Um, it's the thing that keeps track of all the things.
And, um, there
Prasanna Malaiyandi: impressive that they actually used that piece of technology as
a core foundation of like keeping track.
It's like
that's kind of
neat.
W. Curtis Preston: Yeah.
Uh, and so there's going to be a different backup method for that.
If that file exists, there's gonna be a different backup
method for that file, right?
So you're gonna back up that database.
You're gonna, um,
In Oracle, for example, there, there's a command backup control file, right?
It's just a separate, uh, backup.
Prasanna Malaiyandi: They're
W. Curtis Preston: now
exactly special.
Uh, and then we have a very important concept, and that is
the concept of a transaction.
You wanna talk about what a transaction is.
Prasanna Malaiyandi: Yeah, so usually when you say make a right to a database, right,
you just issue the SQL command or whatever to do a simple thing, but that translates
into a whole bunch of other things.
Now, when you actually get that before it can apply to the actual
database, and I don't know if you wanna talk about logs right now, but
that transaction, typically when you think about a transaction, especially
on a relational database side, it's something that has to either complete or.
It's either the transaction completes and the entire database rolls forward
and everything's good, or the transaction doesn't succeed and no part of the
transaction is successful, so basically the entire thing happens or it doesn't,
which means it's atomic, right?
So it all happens and everything's successful, or no part of it happens.
So you don't want the case where it's like, Hey, I am withdrawing
money from your bank, but I don't set the balance properly, or
other things like that, right?
So it either all needs to succeed or none of it
succeeds.
Otherwise, the world goes crazy.
W. Curtis Preston: Right.
And that matters most when you, because there's two
different types of transaction.
They're simple and it's complex.
Complex has a bunch of different parts of it.
And, uh, that's a, a perfect example where you were saying that you, all of those
parts have to work or, or none of them are allowed to work and you will then.
So if, if we can't finish the entire transaction, let's say.
Um, the database crashes.
It's in, it's in the middle of that.
What, what do we call when we make that transaction?
Yes, we roll
back the
Prasanna Malaiyandi: You roll
back.
Yeah.
Which basically, so now you have to think about it though, right now that
you have this concept of, okay, there's a transaction, it's atomic, it either
all succeeds or it gets rolled back.
Now if you think from the database perspective, you need to be able to
track all of these, because how do I know how to go back to a previous state?
It's like I need to.
The previous state.
Right.
So there's so many other things a database does as a matter of just accepting a
single transaction.
W. Curtis Preston: Yeah, exactly.
And, and that's why we have the transaction log, right?
So first, not every database has the concept of a transaction.
I still think.
Did every database has transactions, they just might not call it that.
Um, cuz every database is making changes, is storing data and making changes.
I think that generically every one of those should be called a transaction.
And, and by the way, this was one of my biggest challenges when I, when I
wrote my first, um, version of this, like, which is a really long time ago,
was trying to get, um, DBAs, again, of different database products to agree
on a generic term that would work and,
Prasanna Malaiyandi: for everything.
yeah,
W. Curtis Preston: exactly.
And transaction.
Um, I is one of those things, right?
Um, but the transaction log re uh, Oracle for example, calls it a
redo log, some call it a, you know, um, so I ha I have the, um, It.
So what I do
Prasanna Malaiyandi: The T log in
W. Curtis Preston: log might not
be there, by The way, I'm, I'm showing that not in all NoQ databases.
And by the way, um, we didn't talk about no SQL when we were
talking about database types.
I thought no SQL meant that they didn't use sql.
It's, it's not, it's not only sql, it's what is, what no SQL stands for.
Um, anyway, I just thought.
Important, but, but the transaction log is extremely important.
Um, the first being the one that we've already mentioned, and
that is the database crashes in the midst of something, right?
Either the database dies on the server or the server dies.
Someone pulls out a plug.
Um, and then when the database comes back up, This is the job of the
master file, the transaction log.
So we come up with the master file and the, and the database
looks at all of the data files.
And again, I know I'm using generic terms and these aren't always going
to be applicable to every database, but essentially the database comes
up and it's got something that looks across the database and
says, okay, something happened.
We need, we need to get back to a consistent.
Prasanna Malaiyandi: Put Humpty Dumpty back
together.
W. Curtis Preston: Yeah.
Right before we can let people start, we need to figure out
if we had anything in process.
We need to figure out if there were any transactions that we started recording.
That we didn't finish, right?
So the database is gonna come up and it's gonna look at each data file and
it's gonna look at the, the control file.
Like in the case of Oracle, look at the control file, otherwise
known as the master file.
And then, um, look at that transaction log and say, all right, we were
supposed to finish this transaction.
And then you're able to go to each data file and say, what Transac.
What?
Um, there's a, like, I think it's called sequence number.
Sequence number is what I think Oracle calls it.
Look at the sequence number and say, did we finish here?
Did we finish here?
Did we, oh, look at you.
You didn't get to the sequence number.
You know what, we're gonna have to roll everybody back.
Right?
That's what, that's the job of the control file is, I'm sorry, the of the
transaction log is to roll everybody back.
Um, So that, uh, we don't have, um, consistency problems
Prasanna Malaiyandi: inconsistent.
And then potentially you could also recover the database and roll back
forward and reapply that transaction
and not lose data.
W. Curtis Preston: Yeah, I wasn't gonna cover that yet, but in fact, I'm sorry.
We're gonna cover that in part two because I'm realizing that we've been talking
about this for a while and we're, you know, we're coming up on 35 minutes and
we've just covered sort of the basics.
We haven't gotten to the backup and recovery.
In the book, by the way, in the book, you occasionally see
these, those little, where is it?
The little scorpions, right?
And the scorpion is meant to be like a, a warning, right?
So here's what I have here.
Please note that just like everything else in data protection and protections
mentioned in this section, only protect against hardware failures.
So when we have.
All the things that are built into the database.
If a DBA accidentally drops a crucial table or a bad actor, uh,
deletes or encrypts your database, your fancy replication will only
make it more efficient, right?
It will immediately replicate whatever happened everywhere else.
This is why we back up databases too.
you about to say something?
Prasanna Malaiyandi: I was just going to say that for the people
listening, Databases are complicated.
So if a lot of this sort of goes over your head, don't freak out.
Don't worry.
The database admins have been doing this for years and years and years, right?
And just like you've learned sort of virtualization, which we'll
talk about later, and physical or traditional, uh, sources as well, you
just need to understand the mapping.
And there are a couple different differences for databases.
But once you understand that, It becomes a lot easier, so don't freak out.
Don't worry if this all sounds like a different language, but
W. Curtis Preston: Yeah.
And.
Prasanna Malaiyandi: just doing that mapping your head.
W. Curtis Preston: Yeah, and I listed, um, again, going to that db engines.com,
there are 13 types of databases and 300 different database products listed there.
So don't feel overwhelmed.
Um, this is not the world of, oh, is it Linux or, uh, windows or Mac, right?
This is, well, it depends, and there are types of databases.
I'll just be honest.
There are types of databases that I don't get.
Graph being one of them.
I just don't understand what or how they do.
I, I think you
Prasanna Malaiyandi: I I heard I heard a new one.
Yeah, I heard a new one recently, which was, uh, vector databases,
which is pro apparently starting to be used for like AI ml.
W. Curtis Preston: Oh, of course.
The world of A I M L.
Um, the, the thing that, the thing that you need to understand.
Uh, about any database is that it has really important data
that needs to be protected,
Prasanna Malaiyandi: Yep.
W. Curtis Preston: What you need to know about that database is, is.
From a backup and recovery perspective is you need to understand all
of the elements of that aspect.
Um, the one thing I think you will struggle with, with some databases and
some DBAs today is the same thing that we struggle with in other parts of of it, and
that is, Um, some DBAs of some products, confusing availability and um, you
know, that concept with data protection.
Um, and I think of like Cassandra MongoDB where they're like, oh, we're good.
Like we, you know, it's replicated.
We got everything three different places and, um, you know,
it's eventually consistent.
Um, and, um, we c we can lose a node.
We're good.
We can lose seven nodes.
The database will.
Okay.
What if we lose all the notes, right?
Prasanna Malaiyandi: Or what if
someone drops a table
W. Curtis Preston: what if somebody drops a
table, right?
What if, uh, what if a, you know, a ransomware, uh, a threat actor
comes in and does bad things?
I, I don't, this is just like the same argument that I make in the SaaS
world is, um, Like everything needs something that is like backup, right?
I, I have the broadest term, the broadest definition of backup that I think
anybody in the industry has, and that is anything that copies the data to another
place for the purposes of restore,
Prasanna Malaiyandi: Yep.
W. Curtis Preston: that's, you know, snapshots in a replication to.
Um, as long as we have the ability to go back in time, and as long as I
don't have the ability to, to attack the backup with the primary, that's my
biggest concern that I often have with snapshot and replication based methods.
Right.
Um, so hopefully if you're using snapshot and replication, hopefully on the other
end your copying that data somehow.
Prasanna Malaiyandi: Yep.
W. Curtis Preston: Um, if, if that's a, um, you know, a C D
P style backup, if that's tape, if that's disk, if that's cloud.
But just don't tell me this thing doesn't need backup,
that just doesn't roll with me.
Right.
Um,
Prasanna Malaiyandi: Right.
Can I, can I challenge
W. Curtis Preston: resilient, you know, go ahead.
Prasanna Malaiyandi: Sure.
I, and maybe we'll talk about this when we get to a chapter.
I think we have a chapter on cloud, right?
W. Curtis Preston: Oh yeah, I'm
Prasanna Malaiyandi: when we get there, um, one of my biggest questions is, what
about everyone who uses like Amazon s3?
W. Curtis Preston: Mm-hmm.
Prasanna Malaiyandi: Right?
Because no one didn't, as far as I know, almost no one
backs that.
W. Curtis Preston: I, I, it is a problem.
It is definitely a, a thing that needs to be discussed, and it's a
thing where, Um, I firmly stand on both sides of that, of that story.
Right.
Um, that, that's a, yeah, we will definitely, um, we will definitely
talk about that concept and you will hear me waffle back and forth.
And part of it is, um, it's a little bit different in that.
The, the multiple locations and we're get, we're got the cart before the horse.
But you're deal, you, you have something that is, um, you have features that
include both protection against node and site failure and human failure.
Prasanna Malaiyandi: Yep.
W. Curtis Preston: So if you have stuff that deals with both
of those, um, That, that's where I start to waffle a little bit.
Prasanna Malaiyandi: Yeah.
And we'll get to that
at some point.
Yeah.
Well, when we get to the chapter on
W. Curtis Preston: And we're not, and we're not gonna solve that.
We're not gonna solve that.
That problem when we get there.
But anyway, so this is the basics.
Uh, by the way, if you, if I think that resource db-engines.com,
uh, is a great resource.
Um, and, uh, to help you understand all these different models, um, and, and to
understand which model your database that.
That you're, uh, using, um, we didn't mention Postgres, right?
Postgres is another very popular, uh, I think it's gotten a lot more
popular over the years because
what?
Prasanna Malaiyandi: I was thinking like the web app development stuff.
I think they
use that a lot more.
W. Curtis Preston: Yeah, I, I think it's got, it's, it's, it's an open
source product that probably has the.
Like data integrity stuff built into it compared to MyQ l Um, there's complexity.
It goes with that, but I think that's, you know, that's the thing with that.
Uh, all right.
Well, uh, enough talking about databases, we will do part two coming up and talk
about how to back these things up.
Uh, that's, and that's really you.
That's really what we
Prasanna Malaiyandi: The meat and
W. Curtis Preston: That's really what we wanna talk about.
What's that?
The meat and potatoes.
Yeah, absolutely.
All right, well, uh, thanks for, you know, the usual good
questions, et cetera, Prasanna.
Prasanna Malaiyandi: try Curtis and I hope you have a wonderful rest of your Monday.
Happy 200th episode.
W. Curtis Preston: Happy 200th episode.
And, uh, thanks to those of you that have listened on those 200 episodes.
By the way, if you haven't listened to all 200 episodes,
you got some catching up to do.
Um, and, uh, remember to subscribe so that you can restore it all.