Přehled variant databázové replikace (master-slave vs. master-master, physical vs. logical) a jejich pro a proti. Krátká historie replikace v PostgreSQL s přehled nástrojů které dnes máme k dispozici (slony-I, pgpool-II, Londiste a Bucardo). A nakonec stručné srovnání s replikací ve dvou populárních databázích (MySQL a Oracle).
This document demonstrates pgpool-II for replication and high availability of PostgreSQL databases. It shows:
1. A basic configuration with a master and standby node replicating over pgpool-II for online recovery and load balancing.
2. How pgpool-II can be configured for warm standby replication with automatic failover through scripting.
3. That pgpool-II allows scaling out additional database nodes without downtime and prevents single points of failure through multi-master replication across multiple pgpool instances.
PostgreSQL on EXT4, XFS, BTRFS and ZFSTomas Vondra
One of the most common question I'm asked by users and customer about configuring a Linux-based system for PostgreSQL is "What file fystem should I use to get the best performance?" Sadly, most of the recommendations is based on obsolete "common knowledge" passed from generation to generation. But in recent years the file systems improved a lot - we've seen both evolution of established file systems (EXT family, XFS, ...) and revolution in the form of BTRFS, ZFS or F2FS. And of course new kinds of hardware (SSDs) which certainly impacts the design of a file system.
PostgreSQL performance improvements in 9.5 and 9.6Tomas Vondra
The document summarizes performance improvements in PostgreSQL versions 9.5 and 9.6. Some key improvements discussed include optimizations to sorting, hash joins, BRIN indexes, parallel query processing, aggregate functions, checkpoints, and freezing. Performance tests on sorting, hash joins, and parallel queries show significant speedups from these changes, such as faster sorting times and better scalability with parallel queries.
Performance improvements in PostgreSQL 9.5 and beyondTomas Vondra
This document discusses several performance improvements made in PostgreSQL versions 9.5 and beyond. Some key improvements discussed include:
- Faster sorting through allowing sorting by inlined functions, abbreviated keys for VARCHAR/TEXT/NUMERIC, and Sort Support benefits.
- Improved hash joins through reduced palloc overhead, smaller NTUP_PER_BUCKET, and dynamically resizing the hash table.
- Index improvements like avoiding index tuple copying, GiST and bitmap index scan optimizations, and block range tracking in BRIN indexes.
- Aggregate functions see speedups through using 128-bit integers for internal state instead of NUMERIC in some cases.
- Other optimizations affect PL/pgSQL performance,
Přehled variant databázové replikace (master-slave vs. master-master, physical vs. logical) a jejich pro a proti. Krátká historie replikace v PostgreSQL s přehled nástrojů které dnes máme k dispozici (slony-I, pgpool-II, Londiste a Bucardo). A nakonec stručné srovnání s replikací ve dvou populárních databázích (MySQL a Oracle).
This document demonstrates pgpool-II for replication and high availability of PostgreSQL databases. It shows:
1. A basic configuration with a master and standby node replicating over pgpool-II for online recovery and load balancing.
2. How pgpool-II can be configured for warm standby replication with automatic failover through scripting.
3. That pgpool-II allows scaling out additional database nodes without downtime and prevents single points of failure through multi-master replication across multiple pgpool instances.
PostgreSQL on EXT4, XFS, BTRFS and ZFSTomas Vondra
One of the most common question I'm asked by users and customer about configuring a Linux-based system for PostgreSQL is "What file fystem should I use to get the best performance?" Sadly, most of the recommendations is based on obsolete "common knowledge" passed from generation to generation. But in recent years the file systems improved a lot - we've seen both evolution of established file systems (EXT family, XFS, ...) and revolution in the form of BTRFS, ZFS or F2FS. And of course new kinds of hardware (SSDs) which certainly impacts the design of a file system.
PostgreSQL performance improvements in 9.5 and 9.6Tomas Vondra
The document summarizes performance improvements in PostgreSQL versions 9.5 and 9.6. Some key improvements discussed include optimizations to sorting, hash joins, BRIN indexes, parallel query processing, aggregate functions, checkpoints, and freezing. Performance tests on sorting, hash joins, and parallel queries show significant speedups from these changes, such as faster sorting times and better scalability with parallel queries.
Performance improvements in PostgreSQL 9.5 and beyondTomas Vondra
This document discusses several performance improvements made in PostgreSQL versions 9.5 and beyond. Some key improvements discussed include:
- Faster sorting through allowing sorting by inlined functions, abbreviated keys for VARCHAR/TEXT/NUMERIC, and Sort Support benefits.
- Improved hash joins through reduced palloc overhead, smaller NTUP_PER_BUCKET, and dynamically resizing the hash table.
- Index improvements like avoiding index tuple copying, GiST and bitmap index scan optimizations, and block range tracking in BRIN indexes.
- Aggregate functions see speedups through using 128-bit integers for internal state instead of NUMERIC in some cases.
- Other optimizations affect PL/pgSQL performance,
Tipy pro administraci IBM Domino serveru.
Další informace pro adminy:
http://www.jaknalotus.cz
Nabídky školení a workshopů:
http://www.hansgut.cz/nabidka-sluzeb/
Workshop Administrace IBM Domino serveru
http://www.hansgut.cz/firemni-workshop-administrace-ibm-domino-serveru/
Workshop IBM Notes pro uživatele
http://www.hansgut.cz/firemni-workshop-ibm-notes/
Czech Sun Training Day 2008 - Java Enterprise SystemMartin Cerveny
Presentation from training day for Sun Solaris customers to explain features of Sun Java Enterprise System.
Presentation covers following themes:
- architecture
- Directory server
- Web server
- Access manager
- Portal server
Tipy pro administraci IBM Domino serveru.
Další informace pro adminy:
http://www.jaknalotus.cz
Nabídky školení a workshopů:
http://www.hansgut.cz/nabidka-sluzeb/
Workshop Administrace IBM Domino serveru
http://www.hansgut.cz/firemni-workshop-administrace-ibm-domino-serveru/
Workshop IBM Notes pro uživatele
http://www.hansgut.cz/firemni-workshop-ibm-notes/
Czech Sun Training Day 2008 - Java Enterprise SystemMartin Cerveny
Presentation from training day for Sun Solaris customers to explain features of Sun Java Enterprise System.
Presentation covers following themes:
- architecture
- Directory server
- Web server
- Access manager
- Portal server
3. Distribuovaná data
SELECT * FROM T T
SELECT * FROM T
SELECT * FROM T
SELECT * FROM T
4. Distribuovaná data - problém
SELECT * FROM T T
SELECT * FROM T
SELECT * FROM T
SELECT * FROM T
5. Replikace
T
T
T
SELECT * FROM T
SELECT * FROM T
6. Replikace
• replikace je technika zajišťování dostupnosti dat v distribuovaných
databázových systémech.
• data jsou fyzicky uložena v systému ve více kopiích (replikách) na
více místech (uzlech)
• k distribuovaným datům můžeme přistupovat lokálně
• při zachování určité míry konzistence
7. Replikační objekty
• co všechno můžeme replikovat:
▫ tabulky
▫ indexy
▫ pohledy
▫ balíky
▫ procedury, funkce
▫ typy
▫ triggery
▫ synonyma
▫ operátory
8. Jak replikovat
• nereplikovat
▫ triviální
• export import
▫ utiltity, CREATE TABLE AS SELECT
▫ bez dalších datových přenosů
▫ jednou a dost
• Oracle Dataguard
▫ neflexibilní
• zařídit replikaci sami
▫ procedurálně pomocí triggerů (PL/SQL)
▫ složité pro obecné situace
9. Database link
• potřebujeme komunikovat se vzdálenou databází
• spojení pomocí database linku
▫ jako client-server
• CREATE [PUBLIC] DATABASE LINK name
CONNECT TO user IDENTIFIED BY pass
USING ‘database‘
• tnsnames.ora
▫ $ORACLE_HOME/network/ADMIN
10. Typy replikací
• základní
▫ basic replication
▫ jen pro čtení
▫ data proudí jedním směrem
• pokročilá
▫ advanced replication
▫ přenos oběma směry
▫ Enterprise
11. Materializovaný pohled
• materialized view
• pohled ~ pohled na data ~ předkompilovaný optimalizovaný SQL
dotaz
• materializovaný pohled ~ pohled, který fyzicky obsahuje data
• dříve snapshot
• CREATE MATERIALIZED VIEW pohled AS SELECT …
12. Základní replikace
• můžeme replikovat jenom tabulky
▫ a to jako materializované pohledy
▫ read only materialized view
• slovník:
▫ zdrojová tabulka: target master table
▫ patří do databáze master definition site
▫ read-only mviews jsou v destination site
• replikované mviews musí mít identifikovatelné řádky
▫ primární klíč
▫ ROWID
13. Výhody replikovaných mviews
• nižší nároky na přenos dat
• lepší výkon (lokální data)
• data subsetting
• konzistence
14. Materialized view log
• proč?
▫ chceme mít v mview aktuální data
• zaznamenávají změny v datech, které jsou zajímavé pro mview
▫ na úrovni řádků
• přísluší master site
• CREATE MATERIALIZED VIEW LOG ON tabulka TABLESPACE ts
15. Aktualizace mview
• 3 metody:
▫ FAST
aktualizuje na úrovni řádků
potřebuje MV log
▫ COMPLETE
MV se kompletně vymaže znovu naplní
▫ FORCE
pokud to jde, provede se FAST, jinak COMPLETE
• CREATE MATERIALIZED VIEW mv
REFRESH FAST NEXT sysdate + 1 AS
…
16. Refresh group
• uvažme příklad:
▫ v master site máme tabulky zaměstnanec a plat, které replikujeme do
destination site
▫ MV se aktualizují každé 3 minuty
▫ v destination site chce někdo přiřadit platy zaměstnancům (JOIN)
není zaručeno, že se to povede (resp. může vzniknout zaměstnanec bez platu)
protože zaměstnanci můžou být aktuální a platy budou aktuální až za 2 minuty
to protože IO cizího klíče je jen v master site
• řešením jsou refresh groups
▫ pohledy v jedné skupině se aktualizují najednou
17. Příklad
dbadmin@semora remoteUser@semora client@everywhere
CREATE TABLE remoteTable (id INT PRIMARY KEY,zprava
VARCHAR2(255));
CREATE USER remoteUser IDENTIFIED BY remoteUser;
GRANT CREATE SESSION TO remoteUser;
GRANT CREATE SYNONYM TO remoteUser;
GRANT SELECT ON remoteTable TO remoteUser;
CREATE SYNONYM
remoteTable FOR
dbadmin.remoteTable;
CREATE PUBLIC DATABASE LINK semoraLink CONNECT TO
remoteUser IDENTIFIED BY remoteUser USING 'semora';
CREATE MATERIALIZED VIEW selectFromRemote AS SELECT * FROM
remoteTable@semoraLink
INSERT INTO remoteTable VALUES (1,'Hello, this is the
remote table');
COMMIT;
19. Replikační skupiny
• pokud máme replikovaných objektů více než málo, je obtížné je
individuálně spravovat
• používají se replikační skupiny (replication groups)
▫ sdružujeme objekty, které spolu logicky souvisí
• každý objekt patří do nejvýše jedné replikační skupiny
• objekty z replikační skupiny mohou patřit do různých schémat
20. Updatable materialized views
• jedna master tabulka podporuje neomezeně UMV
• protože je ! master tabulka, všechny konflikty se řeší v jednom
bodě systému
• nejsou tolik náročné na zdroje
• dají se použít společně s multimaster replikací
• CREATE MATERIALIZED VIEW view FOR UPDATE …
• a navíc přiřazením do replikační skupiny a registrací replikačního
objektu do katalogu
22. Writeable materialized view
• jsou to MV, do kterých je možné zapisovat (DML)
• ale změny se nepropagují směrem ven
• po refreshi se data ztratí
• vytváří se stejně jako updatable MV, ale nepřiřazují se do replikační
skupiny
23. Replikační katalog
• každý prvek zapojený do replikace má svůj replikační katalog
• sada pohledů a slovníků s informacemi o replikačních objektech a
skupinách
• používá se při provádění replikace
• procedury pro správu
▫ DBMS_REPCAT.CREATE_MASTER_REPGROUP
vytváří novou master group
24. Multimaster replikace
• peer-to-peer
• replikují se vždy všechna data
• více master-site v systému, které komunikují mezi sebou
• informace se aktualizují hned po dokončení transakce
▫ pokud je to možné
25. Multimaster replikace
• implementována procedurálně na úrovni triggerů
▫ generují se
▫ nepoužívají se MV
• umožňuje zároveň z dvou míst přistupovat (měnit) jeden záznam
▫ může dojít ke konfliktům
řeší se podle definovaných pravidel
26. Multimaster komunikace
• manipulace s daty neprobíhá
přímo
• akce se vloží do fronty Local DB Remtoe DB
odložených transakcí (deferred
transaction queue) Deferred Deferred
• odtud se šíří po replikační transaction transaction
skupině queue DB link queue
• pokud dojde k chybě (např. ztráta
připojení), transakce se přesune
do fronty chybových transakcí Table Table
(deferred error queue) A A
• replikace je pozastavena, dokud
chyba není opravena INSERT INTO A…
28. Konflikty
• u asynchronní multimaster replikace může dojít ke konfliktům (kolizím)
▫ můžeme zvolit i synchronní zpracování
• řeší se podle pravidel
▫ buď implicitní
▫ nebo uživatelsky definovaná
• např.
▫ latest timestamp value
▫ earliest timestamp value
▫ min/max value
▫ …
29. Reference
• Oracle documentation
• Jiří Vytasil; Conicov Andrej – Replikace
• John Garmany, Robert Freeman - Oracle Replication
RAMPANT TECHPRESS, 2003
• orafaq.com