1
00:00:06,780 --> 00:00:08,920
- Now of course there are plenty of times,

2
00:00:08,920 --> 00:00:11,790
plenty of environments,
such as production,

3
00:00:11,790 --> 00:00:14,490
when you need a high degree of durability

4
00:00:14,490 --> 00:00:17,630
in your data that you
need not only backups,

5
00:00:17,630 --> 00:00:22,470
but also, maybe even, multiple
copies of the data live

6
00:00:22,470 --> 00:00:25,530
and ready to go, so that
in case one is unavailable,

7
00:00:25,530 --> 00:00:27,030
you can switch to another.

8
00:00:27,030 --> 00:00:31,610
So we have several options
within RDS to help us with that.

9
00:00:31,610 --> 00:00:35,760
The first option would
be Multi-AZ Deployments.

10
00:00:35,760 --> 00:00:38,470
With Multi-AZ Deployments,
as you can see here,

11
00:00:38,470 --> 00:00:41,330
we would choose, of course
we would choose, a region.

12
00:00:41,330 --> 00:00:43,790
In this example we're
using the Oregon region

13
00:00:43,790 --> 00:00:45,740
in us-west-2.

14
00:00:45,740 --> 00:00:49,040
And for Multi-AZ Deployment,
we need to choose,

15
00:00:49,040 --> 00:00:50,993
or we need to enable,

16
00:00:52,040 --> 00:00:56,340
RDS to leverage multiple
availability zones.

17
00:00:56,340 --> 00:00:57,173
Right?

18
00:00:57,173 --> 00:01:01,920
So we are creating a
VPC and creating subnets

19
00:01:01,920 --> 00:01:05,720
that allow us to use these two different

20
00:01:05,720 --> 00:01:06,760
availability zones.

21
00:01:06,760 --> 00:01:09,830
Both us in this example,
us-west-2b and 2c.

22
00:01:09,830 --> 00:01:13,640
And of course, you can see
here, in order to do that,

23
00:01:13,640 --> 00:01:16,200
we've created two different subnets.

24
00:01:16,200 --> 00:01:18,460
Right, each with their own range.

25
00:01:18,460 --> 00:01:22,840
And the benefit of Multi-AZ
Deployments is that we get

26
00:01:22,840 --> 00:01:26,860
not only a primary, not just one instance,

27
00:01:26,860 --> 00:01:31,350
we also get a stand-by instance,

28
00:01:31,350 --> 00:01:35,720
and of course AWS creates and manages

29
00:01:35,720 --> 00:01:37,710
both of those instances.

30
00:01:37,710 --> 00:01:41,680
And then AWS also manages the ongoing

31
00:01:41,680 --> 00:01:44,029
synchronous replication between them.

32
00:01:44,029 --> 00:01:45,010
Right?

33
00:01:45,010 --> 00:01:47,220
So you can see here with
Multi-AZ Deployments,

34
00:01:47,220 --> 00:01:52,000
we have multiple copies
of the data that's live,

35
00:01:52,000 --> 00:01:54,890
that we can switch from one
to the other very quickly,

36
00:01:54,890 --> 00:01:55,863
and very easily.

37
00:01:56,850 --> 00:02:00,400
And so, again with Multi-AZ Deployments,

38
00:02:00,400 --> 00:02:02,750
we gain access to not
just high availability,

39
00:02:02,750 --> 00:02:04,810
but also fault tolerance.

40
00:02:04,810 --> 00:02:07,970
There is some built in fault tolerance,

41
00:02:07,970 --> 00:02:10,510
so that if the primary fails,

42
00:02:10,510 --> 00:02:12,190
we can switch over automatically,

43
00:02:12,190 --> 00:02:14,890
or failover to that secondary.

44
00:02:14,890 --> 00:02:19,380
And of course, that is,
Amazon handles the synchronous

45
00:02:19,380 --> 00:02:21,360
replication between those two,

46
00:02:21,360 --> 00:02:25,720
and those are built and not
only on physically distinct

47
00:02:25,720 --> 00:02:29,360
servers, but also in physically
distinct data centers.

48
00:02:29,360 --> 00:02:30,430
Remember, we just talked

49
00:02:30,430 --> 00:02:32,610
about the two different availability zones

50
00:02:32,610 --> 00:02:35,980
and we know that those
different availability zones

51
00:02:35,980 --> 00:02:37,853
are physically distinct centers.

52
00:02:38,810 --> 00:02:42,760
And so, automatic failover
can take place if there's

53
00:02:42,760 --> 00:02:44,630
a loss of a network.

54
00:02:44,630 --> 00:02:49,240
Right, so, if the primary is
unreachable due to some issue

55
00:02:49,240 --> 00:02:50,600
with the network,

56
00:02:50,600 --> 00:02:53,960
if the primary is unreachable

57
00:02:53,960 --> 00:02:56,720
because there was an
underlying compute failure

58
00:02:56,720 --> 00:02:58,980
or an underlying storage failure,

59
00:02:58,980 --> 00:03:03,660
then AWS will automatically promote

60
00:03:03,660 --> 00:03:06,360
the secondary to primary,

61
00:03:06,360 --> 00:03:10,620
switch us over and then
automatically replace

62
00:03:10,620 --> 00:03:14,210
the failed primary, which then becomes

63
00:03:14,210 --> 00:03:15,393
the new secondary.

64
00:03:16,510 --> 00:03:19,240
And then of course, this is considered

65
00:03:19,240 --> 00:03:21,180
a production best practice.

66
00:03:21,180 --> 00:03:24,630
So if you are running
production workloads on RDS,

67
00:03:24,630 --> 00:03:28,290
Amazon does recommend that you opt

68
00:03:28,290 --> 00:03:30,370
into a Multi-AZ Deployment.

69
00:03:30,370 --> 00:03:32,800
Remember that that is not the default.

70
00:03:32,800 --> 00:03:37,800
If you need that secondary instance live,

71
00:03:37,800 --> 00:03:40,580
if you need the ability
to automatically failover,

72
00:03:40,580 --> 00:03:42,260
you, it is up to you,

73
00:03:42,260 --> 00:03:44,453
to choose a Multi-AZ Deployment.

74
00:03:45,450 --> 00:03:49,210
Now another option that we
have in order to help us

75
00:03:49,210 --> 00:03:52,060
with data durability are backups.

76
00:03:52,060 --> 00:03:56,740
And of course RDS performs
these backups automatically,

77
00:03:56,740 --> 00:04:01,740
and we know that because RDS
is essentially built on top

78
00:04:02,650 --> 00:04:07,650
of EC2 and EBS that those
Snapshots will go to S3.

79
00:04:09,450 --> 00:04:13,660
And we know that S3 is
inherently replicated across

80
00:04:13,660 --> 00:04:15,660
numerous availability zones.

81
00:04:15,660 --> 00:04:18,930
Right, so there is an even
higher degree of durability

82
00:04:18,930 --> 00:04:20,893
when the data is stored in S3.

83
00:04:21,899 --> 00:04:25,160
And so, we get to choose
the window of time,

84
00:04:25,160 --> 00:04:27,300
when does the backup happen.

85
00:04:27,300 --> 00:04:28,133
Right?

86
00:04:28,133 --> 00:04:30,175
Perhaps when you have the
lowest amount of traffic

87
00:04:30,175 --> 00:04:32,610
or the lowest amount of work being done

88
00:04:32,610 --> 00:04:34,900
by the database.

89
00:04:34,900 --> 00:04:35,733
Right?

90
00:04:35,733 --> 00:04:37,870
Who knows, that could
be 1:00 a.m., 5:00 a.m.,

91
00:04:37,870 --> 00:04:39,990
whenever that window is for you,

92
00:04:39,990 --> 00:04:42,000
you get to determine when that backup

93
00:04:42,000 --> 00:04:43,030
actually happens.

94
00:04:43,030 --> 00:04:45,660
And that is performed,
the automated backups,

95
00:04:45,660 --> 00:04:47,263
are performed once per day.

96
00:04:48,160 --> 00:04:50,920
And, like I said, those are
essentially the same thing

97
00:04:50,920 --> 00:04:52,311
as an EBS Snapshot.

98
00:04:52,311 --> 00:04:53,144
Right?

99
00:04:53,144 --> 00:04:56,440
They're taken from the
volume and written to S3,

100
00:04:56,440 --> 00:05:01,440
and those automated backups
are retained for up to 35 days,

101
00:05:01,540 --> 00:05:05,720
so you do get a pretty
decent period of time

102
00:05:05,720 --> 00:05:07,620
to which you can roll back.

103
00:05:07,620 --> 00:05:10,820
You can easily restore an entire database

104
00:05:12,550 --> 00:05:14,653
from a backup.

105
00:05:15,570 --> 00:05:18,300
We can also perform a
point-in-time restore,

106
00:05:18,300 --> 00:05:20,653
up to a five minute window.

107
00:05:22,160 --> 00:05:27,160
And you can also copy those
backups to another region,

108
00:05:27,250 --> 00:05:30,030
so if you wanted to gain
an even greater degree

109
00:05:30,030 --> 00:05:33,270
of durability, to have,
you know, if you wanted

110
00:05:33,270 --> 00:05:35,550
to have two copies of the data live

111
00:05:35,550 --> 00:05:38,700
with Multi-AZ Deployments,
you have backups

112
00:05:38,700 --> 00:05:40,180
in that same region,

113
00:05:40,180 --> 00:05:42,010
and then to take it a step further,

114
00:05:42,010 --> 00:05:45,420
by copying those backups
to another region,

115
00:05:45,420 --> 00:05:48,330
now you have yet another,
not just one copy,

116
00:05:48,330 --> 00:05:51,510
but ultimately, because
again, because it's NS3,

117
00:05:51,510 --> 00:05:54,840
you have multiple copies
in that other region,

118
00:05:54,840 --> 00:05:56,520
thousands of miles apart.

119
00:05:56,520 --> 00:05:58,980
So if there is some kind of a disaster,

120
00:05:58,980 --> 00:06:02,110
you know that that data is still available

121
00:06:02,110 --> 00:06:03,956
in another region.

122
00:06:03,956 --> 00:06:07,450
So, we have between Multi-AZ Deployments

123
00:06:07,450 --> 00:06:10,830
and automated backups,
we have plenty of tools

124
00:06:10,830 --> 00:06:14,400
that make it very easy for us to ensure

125
00:06:14,400 --> 00:06:19,313
a very high degree of
durability in our data with RDS.