Transactional replication involves sending an initial full copy of the database to subscribers, followed by real-time updates as changes occur at the publisher.

• Changes are propagated in the same order as they happen, ensuring transactional consistency.
• It is ideal for server-to-server environments that require high accuracy and reliability.

Example: Banking systems or e-commerce sites that demand consistent and up-to-date transaction data.

Example: Banking systems or e-commerce sites that demand consistent and up-to-date transaction data.

Snapshot replication copies and distributes data exactly as it exists at a specific point in time, without tracking changes.

• It sends the entire dataset to subscribers periodically.
• Suitable for databases where data changes infrequently.

Drawback: Can be slower because it replicates the entire dataset each time.

Drawback: Can be slower because it replicates the entire dataset each time.

Merge replication allows both the publisher and subscriber to make changes independently.

• Changes are later merged into a single database.
• It is complex but useful in mobile or client-server environments, where users work offline and synchronize later.

Example: Field data collection systems or distributed applications where clients update data locally.

Example: Field data collection systems or distributed applications where clients update data locally.

In this architecture:

• One database server is designated as the master and
• One or more servers are designated as slaves.

Note: The master handles all write operations and the slaves receive read-only copies from the master. This model ensures data consistency and simplifies synchronization.

Note: The master handles all write operations and the slaves receive read-only copies from the master. This model ensures data consistency and simplifies synchronization.

All servers act as masters, meaning that updates can occur at any node and changes are replicated across all other nodes.

• Suitable for large distributed systems that require high availability and update flexibility.
• However, it requires conflict detection and resolution mechanisms.

Every server acts as both a master and a slave, with data replicated in a peer-to-peer manner.

• Commonly used in distributed databases where each node can handle both reads and writes.
• Ensures redundancy and high availability.

In this type, a single source database replicates data to multiple target databases.

• Ideal for centralized data control with distributed read access.
• Simplifies consistency but increases load on the source server.

In full replication, the entire database is replicated at every site. Offers maximum availability and faster local access. However, it increases storage requirements and update complexity.

Advantages:

• High data availability
• Faster query execution (local access)
• Improved performance for global queries

Disadvantages:

• Difficult concurrency management
• Slow update propagation
• High storage and network costs
• Complex consistency maintenance

In no replication, each data item is stored at only one location in the distributed system.

Advantages:

• Reduced concurrency issues
• Simplified recovery and management

Disadvantages:

• Poor data availability (single point of failure)
• Slower query response due to centralized access

In partial replication, only selected fragments of the database are replicated based on their importance or access frequency. Balances between storage efficiency and availability.

Advantages:

• Optimized storage
• Flexibility based on data importance
• Better performance for critical data

Disadvantages:

• Complex management and configuration
• Possible inconsistent data access across sites