1
00:00:00,004 --> 00:00:03,874
Michael: Hello, and welcome to Postgres fm, a weekly show about all things PostGresQ.

2
00:00:04,234 --> 00:00:08,314
I'm Michael, founder of PG Mustard, and this is my co-host Nikolai, founder of Postgres ai.

3
00:00:08,584 --> 00:00:10,024
Hey, Nikolai, what are we talking about today?

4
00:00:10,624 --> 00:00:15,951
Nikolay: This week is my choice and  I choose replication, but this is just one word.

5
00:00:15,993 --> 00:00:17,553
But huge, huge topic.

6
00:00:18,085 --> 00:00:20,485
Let's try to talk about replication.

7
00:00:20,818 --> 00:00:27,788
Only trying to focus on areas which are interesting to backend developers and architects.

8
00:00:28,178 --> 00:00:32,348
So for, for people who create something, build something, and so on.

9
00:00:33,176 --> 00:00:33,926
Michael: Yeah, exactly.

10
00:00:33,926 --> 00:00:34,346
Let's make sure.

11
00:00:34,383 --> 00:00:40,213
it'd be cool to cover the different options people have and the problems they're generally trying to solve when they're looking into this.

12
00:00:40,453 --> 00:00:44,158
We also had a couple of requests from listeners that cover this, so we've got.

13
00:00:44,588 --> 00:00:46,535
The differences between    physical and logical.

14
00:00:46,895 --> 00:00:51,441
And also challenges on different managed services, especially rds.

15
00:00:51,525 --> 00:00:52,245
So that would be cool.

16
00:00:52,635 --> 00:00:56,105
And options like WAL shipping WAL streaming, if that came in via

17
00:00:56,170 --> 00:00:57,730
Nikolay: sub, two subtypes of physical.

18
00:00:57,730 --> 00:00:58,060
Right, right.

19
00:00:58,720 --> 00:01:03,009
Well, let's start from the problem like why at all  do we need replication?

20
00:01:03,056 --> 00:01:03,716
I see.

21
00:01:04,721 --> 00:01:09,191
areas where replication is needed and two of them are major.

22
00:01:09,551 --> 00:01:14,395
And third is kind of controversial so first question.

23
00:01:14,647 --> 00:01:24,113
Where replication might be needed is high mult What, for example, in cloud our VM can be done anytime, so we don't want to have.

24
00:01:24,953 --> 00:01:25,193
Right.

25
00:01:25,198 --> 00:01:29,127
So we, we want to have zero, almost zero downtime or downtime.

26
00:01:29,127 --> 00:01:30,477
Less than one minute, always.

27
00:01:31,000 --> 00:01:31,210
Michael: Yeah.

28
00:01:31,210 --> 00:01:35,680
Or even if we self-host the machine can, like things can go wrong with one.

29
00:01:36,715 --> 00:01:40,123
For it to fail over to a, a secondary is super helpful.

30
00:01:40,363 --> 00:01:41,053
Sorry, Stan.

31
00:01:41,533 --> 00:01:45,315
I see primary and standby as the, as the language in the ducks.

32
00:01:47,205 --> 00:01:49,842
Nikolay: You have some service in data center in this case.

33
00:01:50,577 --> 00:01:55,347
Perfect opportunity to go a different route and go blame your provider of hardware and so on.

34
00:01:55,437 --> 00:02:00,843
So like in, in the case of clouds this is less possible.

35
00:02:00,873 --> 00:02:04,612
So, usually, and, and issues happen more often actually.

36
00:02:04,739 --> 00:02:07,828
Naturally you can have very good hardware.

37
00:02:07,833 --> 00:02:13,045
So each server is running years and cloud is also possible, but less often.

38
00:02:13,586 --> 00:02:15,549
And this is, this is the first option anyway.

39
00:02:15,751 --> 00:02:26,984
Second is I have I CPU or like, I, I, I have almost saturated disc or everything is out of cash or something like I, I have resources which are close to saturation.

40
00:02:27,344 --> 00:02:41,707
So one machine is not enough, and in my opinion, this second option in clouds, they, it's also definitely
possible, but you in clouds, it's easier to just increase resources switching to more powerful machine, right?

41
00:02:42,097 --> 00:02:45,648
Which is , like less convenient to do out of clouds.

42
00:02:45,698 --> 00:02:47,071
So this, this reason.

43
00:02:47,641 --> 00:02:53,491
Triggers more, like maybe sooner, not if you're not, not, not on cloud.

44
00:02:54,001 --> 00:03:01,582
But anyway, in cloud it also triggers and at some point you want to offload reads to, different server and POS allows it.

45
00:03:01,619 --> 00:03:06,599
And the third option is using replication in addition or, instead of backups.

46
00:03:07,229 --> 00:03:09,179
And usually it's a bad idea.

47
00:03:09,179 --> 00:03:10,605
First of all, if you.

48
00:03:11,075 --> 00:03:17,125
, for example, you'll lose, like if you lose whole one node, it, it's, it's about aha.

49
00:03:17,125 --> 00:03:19,015
It's not about disaster recovery and backups.

50
00:03:19,345 --> 00:03:31,566
But if, for example, someone deleted something, a replication immediately delivered this propagated this change to all nodes, so That's why we also always say like, replication is not for backups.

51
00:03:31,625 --> 00:03:40,699
But in pogo for physical replication, there is an option to have a special replica, which will be delayed by several hours.

52
00:03:40,699 --> 00:03:41,839
For example, like four hours.

53
00:03:42,229 --> 00:03:51,908
And if someone deleted something, you can use that replica and actually promoted, not promote replay additional walls until the point right before deli.

54
00:03:52,673 --> 00:03:52,733
It.

55
00:03:53,723 --> 00:03:53,993
Right.

56
00:03:53,993 --> 00:04:01,361
And if you know this, this time, because it's sometimes it's not easy to find, and then you can restore, manually, restore the data, which was deleted.

57
00:04:01,631 --> 00:04:03,221
It's called delayed replica approach.

58
00:04:03,221 --> 00:04:09,943
But I like it, not so much because it's, it's better to use branching or like for example Database Lab Engine.

59
00:04:10,498 --> 00:04:15,878
and to have a specialized replica with snapshots every, like, for example, two or four hours or one hour.

60
00:04:15,878 --> 00:04:20,579
And we have a recipe to, to do the same point in time recovery starting from some snapshot.

61
00:04:20,584 --> 00:04:24,426
In this case, it's very fast  but always, there is no option to restore from backups.

62
00:04:24,426 --> 00:04:26,646
You should have backups with four point in time recovery.

63
00:04:26,646 --> 00:04:30,146
We've con continuously Archived walls, so you can restore from there.

64
00:04:30,151 --> 00:04:35,066
But if your database is, for example, one terabyte, you should be prepared to spend roughly one hour.

65
00:04:35,456 --> 00:04:39,746
If it's 10 terabyte, 10 hours roughly, sometimes five.

66
00:04:40,049 --> 00:04:41,359
so back to the main.

67
00:04:41,419 --> 00:04:44,225
So we will focus on two main,  use cases.

68
00:04:44,304 --> 00:04:46,664
We want to offload some work.

69
00:04:47,414 --> 00:04:53,988
To different server or we want also to achieve very low downtime if something bad happens with some node.

70
00:04:54,369 --> 00:04:56,658
And of course obviously interesting.

71
00:04:56,718 --> 00:05:01,828
Historically in pogs there was some idea this should be implemented outside of.

72
00:05:02,713 --> 00:05:09,923
replication, I mean, It only, as I remember, in 9.0 replication was implemented in core physical replication.

73
00:05:10,402 --> 00:05:10,612
Am

74
00:05:10,687 --> 00:05:11,017
Michael: Oh really?

75
00:05:11,017 --> 00:05:11,557
That recently?

76
00:05:12,202 --> 00:05:15,202
Nikolay: Am I right about nine zero or it was eight something?

77
00:05:15,232 --> 00:05:18,442
I, I, we should check, but it was not long ago.

78
00:05:18,442 --> 00:05:21,892
Like in, in, in the middle of, like in, for example, in 2000.

79
00:05:22,579 --> 00:05:27,593
we didn't have replication and still there are ongoing discussions like we, we shouldn't have it in the engine.

80
00:05:27,593 --> 00:05:28,553
That should be outside.

81
00:05:28,733 --> 00:05:33,965
And there was a system called sloany, which implemented logical replication actually based on triggers.

82
00:05:34,325 --> 00:05:40,231
And it was very difficult to, like you, you, you need to ma to allocate a single hole.

83
00:05:40,651 --> 00:05:41,812
DBA to maintain it.

84
00:05:41,817 --> 00:05:43,689
So it was not easy to maintain.

85
00:05:43,694 --> 00:05:51,227
And then sky Skype implemented long also based on triggers, slightly better in terms of maintenance.

86
00:05:51,288 --> 00:06:05,877
and the good about those systems was, was that, You can add additional logic easily because you can specify
which tables you want to take and you can actually make transformations on the fly, like a lot of flexibility.

87
00:06:06,198 --> 00:06:08,344
But of course this is based on triggers.

88
00:06:08,344 --> 00:06:13,269
There is overhead you write to a table and trigger rights to additional table, right?

89
00:06:13,389 --> 00:06:16,646
Like so, so, so to then consumers propagate changes.

90
00:06:16,658 --> 00:06:17,541
That additional table.

91
00:06:17,991 --> 00:06:26,398
So kind of significant overhead, but you can replicate from one major pro version to another major pro version.

92
00:06:26,458 --> 00:06:26,758
Great.

93
00:06:27,718 --> 00:06:31,973
But nobody guarantees that subscribers or recipient node will have the same data.

94
00:06:31,978 --> 00:06:34,139
Like like there, there are many risk.

95
00:06:34,178 --> 00:06:35,198
When you use the system.

96
00:06:35,738 --> 00:06:38,597
So it's, it's not as reliable.

97
00:06:39,017 --> 00:06:42,007
And then based on wall, wall existed, write a headlock.

98
00:06:42,007 --> 00:06:43,957
So bogus writes any change.

99
00:06:43,987 --> 00:06:50,378
First to write a headlock and then to, and, and synchronize it to with disks, right?

100
00:06:50,383 --> 00:06:55,748
So it's it's guaranteed that right headlock has all physical instructions of all changes.

101
00:06:56,048 --> 00:06:56,738
So based on the.

102
00:06:57,743 --> 00:07:07,896
The idea is wall is is is used when we replay POCUS after crash, replace changes since LA latest last checkpoint.

103
00:07:08,856 --> 00:07:16,570
And the idea was let's take this mechanism and have another note which will be always replaying these walls and it'll.

104
00:07:17,415 --> 00:07:19,945
Constantly replaying them and that's it.

105
00:07:20,955 --> 00:07:24,065
It, it won't be allowed for the snow to ride.

106
00:07:24,660 --> 00:07:26,700
Itself always to just to replay.

107
00:07:27,420 --> 00:07:29,910
So like constantly being in recovery mode.

108
00:07:29,940 --> 00:07:37,890
That's why function to check if it's primary note or replica note, standby note, it's called PG is in recovery.

109
00:07:38,310 --> 00:07:41,646
It's very confusing like each standby note each.

110
00:07:42,047 --> 00:07:49,992
Replica, it's like kind of in recovery constantly, but it's, there is additional like recovery process for st by nose.

111
00:07:50,082 --> 00:07:51,762
After crash, it also can crash, right?

112
00:07:52,092 --> 00:07:55,842
So there is recovery and then we, like, there are two types of recovery state.

113
00:07:56,162 --> 00:07:59,972
I, I would say like normal and not normal.

114
00:08:00,502 --> 00:08:00,852
. So,

115
00:08:01,732 --> 00:08:15,622
Michael: It's a really good point though, because I think some people come to this, haven't had experience of other databases and
wonder if there is a way of having multiple nodes that they can write to in Postgres, and that's not an option in Vanilla Postgres.

116
00:08:15,952 --> 00:08:19,952
Whereas there's some kind of Postgres compatible database that do allow that.

117
00:08:19,952 --> 00:08:27,726
We live in a world of you have one primary that you can write to and then you can have multiple replicas from that that you can read from as well.

118
00:08:28,401 --> 00:08:28,791
Nikolay: Right.

119
00:08:29,273 --> 00:08:35,997
For physical replication, physical application is based on the wall and it's just we are in constant in recovery, but accepting connections.

120
00:08:35,997 --> 00:08:37,317
Okay, we have physical standby.

121
00:08:37,647 --> 00:08:39,872
What we need to understand that it's everything.

122
00:08:39,872 --> 00:08:43,256
Unfortunately, pog gras wall, it's like it's single thing for.

123
00:08:44,066 --> 00:08:46,466
Postal server, so-called cluster and postal documentation.

124
00:08:46,706 --> 00:08:54,794
So we cannot take only one database, unfortunately, although such projects exist, exist, and maybe it'll be implemented at some point.

125
00:08:54,903 --> 00:08:57,787
Other database systems supported, for example, SQL Server.

126
00:08:58,317 --> 00:09:03,719
So what we have here, we have node, which is constantly replaying walls.

127
00:09:04,174 --> 00:09:05,624
It means that everything is there.

128
00:09:05,684 --> 00:09:07,394
Everything all tables, even blo.

129
00:09:08,132 --> 00:09:09,572
, which is good actually sometimes.

130
00:09:10,262 --> 00:09:11,075
And physical.

131
00:09:11,105 --> 00:09:12,845
This is called, called physical application.

132
00:09:12,845 --> 00:09:22,434
And you mentioned in request there are two subtypes of physical application based on wall shipping and historically it was implemented first and second streaming.

133
00:09:22,434 --> 00:09:23,407
Why We have two.

134
00:09:24,092 --> 00:09:25,862
Because they're slightly different.

135
00:09:25,908 --> 00:09:29,038
Wall shipping is more like, I would say it's more reliable.

136
00:09:29,458 --> 00:09:39,026
And it also, you can ship walls from archive, from object store like s3, s3, and even primary won't know about you.

137
00:09:39,031 --> 00:09:40,436
It's convenient.

138
00:09:40,436 --> 00:09:43,256
You can have a lot of replicas like that.

139
00:09:43,916 --> 00:09:47,821
But leg can be significant like some seconds already.

140
00:09:47,971 --> 00:09:48,241
Michael: Okay.

141
00:09:48,681 --> 00:09:48,921
Interesting.

142
00:09:49,006 --> 00:09:49,246
Nikolay: Yeah.

143
00:09:49,666 --> 00:09:53,056
And uh, all files are 16 max by default.

144
00:09:53,296 --> 00:10:00,843
As I remember, RDS increased them to 64, if I'm not mistaken, but to get that file to store it like it takes some time.

145
00:10:01,083 --> 00:10:11,711
So that's why streaming replication was additionally implemented to, in an effort to minimize the leg and also to get control, better control replication.

146
00:10:12,622 --> 00:10:22,038
application slot is just the idea that it should be visible that we have a standby notes and we should be able to understand  what are the leg there.

147
00:10:22,218 --> 00:10:24,648
And you can see even detailed leg there.

148
00:10:25,098 --> 00:10:29,088
So when you design some system, you can understand, okay, we will have standbys.

149
00:10:29,589 --> 00:10:31,299
They will be asynchronous by nature.

150
00:10:31,359 --> 00:10:48,719
So legs are possible and we can also see from the sitting on the primary what are the legs including phases of the leg,
like in transfer or like flashing to disc or replaying, like where like how like is we can zoom into like and see it on.

151
00:10:48,732 --> 00:10:50,172
Under like closer.

152
00:10:50,562 --> 00:10:57,228
So, so,  standby notes are asynchronous, but it's possible to make them synchronous as well with obvious trade off.

153
00:10:57,314 --> 00:11:09,348
If we say we need synchronous behavior, then we need to, our transaction at commit time will, will need
to wait until the, this transaction confirmed to be written, committed on both notes or on three notes.

154
00:11:09,348 --> 00:11:10,428
It's very expensive in terms.

155
00:11:10,519 --> 00:11:12,589
Writing transactions, right?

156
00:11:12,859 --> 00:11:16,119
But with f Trick, you can design it your system.

157
00:11:16,639 --> 00:11:18,978
Not every transaction will behave like that.

158
00:11:19,008 --> 00:11:24,552
You can be, you can have node synchronous by nature, but then say, this transaction is super important.

159
00:11:24,557 --> 00:11:28,666
So I want this transaction to be, to behave as as synchronous you.

160
00:11:28,666 --> 00:11:32,057
It, it is a controlled vr uh, synchronous commit, right?

161
00:11:32,057 --> 00:11:36,437
So you can say, I want this to be saved on multiple servers.

162
00:11:36,977 --> 00:11:37,847
This is, this is strict.

163
00:11:37,997 --> 00:11:40,517
Not everyone knows, right?

164
00:11:40,877 --> 00:11:41,297
So,

165
00:11:41,342 --> 00:11:42,092
Michael: Yeah, I didn't know that.

166
00:11:42,092 --> 00:11:43,022
That's the main, that's cool.

167
00:11:43,082 --> 00:11:43,682
Do you use that?

168
00:11:44,128 --> 00:11:50,394
Nikolay: Uh, No, I actually, I, I see a lot of companies and people who, who u use synchronous standby notes.

169
00:11:50,399 --> 00:11:54,238
And also there is an option to say, okay, I have ma many standby notes.

170
00:11:54,238 --> 00:11:57,778
I, I want at least one of them to, to receive the.

171
00:11:58,148 --> 00:11:58,898
of the change.

172
00:11:59,198 --> 00:12:00,338
It's called quo commit.

173
00:12:00,398 --> 00:12:03,788
You say how many nodes should receive it out of all existing nodes.

174
00:12:04,298 --> 00:12:13,063
It's also possible, like there are many things that which are now possible for physical application, but somehow, we live with a synchronous, nodes and leg are very small.

175
00:12:13,068 --> 00:12:18,659
We control them usually using slots and later newest post versions have protection.

176
00:12:19,049 --> 00:12:24,153
There is like, I remember my ops people told me they are afraid of.

177
00:12:24,170 --> 00:12:30,617
Slots because if some node is down, slot is accumulating a lot, big leg, and then you're out of disc on the primary.

178
00:12:31,037 --> 00:12:31,967
Now we have protection.

179
00:12:31,967 --> 00:12:37,613
I don't remember the parameter, but you can say not more than this number of gigabytes.

180
00:12:37,943 --> 00:12:42,726
Then this node will be considered as completely lost and slot will be.

181
00:12:43,361 --> 00:12:47,201
Not working anymore, but you are, you're safe, you're free space on the primary.

182
00:12:47,891 --> 00:12:50,081
So like, it's, it's quite powerful.

183
00:12:50,291 --> 00:12:56,741
But for if, if I'm a backend developer, I need to understand that nature is by default is asynchronous.

184
00:12:57,431 --> 00:12:59,861
If I want synchronous, I won't be very careful.

185
00:13:00,251 --> 00:13:03,882
I want to understand all network evidences because network is involved now.

186
00:13:03,882 --> 00:13:04,212
Right?

187
00:13:04,932 --> 00:13:09,941
And of course, if I use standbys only for a shape, high avail.

188
00:13:10,937 --> 00:13:11,747
, it matters less.

189
00:13:12,197 --> 00:13:14,537
And I of course should use Petro or something.

190
00:13:14,537 --> 00:13:15,647
Petro is the most popular.

191
00:13:15,647 --> 00:13:19,277
Autofill other, by the way, same idea, which should not be be in core.

192
00:13:19,277 --> 00:13:20,987
That's why it's outside here.

193
00:13:21,617 --> 00:13:23,237
Like in replication.

194
00:13:23,297 --> 00:13:28,157
The idea, let's have it in core one for autofill, other not yet.

195
00:13:28,307 --> 00:13:36,076
It's still outside my opinion, everything should be in court, but there are many things obviously that prevented from happening.

196
00:13:36,556 --> 00:13:37,426
So if you.

197
00:13:39,586 --> 00:13:42,646
You don't put load there, you have a lot of money.

198
00:13:43,216 --> 00:13:43,606
Why not?

199
00:13:44,266 --> 00:13:49,705
Then you don't deal with, like, you just need to control the leg in terms of the health of this node, right?

200
00:13:50,236 --> 00:13:54,612
And primary is down, and leg is known to be small.

201
00:13:54,782 --> 00:13:55,272
Okay?

202
00:13:55,482 --> 00:13:56,412
Data loss is small.

203
00:13:56,442 --> 00:13:58,722
If it exceeds, for example, in Petro, we control it.

204
00:13:58,782 --> 00:13:59,682
We can set.

205
00:14:00,537 --> 00:14:03,312
Allowed leg for failover event.

206
00:14:03,532 --> 00:14:10,440
if it exceeds, if, if Patran knows that the leg is too high, failover won't happen because we don't want data loss.

207
00:14:10,680 --> 00:14:11,910
So we can prioritize.

208
00:14:11,940 --> 00:14:14,890
We, we have trade off here, what to do, failover and.

209
00:14:15,301 --> 00:14:19,941
Have lower downtime or we want to save all our, our data.

210
00:14:19,941 --> 00:14:27,771
We don't have, we don't want data loss, so we probably have, it's better to have downtime, but try to fix primary and save data.

211
00:14:28,401 --> 00:14:29,721
There is, there is trade off here

212
00:14:30,306 --> 00:14:33,606
Michael: If, if people want to like read up more about this kind of thing.

213
00:14:33,606 --> 00:14:45,588
I've seen people using the, like if your, if your boss is demanding zero data loss and instant failover the,
I've seen the, the letters, the acronyms, R p o and R T O and people have written a lot of useful guides

214
00:14:45,723 --> 00:14:50,253
Nikolay: Well, R P R two is good to understand, but it's more like ops terms,

215
00:14:50,913 --> 00:14:51,593
Michael: Yeah, exactly.

216
00:14:52,308 --> 00:14:56,944
Nikolay: How to define as slo sla, R P O R T O.

217
00:14:56,944 --> 00:14:59,541
Yeah, returning to these subtypes.

218
00:15:00,049 --> 00:15:02,019
Now we have wall shipping and we have streaming.

219
00:15:02,019 --> 00:15:11,174
Of course, streaming should be preferred if you want smaller leg on your notes, and especially if you want  to offload.

220
00:15:12,538 --> 00:15:15,578
you, you will want to upload that also to reduce load.

221
00:15:15,638 --> 00:15:17,990
Or very often it's CPU load.

222
00:15:17,990 --> 00:15:38,519
Sometimes this scale you want to upload it to replicas, standby servers you probably would, would prefer streaming and with
replications lost for better observability, but,  the trick everyone implements, everyone who deals with such system is okay.

223
00:15:39,029 --> 00:15:42,089
We have, sometimes we have leg few seconds.

224
00:15:42,479 --> 00:15:54,149
What if, and for example, we, we have a page or mobile app, we, and user created something and then immediately tries to search, trying to check the result.

225
00:15:54,869 --> 00:15:58,392
If user is very fast and our standby node has some.

226
00:15:59,217 --> 00:16:04,317
User might see in like, no new items in the results set.

227
00:16:04,317 --> 00:16:07,167
Where is my, where is my post or comment or something?

228
00:16:07,887 --> 00:16:14,130
In this case every, every experience backend developer implements the pattern,  sticky reads.

229
00:16:14,135 --> 00:16:17,100
I, I say, I, I said, I named it like this sticker.

230
00:16:17,100 --> 00:16:19,440
Its so you say, okay.

231
00:16:20,069 --> 00:16:28,018
In my session or this user or something, you need to identify somehow your user, if you have sessions it's session.

232
00:16:28,078 --> 00:16:32,218
If you have like rest api, no, no context on server.

233
00:16:32,223 --> 00:16:36,598
So maybe you need somehow to identify like, like customers, user id.

234
00:16:36,868 --> 00:16:42,752
So you say, okay, some recent data change happened and we mark this user as.

235
00:16:42,803 --> 00:16:44,423
Recently changed database.

236
00:16:44,831 --> 00:16:46,435
some flag in cash.

237
00:16:46,435 --> 00:16:48,415
In some cash, like ma'am, cash radius, anything.

238
00:16:48,917 --> 00:16:55,101
And in this case you need to teach your backend to work only with primary for some period of time.

239
00:16:55,597 --> 00:16:56,167
stick old.

240
00:16:56,878 --> 00:16:58,018
res to the primary.

241
00:16:58,181 --> 00:17:00,821
that's why I call it sticky, sticky reeds or sticky salads.

242
00:17:01,751 --> 00:17:11,290
And the funny thing that couple of years ago, rails, Rubian rails, they implemented it so they, it's, it's there and you just can use it.

243
00:17:11,290 --> 00:17:11,710
That's it.

244
00:17:12,040 --> 00:17:17,418
It's, I think every framework should think about it because they should think about scale scaling.

245
00:17:18,003 --> 00:17:24,483
and performance issues because if you don't scale, you will be, users will be suffering in terms of performance.

246
00:17:24,903 --> 00:17:30,834
Clo, the closer you to situation, for example, of cpu, the bigger problems  can happen.

247
00:17:31,614 --> 00:17:32,214
So

248
00:17:32,279 --> 00:17:33,324
Michael: also sometimes.

249
00:17:33,514 --> 00:17:33,674
Nikolay: good?

250
00:17:33,674 --> 00:17:34,154
Mm-hmm.

251
00:17:34,194 --> 00:17:35,604
Michael: Yeah, that sounds, that sounds cool.

252
00:17:35,609 --> 00:17:39,935
I've the other thing I see people using replicas for in terms of reads are.

253
00:17:40,945 --> 00:17:42,805
Kind of read only parts of the app.

254
00:17:42,805 --> 00:17:48,141
So like analytic, like dashboards or their own internal analytics, that kind of thing.

255
00:17:50,571 --> 00:17:51,851
What, what risks are there?

256
00:17:51,851 --> 00:17:52,091
There?

257
00:17:52,121 --> 00:17:53,498
Nikolay: POCUS doesn't allow to do it.

258
00:17:53,498 --> 00:17:57,657
Without consequences, you have two options and both are bad.

259
00:17:57,717 --> 00:18:01,107
You just need to choose which is less bad in your case.

260
00:18:01,437 --> 00:18:06,562
First option,  you have regular standby which means host standby feedback is off.

261
00:18:07,072 --> 00:18:08,042
Host standby feedback.

262
00:18:08,109 --> 00:18:12,177
Signals to the primary, the state of our standby.

263
00:18:12,362 --> 00:18:13,892
It's, it's controlled on standby.

264
00:18:13,892 --> 00:18:19,464
On each standby you can define it and it says, okay, if it's off, I don't care.

265
00:18:19,464 --> 00:18:23,156
Like primary do, doesn't, shouldn't know about where I am.

266
00:18:23,656 --> 00:18:30,456
And, but this means that any transaction that lasts longer and all analytical queries tend to last longer.

267
00:18:30,456 --> 00:18:30,696
Right?

268
00:18:31,356 --> 00:18:33,006
They will pause replica.

269
00:18:34,135 --> 00:18:44,897
and there is, there are parameters for streaming and for wall shipping separately, which define maximum duration because af after which we can say, okay, it's, it's enough, and we cancel.

270
00:18:44,927 --> 00:18:47,247
Transaction in favor to replay.

271
00:18:47,822 --> 00:18:52,209
New changes from wall uh, streaming or wall shipped, doesn't matter.

272
00:18:52,305 --> 00:19:00,495
This is not good because it makes your note like single user because other users, like for example, one user is using, okay, I'm using it fir first.

273
00:19:00,495 --> 00:19:06,195
Danger is that at some point transaction can, like my read, only cell can be canceled.

274
00:19:06,195 --> 00:19:11,515
It's one can, but I can adjust this parameter and, and allow like couple of apps.

275
00:19:11,965 --> 00:19:15,484
But other users coming to this, Observe.

276
00:19:15,484 --> 00:19:16,264
Huge lag.

277
00:19:17,164 --> 00:19:24,464
That's why I, I say like, virtually this is a single user note, like, you're alone there, like, others will suffer.

278
00:19:24,464 --> 00:19:25,874
So it's, it's not convenient.

279
00:19:25,879 --> 00:19:29,450
That's why in this case there is another option, which is also bad.

280
00:19:29,450 --> 00:19:34,934
It's called constant by feedback being on, we are turning on and standby.

281
00:19:35,049 --> 00:19:37,699
Reports to the primary, about Xmen Horizon.

282
00:19:38,029 --> 00:19:46,286
Well, like we have transaction IDs and we have many transactions happening at the same time, like constantly because it's multiuser, multi multiuser system, right?

283
00:19:46,886 --> 00:19:54,578
And there is a vacuum, which, which should clean that two poles, which already dead for all transactions.

284
00:19:54,908 --> 00:20:03,138
But how to define for which, like all to define all here, we need to understand which is the oldest transaction still ongoing.

285
00:20:03,653 --> 00:20:05,423
And this is called like Xin Horizon.

286
00:20:06,263 --> 00:20:10,133
Xmen is because I remember you can select Xin from a table.

287
00:20:10,463 --> 00:20:12,173
There is always such column there.

288
00:20:13,163 --> 00:20:20,423
Our listeners who listened first episodes, not I, I I, I like this like hidden columns, Sy Xim x, Maxs i d.

289
00:20:20,903 --> 00:20:23,303
So Xim Xmen is like birthdate.

290
00:20:23,768 --> 00:20:31,961
In terms of transaction id, you can uh, see when each tuple physical row version was created in which transaction.

291
00:20:32,291 --> 00:20:40,811
So we have multiple transactions and the oldest one is our Xmen Horizon, and this is reported to primary.

292
00:20:41,051 --> 00:20:45,791
So primary auto working, all working workers on primary respect.

293
00:20:46,646 --> 00:20:51,236
And don't delete the tules because they are considered still needed on some replicas.

294
00:20:51,806 --> 00:20:59,096
And imagine if you do it some, you run some query on some node with hot, hot turned on for many hours.

295
00:20:59,586 --> 00:21:02,336
It'll lead to auto vacuum.

296
00:21:02,336 --> 00:21:05,846
Unable to delete the tules in all tables on the printer.

297
00:21:05,906 --> 00:21:06,506
All tables.

298
00:21:06,506 --> 00:21:11,232
It's like cluster white problem, So we will eventually.

299
00:21:13,257 --> 00:21:17,667
Later, transaction finished, vacuum deleted, and we have gaps.

300
00:21:17,667 --> 00:21:18,297
Gaps is blo.

301
00:21:19,107 --> 00:21:30,717
Blood should be distinguished from dead tuple, but tuple accumulation of large volumes of lead to blo, and that's not good affecting both table and indexes health.

302
00:21:31,317 --> 00:21:36,027
So constant back feedback on is bad, off is bad.

303
00:21:36,177 --> 00:21:37,597
Choose what you prefer.

304
00:21:38,247 --> 00:21:40,570
So I prefer my idea.

305
00:21:41,304 --> 00:21:43,124
Two other options.

306
00:21:43,846 --> 00:21:46,786
Both are good, but both are difficult to implement.

307
00:21:47,236 --> 00:21:49,846
First is don't use Postgres for analytical queries.

308
00:21:51,886 --> 00:21:57,240
use logical decoding, logical replication to other systems like click House or Snowflake.

309
00:21:57,240 --> 00:21:57,670
Anything.

310
00:21:57,680 --> 00:22:02,380
This is what second, but of course it means like, it's easy to say, but, but.

311
00:22:03,075 --> 00:22:07,353
It, it's a lot of new expertise required and a lot of main maintenance efforts.

312
00:22:07,593 --> 00:22:11,417
Of course, it's easier to create physical standby and work from there.

313
00:22:12,077 --> 00:22:23,221
Second option is to have again, branching or database lab engine and provisions uh, clone or from branch and new one just released branching last week.

314
00:22:23,221 --> 00:22:24,811
By the way, I'm super excited.

315
00:22:24,811 --> 00:22:25,951
This should be.

316
00:22:26,656 --> 00:22:44,260
Branching is super powerful and it's, it's, I'm most excited about capabilities for development environments for like non-production environments, but for
production environments, it's also good, like you have specialized replika, and when you provision branched or cloned pos it doesn't report to a primary at all.

317
00:22:44,795 --> 00:22:46,895
You can do, like you, you have frozen state.

318
00:22:46,895 --> 00:22:51,815
Of course you, you're not receiving fresh changes, but you can do whatever you want.

319
00:22:51,815 --> 00:22:55,895
Like you are already detached from, from anyone.

320
00:22:56,225 --> 00:22:59,825
So you cannot be a problem for others, it's good.

321
00:23:00,635 --> 00:23:04,055
Well, of, of course you can have a logical replication.

322
00:23:04,115 --> 00:23:06,795
It doesn't report about Xmen Horizon to the primary.

323
00:23:06,819 --> 00:23:11,728
But there are, it reports about It learns about system catalog changes.

324
00:23:11,818 --> 00:23:16,948
So if some DDL is happening, there will be a problem, which is problem in general in logical.

325
00:23:17,406 --> 00:23:22,224
So,  easy options above bad difficult options are above good , right?

326
00:23:22,434 --> 00:23:23,744
But you need the additional.

327
00:23:25,534 --> 00:23:28,294
You know, you know, in additional tools for it.

328
00:23:28,954 --> 00:23:33,699
So that's, that probably covers physical basically just use streaming.

329
00:23:33,759 --> 00:23:35,199
It's good, reliable.

330
00:23:35,589 --> 00:23:48,732
You use wall ship replicas for standby notes for cases when you have, like, for example, you want to provision and keep it up to date, some environment where you do experiments, for example.

331
00:23:49,572 --> 00:23:53,210
Like it can, it can be based on wall shipping from archive.

332
00:23:53,210 --> 00:23:57,830
I prefer to not to touch the primary less often, and that's it.

333
00:23:57,920 --> 00:23:59,240
So physical is reliable.

334
00:23:59,245 --> 00:24:00,590
Battle proven everywhere.

335
00:24:00,590 --> 00:24:01,190
It's working.

336
00:24:01,190 --> 00:24:01,550
It's good.

337
00:24:02,257 --> 00:24:03,067
Michael: How about logical?

338
00:24:03,442 --> 00:24:08,782
Nikolay: Yeah, logical is good also, but it has a lot of limitations.

339
00:24:08,782 --> 00:24:10,852
First of all, in logical can be.

340
00:24:12,037 --> 00:24:17,833
In old-fashioned way, longest is still a tool to, to consider based on triggers or it can be used.

341
00:24:17,835 --> 00:24:20,235
What we have logical decoding and replication pauses.

342
00:24:20,235 --> 00:24:27,428
First of all like for developers, you should understand that logical is based on basically on on wall as well.

343
00:24:27,578 --> 00:24:30,848
On wall is, is recording tuple changes.

344
00:24:31,613 --> 00:24:34,913
This is new to pull, this is new whole page that changed and so on.

345
00:24:35,303 --> 00:24:38,683
Very low level changes and logical is based on that.

346
00:24:38,743 --> 00:24:43,243
So it's not purely logical, it's like logical deriv from physical, right?

347
00:24:43,663 --> 00:24:46,813
And this leads to many, many issues, actually.

348
00:24:47,503 --> 00:24:48,733
So many issues.

349
00:24:48,835 --> 00:24:49,865
But biggest.

350
00:24:49,873 --> 00:25:04,816
issues with logical that it, it lacks some things, but which currently under development, for example, DDL or replication of
sequences, there are, there is ongoing work, a lot of work and hackers which improves it and I mean, solves these problems.

351
00:25:05,371 --> 00:25:12,184
So I'm quite positive that POG 16 will or 17 will be much better in terms of logical and recent Postgres versions.

352
00:25:12,594 --> 00:25:13,054
14 and 15.

353
00:25:13,444 --> 00:25:14,884
They also have improvements.

354
00:25:14,945 --> 00:25:26,135
We had on POG tv we had guest Tamid Cap who described logical replication improvements, but logical in general is needed when your destination should differ from the source.

355
00:25:26,465 --> 00:25:30,955
In logical replication terminology, they call the publisher and the s.

356
00:25:31,483 --> 00:25:35,424
. like primary standby terms converted to publisher subscriber here.

357
00:25:35,803 --> 00:25:39,463
So for example, you want different measure version, right?

358
00:25:39,973 --> 00:25:41,233
Michael: Yeah, so if we're doing an upgrade,

359
00:25:41,683 --> 00:25:44,923
Nikolay: or you want not hold database for example.

360
00:25:44,928 --> 00:25:49,663
You want only a couple of tables or it's different database system at all.

361
00:25:49,723 --> 00:25:51,313
Like click house.

362
00:25:51,744 --> 00:25:56,334
It's also possible based on logical decoding, logical deco idea is, is quite easy.

363
00:25:56,334 --> 00:25:58,755
Like let's Have logical application.

364
00:25:59,745 --> 00:26:11,810
And it'll like stream our changes wall records and we will consume wall records and def decide what to do with them, either ignore or how somehow process and  allow to consume.

365
00:26:12,260 --> 00:26:16,970
So there are plug-ins so-called, which define this logic on the publisher.

366
00:26:17,540 --> 00:26:22,970
And the problem, one of the biggest problems for logical for me, but it looks like practically it's not that big.

367
00:26:23,420 --> 00:26:24,350
So it's.

368
00:26:24,781 --> 00:26:25,651
Passing everything.

369
00:26:25,923 --> 00:26:30,179
So like you cannot, it's, it's both performance and scalability problem.

370
00:26:30,599 --> 00:26:37,139
It can be, it can lead to legs if you have complex records involved, like a lot, lot of columns involved and so on.

371
00:26:37,859 --> 00:26:48,025
And also if you add additional stream and you want to say, okay, these tables will be there and those tables will be here like,  and conquer.

372
00:26:48,325 --> 00:26:55,638
You won conquer because consumption of CPU from of wall sender on, on the publisher side will, will be this.

373
00:26:55,668 --> 00:27:02,868
Like, if it's, it was a hundred percent CPU of one core, now you will have two cores, both consuming a hundred percent.

374
00:27:03,108 --> 00:27:10,384
It's quite the problem, but I, I see that   it's, it hits at only at very under, very heavy.

375
00:27:10,997 --> 00:27:17,507
Not like you, you should go before you'll probably hit the problem on the recipient side.

376
00:27:17,507 --> 00:27:23,147
On the subscriber, for example, if you miss some index and want to replay changes, right?

377
00:27:23,417 --> 00:27:29,721
And also splitting to multiple streams makes more sense here because definitely you can.

378
00:27:30,356 --> 00:27:36,875
We have multiple wall receivers and beckons replaying changes on the recipient side, on the, on the subscriber.

379
00:27:37,015 --> 00:27:45,943
So I also, for those who design and want to think about how to use logical, I wanted to highlight about one interesting point.

380
00:27:46,063 --> 00:27:49,873
We can distinguish two big areas of use cases.

381
00:27:50,173 --> 00:27:52,903
First is when we need all tables in po.

382
00:27:54,313 --> 00:27:57,433
It can be different major version of S but still we need all of them.

383
00:27:57,973 --> 00:28:03,895
And second everything else, like we need only partially our database or it's not positives at all.

384
00:28:04,585 --> 00:28:10,265
So in the first case, I forgot to mention how we need to start with logical.

385
00:28:10,505 --> 00:28:13,755
First, we need to take a copy of database, maybe partially.

386
00:28:13,785 --> 00:28:17,475
And then second phase we stream changes.

387
00:28:17,487 --> 00:28:18,979
It's called CDC change data.

388
00:28:19,947 --> 00:28:23,877
. So there are two phases, initialization and already working state.

389
00:28:24,687 --> 00:28:31,907
And the great news, which is not covered in documentation, that you can switch from physical to logical very easily.

390
00:28:32,927 --> 00:28:40,947
So you just have physical standby and then you create replication slot, logical replication slot on the primary.

391
00:28:40,959 --> 00:28:43,513
It'll provide you LSN while it post.

392
00:28:43,543 --> 00:28:45,403
So this is a po a point.

393
00:28:45,924 --> 00:28:46,794
it was created.

394
00:28:47,064 --> 00:28:52,614
And we know that it's like the state is at this Ls, n ls, N is, it's like log sequence number.

395
00:28:52,614 --> 00:28:57,735
It's the sequentially increasing number in, in, in the wall.

396
00:28:58,262 --> 00:29:05,241
And then you can say recovery target LSN to reach the same LSN on the standby.

397
00:29:06,281 --> 00:29:06,611
Right?

398
00:29:06,851 --> 00:29:10,451
And then you just switch to logical from physical replication.

399
00:29:11,516 --> 00:29:13,946
So it'll, it'll take a few seconds someday.

400
00:29:14,486 --> 00:29:20,460
So you can have 10 terabyte database and traditional logical in the couple, like from physical, physical.

401
00:29:20,460 --> 00:29:25,650
It is easy, like it's already very well known how to do it, but if you want.

402
00:29:26,100 --> 00:29:27,060
Whole database.

403
00:29:27,090 --> 00:29:28,560
You can do this trick.

404
00:29:29,040 --> 00:29:31,840
And super, super cool to, to provision logical.

405
00:29:31,840 --> 00:29:34,807
And this opens the path to various experiments.

406
00:29:34,807 --> 00:29:41,677
For example, if you want to use logical for various migrations to different positive measure version or,

407
00:29:41,902 --> 00:29:42,472
Michael: Yeah,

408
00:29:43,117 --> 00:29:50,117
Nikolay: or something like fight with blood, I don't know, like change personal system, something like that.

409
00:29:50,782 --> 00:29:53,452
Michael: that sounds super interesting for major version upgrades.

410
00:29:53,452 --> 00:29:55,462
So physical replication.

411
00:29:56,497 --> 00:29:58,267
Then could we do a, an upgrade?

412
00:29:58,297 --> 00:30:04,375
Like then we, can we do the, the PG upgrade and then turn on l logical replication to catch up?

413
00:30:04,750 --> 00:30:05,290
Nikolay: Exactly.

414
00:30:05,290 --> 00:30:12,874
So you do this trick and from physical, you convert physical node to logical node and then you can stop it, upgrade it.

415
00:30:13,653 --> 00:30:17,354
During this time, the primary will accumulate changes in the slot.

416
00:30:17,684 --> 00:30:21,649
So once you are up again you will consume and catch up.

417
00:30:22,189 --> 00:30:22,879
That's it.

418
00:30:23,834 --> 00:30:23,839
Yeah.

419
00:30:24,469 --> 00:30:29,209
Super . So I don't know why people don't use it often.

420
00:30:29,239 --> 00:30:34,339
It's like, it's, I I would say this is secret of how it's called Secret of pollution.

421
00:30:34,759 --> 00:30:34,769
Right?

422
00:30:35,089 --> 00:30:36,889
Like very well known secret actually.

423
00:30:36,889 --> 00:30:41,239
Like many people know it, but it's somehow keeping, it's not in the com.

424
00:30:41,329 --> 00:30:47,360
Maybe it should be covered in documentation actually, but documentation is in general likes how to.

425
00:30:48,208 --> 00:30:53,068
it's, it's very occasional to see, to, to see how to parts in documentation current form.

426
00:30:53,548 --> 00:30:56,338
So that being said, recommendation is awesome.

427
00:30:56,428 --> 00:30:56,848
Definitely.

428
00:30:57,238 --> 00:31:01,246
So, and if you need part of it, of course it's, it won't work.

429
00:31:01,426 --> 00:31:02,206
You can't do it.

430
00:31:02,206 --> 00:31:07,216
For example, I won't half a database, I do this trick and then I will drop half of the can work.

431
00:31:07,838 --> 00:31:09,153
But in other cases,

432
00:31:10,190 --> 00:31:10,892
Michael: That's awesome.

433
00:31:11,118 --> 00:31:21,301
I was wondering about two last things we, depending on which one you wanted to cover, either go into a
bit more detail on any of the issues on the, the lodge gratification side or potentially more interesting.

434
00:31:21,391 --> 00:31:27,012
The, one of the questions included any specifics for managed service providers?

435
00:31:27,017 --> 00:31:31,143
So like  any limitations to be aware of in the popular ones like rds, Google

436
00:31:31,203 --> 00:31:33,213
Nikolay: There are limitations everywhere, of course.

437
00:31:33,213 --> 00:31:35,493
So how many nodes you can have.

438
00:31:35,499 --> 00:31:42,518
For example, many projects prefer having like 10 or 15 physical standbys and upload a lot of reads there.

439
00:31:42,818 --> 00:31:46,688
It's constant work for backend developers to find more.

440
00:31:47,123 --> 00:31:50,270
Queries that can se uh, transactions that can be offloaded.

441
00:31:50,960 --> 00:31:58,361
But in general, as I remember on rgs originally they distinguished two types of 10 buy and first one.

442
00:31:58,961 --> 00:32:02,464
Was regular pogs standby, and it, it was supported reads.

443
00:32:02,884 --> 00:32:06,574
And second was a checkbox, multi z, multi mult zone.

444
00:32:07,024 --> 00:32:10,570
It was a hidden standby based, not on POGS replication.

445
00:32:10,870 --> 00:32:12,751
It was before recent changes.

446
00:32:12,815 --> 00:32:14,080
And it was not visible.

447
00:32:14,260 --> 00:32:15,610
You couldn't use it.

448
00:32:15,700 --> 00:32:17,350
So it's like, just for ha.

449
00:32:18,040 --> 00:32:19,840
Now as I know, they support.

450
00:32:20,196 --> 00:32:29,753
,  they changed it I, I haven't looked recently, but I, I saw the news that now for this HR replica  red queries are also supported, which is good.

451
00:32:30,173 --> 00:32:36,727
So, but like in ideal world, of course we should have like we should have a share replica on other subject.

452
00:32:37,597 --> 00:32:40,297
But some people think we should have at least three.

453
00:32:41,242 --> 00:32:52,351
and don't care about  which like symmetric, symmetric schema, when all replicas can be used for failover and all, all replicas can receive reads.

454
00:32:52,926 --> 00:33:01,646
I actually prefer this schema symmetric because if you allocate specific note for ha well, Cassius problem.

455
00:33:02,096 --> 00:33:03,446
You need to warm up, right?

456
00:33:04,106 --> 00:33:08,306
For, for read queries, it's warm up automatically if you, if it's receiving read.

457
00:33:08,306 --> 00:33:11,756
So it's like kind of things to think about.

458
00:33:11,795 --> 00:33:13,609
Like I prefer this approach.

459
00:33:13,729 --> 00:33:16,009
Patoni actually is good for it as well.

460
00:33:16,159 --> 00:33:16,759
By the way.

461
00:33:16,783 --> 00:33:19,725
In Patoni there is a problem with logical slots.

462
00:33:19,785 --> 00:33:23,445
If a other physical follower happened, you don't have slots.

463
00:33:24,693 --> 00:33:25,563
Michael: Interesting.

464
00:33:25,728 --> 00:33:25,998
Nikolay: bad.

465
00:33:25,998 --> 00:33:30,034
And also logical, like unlike physical, physical can be cascaded.

466
00:33:30,064 --> 00:33:36,953
You can create interesting architectures, but for logical, it's always from primary, unfortunately for, from physical primary.

467
00:33:37,403 --> 00:33:44,368
And there are many, there, there are many discussions how to enable logical replication  from, uh, physical standbys.

468
00:33:44,368 --> 00:33:44,848
It would be great.

469
00:33:45,943 --> 00:33:50,294
, but like risks are mo shifted to, to standby, it's much better.

470
00:33:50,562 --> 00:33:52,787
But unfortunately it's not yet implemented.

471
00:33:53,177 --> 00:34:02,105
So if you have physical feller, you'll lose slots but there is some recipe and petro implemented and there is a talk from Kokosh.

472
00:34:02,690 --> 00:34:03,824
Which is Mr.

473
00:34:03,824 --> 00:34:04,334
Patro?

474
00:34:04,754 --> 00:34:09,554
You, can you, yeah, you can, you can listen to, there are many interesting details there.

475
00:34:09,559 --> 00:34:14,844
And actually on positive tv, Alexandro also presented the stock many interesting details.

476
00:34:14,904 --> 00:34:21,320
So it's like how to avoid full initialization for logical replicas.

477
00:34:21,660 --> 00:34:27,759
But for upgrades, we don't care about it because our replicas should live like many, some hours or a couple of days.

478
00:34:28,959 --> 00:34:29,289
Michael: Yeah,

479
00:34:29,579 --> 00:34:29,929
Nikolay: so,

480
00:34:29,979 --> 00:34:30,969
Michael: just tempera really.

481
00:34:30,969 --> 00:34:32,019
Nikolay: so we don't care about it.

482
00:34:32,019 --> 00:34:34,449
So there are many different use cases, a lot of them.

483
00:34:35,257 --> 00:34:35,737
Michael: Awesome.

484
00:34:36,397 --> 00:34:38,087
Was there anything else you wanted to cover?

485
00:34:38,662 --> 00:34:40,522
Nikolay: there are many things to cover.

486
00:34:40,552 --> 00:34:44,722
For example, physical standard behavior may be very different from.

487
00:34:45,082 --> 00:34:45,592
Primary.

488
00:34:45,979 --> 00:34:49,909
For example, if you have sub transactions, you might want to check my article about it.

489
00:34:50,179 --> 00:34:51,259
And the disaster.

490
00:34:51,289 --> 00:34:55,129
GitLab head, they, they also blog post about it.

491
00:34:55,339 --> 00:34:59,829
Very good article and it was quite difficult to troubleshoot so.

492
00:35:00,829 --> 00:35:04,429
the idea that we have the same everything.

493
00:35:04,699 --> 00:35:14,419
Well, yes, we have the same everything, but there are small details that can differ and if you have sub transactions and you should be prepared for growth, definitely worth checking that post.

494
00:35:14,895 --> 00:35:17,115
Cause physical can be different.

495
00:35:17,130 --> 00:35:18,300
can have different behavior.

496
00:35:18,747 --> 00:35:19,887
Michael: I'll definitely include it.

497
00:35:20,242 --> 00:35:28,698
Nikolay: So in general, summary is physical replication is very, very reliable and Postgres logical has issues, but it's people also use it.

498
00:35:28,991 --> 00:35:32,780
There are also derived  products like AWS has dms gcp.

499
00:35:32,840 --> 00:35:41,135
Google also provides something in this area to migrate pogo to pogo, different versions or from different database systems to pos.

500
00:35:41,135 --> 00:35:47,722
Also usually cloud providers provide logical replication connection, but no physical it's worth keeping in mind.

501
00:35:48,052 --> 00:35:50,091
So you can migrate out of them.

502
00:35:50,096 --> 00:35:51,021
Only using logical.

503
00:35:51,021 --> 00:35:55,161
So logical is, it should be an arsenal definitely for various kinds of tasks.

504
00:35:55,491 --> 00:36:01,518
And uh, uh, um, there are, there are products like I would mention a couple of them click former uh, at.

505
00:36:03,423 --> 00:36:05,913
Maybe I'm pronouncing it wrong.

506
00:36:05,963 --> 00:36:07,842
They have issues with duplicates.

507
00:36:07,842 --> 00:36:10,592
They implement I communicated with them many times.

508
00:36:10,695 --> 00:36:18,621
They just don't understand and don't bother, don't understand me because they, they create slot at SQL level.

509
00:36:18,621 --> 00:36:20,871
So they don't, they cannot synchronize it properly.

510
00:36:20,876 --> 00:36:22,531
So if a recipient.

511
00:36:23,026 --> 00:36:25,878
Database like Snowflake don't have unique keys.

512
00:36:25,938 --> 00:36:34,848
You will have duplicates if you need to when switching from initialization to CDC part, or there's also a newer company called Five Train.

513
00:36:35,658 --> 00:36:36,618
This is quite good.

514
00:36:36,618 --> 00:36:48,478
It's commercial company also works with on top of logical decoding and supports a lot of things, and it's very like SA cloud, cloud oriented.

515
00:36:49,218 --> 00:36:50,688
But, and, and I think.

516
00:36:51,273 --> 00:36:54,753
Pricing is also good, but it's sort of considering if you want to save time.

517
00:36:55,646 --> 00:36:56,006
Michael: Yep.

518
00:36:56,276 --> 00:36:59,166
And last, last thing on the car providers is that they do often have.

519
00:36:59,891 --> 00:37:03,909
That just like a checkbook where you can turn on high mult Right?

520
00:37:03,969 --> 00:37:14,124
So it's you don't need the physical replication for that if, if you'd use their own service, but normally costs double just as if you were paying for a replica, right?

521
00:37:14,229 --> 00:37:14,919
Nikolay: Right, right, right.

522
00:37:14,919 --> 00:37:23,272
But as, as I said, this is about rds, the checkbox doubled for price for primary, and you couldn't use for reads, but they changed it recently.

523
00:37:23,272 --> 00:37:24,112
Worth checking.

524
00:37:24,342 --> 00:37:26,212
The, the, there are recent changes.

525
00:37:26,422 --> 00:37:33,622
So you can, you can have the checkbox and still use every day this node for, so

526
00:37:33,907 --> 00:37:39,945
Michael: Cloud SQL is similar, I think in that you, you can just turn it on, but I'm not sure about the being able to use it for reads.

527
00:37:40,635 --> 00:37:40,875
Nikolay: Right.

528
00:37:41,415 --> 00:37:42,285
Okay, good.

529
00:37:42,942 --> 00:37:43,482
Michael: Nice one.

530
00:37:44,202 --> 00:37:45,462
Thank you so much, Nicola.

531
00:37:45,462 --> 00:37:46,263
That was awesome.

532
00:37:46,280 --> 00:37:49,362
Thanks for the suggestions for people that sent those in.

533
00:37:49,452 --> 00:37:50,742
And thanks everyone for listening.

534
00:37:51,327 --> 00:37:52,167
Nikolay: Thank you, Michael.

535
00:37:52,227 --> 00:37:52,887
See you next time.

536
00:37:53,697 --> 00:37:53,877
Bye.

537
00:37:54,522 --> 00:37:55,152
Michael: See you.

538
00:37:55,152 --> 00:37:55,362
Bye.