← Back to branch summary

~ubuntu-branches/ubuntu/oneiric/postgresql-9.1/oneiric-security

« back to all changes in this revision

Viewing changes to doc/src/sgml/html/different-replication-solutions.html

  • Committer: Bazaar Package Importer
  • Author(s): Martin Pitt
  • Date: 2011-05-11 10:41:53 UTC
  • Revision ID: james.westby@ubuntu.com-20110511104153-psbh2o58553fv1m0
Tags: upstream-9.1~beta1
Import upstream version 9.1~beta1

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/src/sgml/html/different-replication-solutions.html
 
1
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
 
2
<HTML
 
3
><HEAD
 
4
><TITLE
 
5
>Comparison of Different Solutions</TITLE
 
6
><META
 
7
NAME="GENERATOR"
 
8
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
 
9
REV="MADE"
 
10
HREF="mailto:pgsql-docs@postgresql.org"><LINK
 
11
REL="HOME"
 
12
TITLE="PostgreSQL 9.1beta1 Documentation"
 
13
HREF="index.html"><LINK
 
14
REL="UP"
 
15
TITLE="High Availability, Load Balancing, and Replication"
 
16
HREF="high-availability.html"><LINK
 
17
REL="PREVIOUS"
 
18
TITLE="High Availability, Load Balancing, and Replication"
 
19
HREF="high-availability.html"><LINK
 
20
REL="NEXT"
 
21
TITLE="Log-Shipping Standby Servers"
 
22
HREF="warm-standby.html"><LINK
 
23
REL="STYLESHEET"
 
24
TYPE="text/css"
 
25
HREF="stylesheet.css"><META
 
26
HTTP-EQUIV="Content-Type"
 
27
CONTENT="text/html; charset=ISO-8859-1"><META
 
28
NAME="creation"
 
29
CONTENT="2011-04-27T21:20:33"></HEAD
 
30
><BODY
 
31
CLASS="SECT1"
 
32
><DIV
 
33
CLASS="NAVHEADER"
 
34
><TABLE
 
35
SUMMARY="Header navigation table"
 
36
WIDTH="100%"
 
37
BORDER="0"
 
38
CELLPADDING="0"
 
39
CELLSPACING="0"
 
40
><TR
 
41
><TH
 
42
COLSPAN="5"
 
43
ALIGN="center"
 
44
VALIGN="bottom"
 
45
><A
 
46
HREF="index.html"
 
47
>PostgreSQL 9.1beta1 Documentation</A
 
48
></TH
 
49
></TR
 
50
><TR
 
51
><TD
 
52
WIDTH="10%"
 
53
ALIGN="left"
 
54
VALIGN="top"
 
55
><A
 
56
TITLE="High Availability, Load Balancing, and Replication"
 
57
HREF="high-availability.html"
 
58
ACCESSKEY="P"
 
59
>Prev</A
 
60
></TD
 
61
><TD
 
62
WIDTH="10%"
 
63
ALIGN="left"
 
64
VALIGN="top"
 
65
><A
 
66
TITLE="High Availability, Load Balancing, and Replication"
 
67
HREF="high-availability.html"
 
68
>Fast Backward</A
 
69
></TD
 
70
><TD
 
71
WIDTH="60%"
 
72
ALIGN="center"
 
73
VALIGN="bottom"
 
74
>Chapter 25. High Availability, Load Balancing, and Replication</TD
 
75
><TD
 
76
WIDTH="10%"
 
77
ALIGN="right"
 
78
VALIGN="top"
 
79
><A
 
80
TITLE="High Availability, Load Balancing, and Replication"
 
81
HREF="high-availability.html"
 
82
>Fast Forward</A
 
83
></TD
 
84
><TD
 
85
WIDTH="10%"
 
86
ALIGN="right"
 
87
VALIGN="top"
 
88
><A
 
89
TITLE="Log-Shipping Standby Servers"
 
90
HREF="warm-standby.html"
 
91
ACCESSKEY="N"
 
92
>Next</A
 
93
></TD
 
94
></TR
 
95
></TABLE
 
96
><HR
 
97
ALIGN="LEFT"
 
98
WIDTH="100%"></DIV
 
99
><DIV
 
100
CLASS="SECT1"
 
101
><H1
 
102
CLASS="SECT1"
 
103
><A
 
104
NAME="DIFFERENT-REPLICATION-SOLUTIONS"
 
105
>25.1. Comparison of Different Solutions</A
 
106
></H1
 
107
><P
 
108
></P
 
109
><DIV
 
110
CLASS="VARIABLELIST"
 
111
><DL
 
112
><DT
 
113
>Shared Disk Failover</DT
 
114
><DD
 
115
><P
 
116
>     Shared disk failover avoids synchronization overhead by having only one
 
117
     copy of the database.  It uses a single disk array that is shared by
 
118
     multiple servers.  If the main database server fails, the standby server
 
119
     is able to mount and start the database as though it were recovering from
 
120
     a database crash.  This allows rapid failover with no data loss.
 
121
    </P
 
122
><P
 
123
>     Shared hardware functionality is common in network storage devices.
 
124
     Using a network file system is also possible, though care must be
 
125
     taken that the file system has full <ACRONYM
 
126
CLASS="ACRONYM"
 
127
>POSIX</ACRONYM
 
128
> behavior (see <A
 
129
HREF="creating-cluster.html#CREATING-CLUSTER-NFS"
 
130
>Section 17.2.1</A
 
131
>).  One significant limitation of this
 
132
     method is that if the shared disk array fails or becomes corrupt, the
 
133
     primary and standby servers are both nonfunctional.  Another issue is
 
134
     that the standby server should never access the shared storage while
 
135
     the primary server is running.
 
136
    </P
 
137
></DD
 
138
><DT
 
139
>File System (Block-Device) Replication</DT
 
140
><DD
 
141
><P
 
142
>     A modified version of shared hardware functionality is file system
 
143
     replication, where all changes to a file system are mirrored to a file
 
144
     system residing on another computer.  The only restriction is that
 
145
     the mirroring must be done in a way that ensures the standby server
 
146
     has a consistent copy of the file system &mdash; specifically, writes
 
147
     to the standby must be done in the same order as those on the master.
 
148
     <SPAN
 
149
CLASS="PRODUCTNAME"
 
150
>DRBD</SPAN
 
151
> is a popular file system replication solution
 
152
     for Linux.
 
153
    </P
 
154
></DD
 
155
><DT
 
156
>Warm and Hot Standby Using Point-In-Time Recovery (<ACRONYM
 
157
CLASS="ACRONYM"
 
158
>PITR</ACRONYM
 
159
>)</DT
 
160
><DD
 
161
><P
 
162
>     Warm and hot standby servers can be kept current by reading a
 
163
     stream of write-ahead log (<ACRONYM
 
164
CLASS="ACRONYM"
 
165
>WAL</ACRONYM
 
166
>)
 
167
     records.  If the main server fails, the standby contains
 
168
     almost all of the data of the main server, and can be quickly
 
169
     made the new master database server.  This is asynchronous and
 
170
     can only be done for the entire database server.
 
171
    </P
 
172
><P
 
173
>     A PITR standby server can be implemented using file-based log shipping
 
174
     (<A
 
175
HREF="warm-standby.html"
 
176
>Section 25.2</A
 
177
>) or streaming replication (see
 
178
     <A
 
179
HREF="warm-standby.html#STREAMING-REPLICATION"
 
180
>Section 25.2.5</A
 
181
>), or a combination of both. For
 
182
     information on hot standby, see <A
 
183
HREF="hot-standby.html"
 
184
>Section 25.5</A
 
185
>.
 
186
    </P
 
187
></DD
 
188
><DT
 
189
>Trigger-Based Master-Standby Replication</DT
 
190
><DD
 
191
><P
 
192
>     A master-standby replication setup sends all data modification
 
193
     queries to the master server.  The master server asynchronously
 
194
     sends data changes to the standby server.  The standby can answer
 
195
     read-only queries while the master server is running.  The
 
196
     standby server is ideal for data warehouse queries.
 
197
    </P
 
198
><P
 
199
>     <SPAN
 
200
CLASS="PRODUCTNAME"
 
201
>Slony-I</SPAN
 
202
> is an example of this type of replication, with per-table
 
203
     granularity, and support for multiple standby servers.  Because it
 
204
     updates the standby server asynchronously (in batches), there is
 
205
     possible data loss during fail over.
 
206
    </P
 
207
></DD
 
208
><DT
 
209
>Statement-Based Replication Middleware</DT
 
210
><DD
 
211
><P
 
212
>     With statement-based replication middleware, a program intercepts
 
213
     every SQL query and sends it to one or all servers.  Each server
 
214
     operates independently.  Read-write queries are sent to all servers,
 
215
     while read-only queries can be sent to just one server, allowing
 
216
     the read workload to be distributed.
 
217
    </P
 
218
><P
 
219
>     If queries are simply broadcast unmodified, functions like
 
220
     <CODE
 
221
CLASS="FUNCTION"
 
222
>random()</CODE
 
223
>, <CODE
 
224
CLASS="FUNCTION"
 
225
>CURRENT_TIMESTAMP</CODE
 
226
>, and
 
227
     sequences can have different values on different servers.
 
228
     This is because each server operates independently, and because
 
229
     SQL queries are broadcast (and not actual modified rows).  If
 
230
     this is unacceptable, either the middleware or the application
 
231
     must query such values from a single server and then use those
 
232
     values in write queries.  Another option is to use this replication
 
233
     option with a traditional master-standby setup, i.e. data modification
 
234
     queries are sent only to the master and are propagated to the
 
235
     standby servers via master-standby replication, not by the replication
 
236
     middleware.  Care must also be taken that all
 
237
     transactions either commit or abort on all servers, perhaps
 
238
     using two-phase commit (<A
 
239
HREF="sql-prepare-transaction.html"
 
240
>PREPARE TRANSACTION</A
 
241
>
 
242
     and <A
 
243
HREF="sql-commit-prepared.html"
 
244
>COMMIT PREPARED</A
 
245
>.
 
246
     <SPAN
 
247
CLASS="PRODUCTNAME"
 
248
>Pgpool-II</SPAN
 
249
> and <SPAN
 
250
CLASS="PRODUCTNAME"
 
251
>Sequoia</SPAN
 
252
> are examples of
 
253
     this type of replication.
 
254
    </P
 
255
></DD
 
256
><DT
 
257
>Asynchronous Multimaster Replication</DT
 
258
><DD
 
259
><P
 
260
>     For servers that are not regularly connected, like laptops or
 
261
     remote servers, keeping data consistent among servers is a
 
262
     challenge.  Using asynchronous multimaster replication, each
 
263
     server works independently, and periodically communicates with
 
264
     the other servers to identify conflicting transactions.  The
 
265
     conflicts can be resolved by users or conflict resolution rules.
 
266
     Bucardo is an example of this type of replication.
 
267
    </P
 
268
></DD
 
269
><DT
 
270
>Synchronous Multimaster Replication</DT
 
271
><DD
 
272
><P
 
273
>     In synchronous multimaster replication, each server can accept
 
274
     write requests, and modified data is transmitted from the
 
275
     original server to every other server before each transaction
 
276
     commits.  Heavy write activity can cause excessive locking,
 
277
     leading to poor performance.  In fact, write performance is
 
278
     often worse than that of a single server.  Read requests can
 
279
     be sent to any server.  Some implementations use shared disk
 
280
     to reduce the communication overhead.  Synchronous multimaster
 
281
     replication is best for mostly read workloads, though its big
 
282
     advantage is that any server can accept write requests &mdash;
 
283
     there is no need to partition workloads between master and
 
284
     standby servers, and because the data changes are sent from one
 
285
     server to another, there is no problem with non-deterministic
 
286
     functions like <CODE
 
287
CLASS="FUNCTION"
 
288
>random()</CODE
 
289
>.
 
290
    </P
 
291
><P
 
292
>     <SPAN
 
293
CLASS="PRODUCTNAME"
 
294
>PostgreSQL</SPAN
 
295
> does not offer this type of replication,
 
296
     though <SPAN
 
297
CLASS="PRODUCTNAME"
 
298
>PostgreSQL</SPAN
 
299
> two-phase commit (<A
 
300
HREF="sql-prepare-transaction.html"
 
301
>PREPARE TRANSACTION</A
 
302
> and <A
 
303
HREF="sql-commit-prepared.html"
 
304
>COMMIT PREPARED</A
 
305
>)
 
306
     can be used to implement this in application code or middleware.
 
307
    </P
 
308
></DD
 
309
><DT
 
310
>Commercial Solutions</DT
 
311
><DD
 
312
><P
 
313
>     Because <SPAN
 
314
CLASS="PRODUCTNAME"
 
315
>PostgreSQL</SPAN
 
316
> is open source and easily
 
317
     extended, a number of companies have taken <SPAN
 
318
CLASS="PRODUCTNAME"
 
319
>PostgreSQL</SPAN
 
320
>
 
321
     and created commercial closed-source solutions with unique
 
322
     failover, replication, and load balancing capabilities.
 
323
    </P
 
324
></DD
 
325
></DL
 
326
></DIV
 
327
><P
 
328
>  <A
 
329
HREF="different-replication-solutions.html#HIGH-AVAILABILITY-MATRIX"
 
330
>Table 25-1</A
 
331
> summarizes
 
332
  the capabilities of the various solutions listed above.
 
333
 </P
 
334
><DIV
 
335
CLASS="TABLE"
 
336
><A
 
337
NAME="HIGH-AVAILABILITY-MATRIX"
 
338
></A
 
339
><P
 
340
><B
 
341
>Table 25-1. High Availability, Load Balancing, and Replication Feature Matrix</B
 
342
></P
 
343
><TABLE
 
344
BORDER="1"
 
345
CLASS="CALSTABLE"
 
346
><COL><COL><COL><COL><COL><COL><COL><COL><THEAD
 
347
><TR
 
348
><TH
 
349
>Feature</TH
 
350
><TH
 
351
>Shared Disk Failover</TH
 
352
><TH
 
353
>File System Replication</TH
 
354
><TH
 
355
>Hot/Warm Standby Using PITR</TH
 
356
><TH
 
357
>Trigger-Based Master-Standby Replication</TH
 
358
><TH
 
359
>Statement-Based Replication Middleware</TH
 
360
><TH
 
361
>Asynchronous Multimaster Replication</TH
 
362
><TH
 
363
>Synchronous Multimaster Replication</TH
 
364
></TR
 
365
></THEAD
 
366
><TBODY
 
367
><TR
 
368
><TD
 
369
>Most Common Implementation</TD
 
370
><TD
 
371
ALIGN="CENTER"
 
372
>NAS</TD
 
373
><TD
 
374
ALIGN="CENTER"
 
375
>DRBD</TD
 
376
><TD
 
377
ALIGN="CENTER"
 
378
>PITR</TD
 
379
><TD
 
380
ALIGN="CENTER"
 
381
>Slony</TD
 
382
><TD
 
383
ALIGN="CENTER"
 
384
>pgpool-II</TD
 
385
><TD
 
386
ALIGN="CENTER"
 
387
>Bucardo</TD
 
388
><TD
 
389
ALIGN="CENTER"
 
390
>&nbsp;</TD
 
391
></TR
 
392
><TR
 
393
><TD
 
394
>Communication Method</TD
 
395
><TD
 
396
ALIGN="CENTER"
 
397
>shared disk</TD
 
398
><TD
 
399
ALIGN="CENTER"
 
400
>disk blocks</TD
 
401
><TD
 
402
ALIGN="CENTER"
 
403
>WAL</TD
 
404
><TD
 
405
ALIGN="CENTER"
 
406
>table rows</TD
 
407
><TD
 
408
ALIGN="CENTER"
 
409
>SQL</TD
 
410
><TD
 
411
ALIGN="CENTER"
 
412
>table rows</TD
 
413
><TD
 
414
ALIGN="CENTER"
 
415
>table rows and row locks</TD
 
416
></TR
 
417
><TR
 
418
><TD
 
419
>No special hardware required</TD
 
420
><TD
 
421
ALIGN="CENTER"
 
422
>&nbsp;</TD
 
423
><TD
 
424
ALIGN="CENTER"
 
425
>&bull;</TD
 
426
><TD
 
427
ALIGN="CENTER"
 
428
>&bull;</TD
 
429
><TD
 
430
ALIGN="CENTER"
 
431
>&bull;</TD
 
432
><TD
 
433
ALIGN="CENTER"
 
434
>&bull;</TD
 
435
><TD
 
436
ALIGN="CENTER"
 
437
>&bull;</TD
 
438
><TD
 
439
ALIGN="CENTER"
 
440
>&bull;</TD
 
441
></TR
 
442
><TR
 
443
><TD
 
444
>Allows multiple master servers</TD
 
445
><TD
 
446
ALIGN="CENTER"
 
447
>&nbsp;</TD
 
448
><TD
 
449
ALIGN="CENTER"
 
450
>&nbsp;</TD
 
451
><TD
 
452
ALIGN="CENTER"
 
453
>&nbsp;</TD
 
454
><TD
 
455
ALIGN="CENTER"
 
456
>&nbsp;</TD
 
457
><TD
 
458
ALIGN="CENTER"
 
459
>&bull;</TD
 
460
><TD
 
461
ALIGN="CENTER"
 
462
>&bull;</TD
 
463
><TD
 
464
ALIGN="CENTER"
 
465
>&bull;</TD
 
466
></TR
 
467
><TR
 
468
><TD
 
469
>No master server overhead</TD
 
470
><TD
 
471
ALIGN="CENTER"
 
472
>&bull;</TD
 
473
><TD
 
474
ALIGN="CENTER"
 
475
>&nbsp;</TD
 
476
><TD
 
477
ALIGN="CENTER"
 
478
>&bull;</TD
 
479
><TD
 
480
ALIGN="CENTER"
 
481
>&nbsp;</TD
 
482
><TD
 
483
ALIGN="CENTER"
 
484
>&bull;</TD
 
485
><TD
 
486
ALIGN="CENTER"
 
487
>&nbsp;</TD
 
488
><TD
 
489
ALIGN="CENTER"
 
490
>&nbsp;</TD
 
491
></TR
 
492
><TR
 
493
><TD
 
494
>No waiting for multiple servers</TD
 
495
><TD
 
496
ALIGN="CENTER"
 
497
>&bull;</TD
 
498
><TD
 
499
ALIGN="CENTER"
 
500
>&nbsp;</TD
 
501
><TD
 
502
ALIGN="CENTER"
 
503
>&bull;</TD
 
504
><TD
 
505
ALIGN="CENTER"
 
506
>&bull;</TD
 
507
><TD
 
508
ALIGN="CENTER"
 
509
>&nbsp;</TD
 
510
><TD
 
511
ALIGN="CENTER"
 
512
>&bull;</TD
 
513
><TD
 
514
ALIGN="CENTER"
 
515
>&nbsp;</TD
 
516
></TR
 
517
><TR
 
518
><TD
 
519
>Master failure will never lose data</TD
 
520
><TD
 
521
ALIGN="CENTER"
 
522
>&bull;</TD
 
523
><TD
 
524
ALIGN="CENTER"
 
525
>&bull;</TD
 
526
><TD
 
527
ALIGN="CENTER"
 
528
>&nbsp;</TD
 
529
><TD
 
530
ALIGN="CENTER"
 
531
>&nbsp;</TD
 
532
><TD
 
533
ALIGN="CENTER"
 
534
>&bull;</TD
 
535
><TD
 
536
ALIGN="CENTER"
 
537
>&nbsp;</TD
 
538
><TD
 
539
ALIGN="CENTER"
 
540
>&bull;</TD
 
541
></TR
 
542
><TR
 
543
><TD
 
544
>Standby accept read-only queries</TD
 
545
><TD
 
546
ALIGN="CENTER"
 
547
>&nbsp;</TD
 
548
><TD
 
549
ALIGN="CENTER"
 
550
>&nbsp;</TD
 
551
><TD
 
552
ALIGN="CENTER"
 
553
>Hot only</TD
 
554
><TD
 
555
ALIGN="CENTER"
 
556
>&bull;</TD
 
557
><TD
 
558
ALIGN="CENTER"
 
559
>&bull;</TD
 
560
><TD
 
561
ALIGN="CENTER"
 
562
>&bull;</TD
 
563
><TD
 
564
ALIGN="CENTER"
 
565
>&bull;</TD
 
566
></TR
 
567
><TR
 
568
><TD
 
569
>Per-table granularity</TD
 
570
><TD
 
571
ALIGN="CENTER"
 
572
>&nbsp;</TD
 
573
><TD
 
574
ALIGN="CENTER"
 
575
>&nbsp;</TD
 
576
><TD
 
577
ALIGN="CENTER"
 
578
>&nbsp;</TD
 
579
><TD
 
580
ALIGN="CENTER"
 
581
>&bull;</TD
 
582
><TD
 
583
ALIGN="CENTER"
 
584
>&nbsp;</TD
 
585
><TD
 
586
ALIGN="CENTER"
 
587
>&bull;</TD
 
588
><TD
 
589
ALIGN="CENTER"
 
590
>&bull;</TD
 
591
></TR
 
592
><TR
 
593
><TD
 
594
>No conflict resolution necessary</TD
 
595
><TD
 
596
ALIGN="CENTER"
 
597
>&bull;</TD
 
598
><TD
 
599
ALIGN="CENTER"
 
600
>&bull;</TD
 
601
><TD
 
602
ALIGN="CENTER"
 
603
>&bull;</TD
 
604
><TD
 
605
ALIGN="CENTER"
 
606
>&bull;</TD
 
607
><TD
 
608
ALIGN="CENTER"
 
609
>&nbsp;</TD
 
610
><TD
 
611
ALIGN="CENTER"
 
612
>&nbsp;</TD
 
613
><TD
 
614
ALIGN="CENTER"
 
615
>&bull;</TD
 
616
></TR
 
617
></TBODY
 
618
></TABLE
 
619
></DIV
 
620
><P
 
621
>  There are a few solutions that do not fit into the above categories:
 
622
 </P
 
623
><P
 
624
></P
 
625
><DIV
 
626
CLASS="VARIABLELIST"
 
627
><DL
 
628
><DT
 
629
>Data Partitioning</DT
 
630
><DD
 
631
><P
 
632
>     Data partitioning splits tables into data sets.  Each set can
 
633
     be modified by only one server.  For example, data can be
 
634
     partitioned by offices, e.g., London and Paris, with a server
 
635
     in each office.  If queries combining London and Paris data
 
636
     are necessary, an application can query both servers, or
 
637
     master/standby replication can be used to keep a read-only copy
 
638
     of the other office's data on each server.
 
639
    </P
 
640
></DD
 
641
><DT
 
642
>Multiple-Server Parallel Query Execution</DT
 
643
><DD
 
644
><P
 
645
>     Many of the above solutions allow multiple servers to handle multiple
 
646
     queries, but none allow a single query to use multiple servers to
 
647
     complete faster.  This solution allows multiple servers to work
 
648
     concurrently on a single query.  It is usually accomplished by
 
649
     splitting the data among servers and having each server execute its
 
650
     part of the query and return results to a central server where they
 
651
     are combined and returned to the user.  <SPAN
 
652
CLASS="PRODUCTNAME"
 
653
>Pgpool-II</SPAN
 
654
>
 
655
     has this capability.  Also, this can be implemented using the
 
656
     <SPAN
 
657
CLASS="PRODUCTNAME"
 
658
>PL/Proxy</SPAN
 
659
> tool set.
 
660
    </P
 
661
></DD
 
662
></DL
 
663
></DIV
 
664
></DIV
 
665
><DIV
 
666
CLASS="NAVFOOTER"
 
667
><HR
 
668
ALIGN="LEFT"
 
669
WIDTH="100%"><TABLE
 
670
SUMMARY="Footer navigation table"
 
671
WIDTH="100%"
 
672
BORDER="0"
 
673
CELLPADDING="0"
 
674
CELLSPACING="0"
 
675
><TR
 
676
><TD
 
677
WIDTH="33%"
 
678
ALIGN="left"
 
679
VALIGN="top"
 
680
><A
 
681
HREF="high-availability.html"
 
682
ACCESSKEY="P"
 
683
>Prev</A
 
684
></TD
 
685
><TD
 
686
WIDTH="34%"
 
687
ALIGN="center"
 
688
VALIGN="top"
 
689
><A
 
690
HREF="index.html"
 
691
ACCESSKEY="H"
 
692
>Home</A
 
693
></TD
 
694
><TD
 
695
WIDTH="33%"
 
696
ALIGN="right"
 
697
VALIGN="top"
 
698
><A
 
699
HREF="warm-standby.html"
 
700
ACCESSKEY="N"
 
701
>Next</A
 
702
></TD
 
703
></TR
 
704
><TR
 
705
><TD
 
706
WIDTH="33%"
 
707
ALIGN="left"
 
708
VALIGN="top"
 
709
>High Availability, Load Balancing, and Replication</TD
 
710
><TD
 
711
WIDTH="34%"
 
712
ALIGN="center"
 
713
VALIGN="top"
 
714
><A
 
715
HREF="high-availability.html"
 
716
ACCESSKEY="U"
 
717
>Up</A
 
718
></TD
 
719
><TD
 
720
WIDTH="33%"
 
721
ALIGN="right"
 
722
VALIGN="top"
 
723
>Log-Shipping Standby Servers</TD
 
724
></TR
 
725
></TABLE
 
726
></DIV
 
727
></BODY
 
728
></HTML
 
729
>
 
 
b'\\ No newline at end of file'