Search for:
Actian Ingres 12.0: Modernize Your Way – Trusted, Reliable, and Adaptable

Our trusted and reliable database delivers performance and flexibility, empowering customers to modernize at their own pace.

As the director of product management for Actian, I’m thrilled to share first-hand insights into the latest enhancements to Actian Ingres. This major release embodies our commitment to customer-driven innovation and reinforces our position as a trusted technology partner.

Actian Ingres 12.0 builds upon the core strengths that have made Ingres a go-to transactional database for decades. We’ve invested heavily in performance, security, and cloud-readiness to ensure it meets customers’ modernization needs.

 

Choice and Flexibility

This release is all about giving customers the power of choice. Whether you’re committed to on-premises deployments, ready to embrace the cloud, or are looking for a hybrid solution, Actian Ingres 12.0 adapts to your modernization strategy.

We have options for Lift/Shift to VM, containerization via Docker and Kubernetes, and plans for bring your own license (BYOL) on the AWS Marketplace. If customers want to take a phased approach, customers have several options. Customers can move first to Linux on-premises, then to virtual machines (VMs) in the cloud, and finally to containers. We’re here to help and want customers to know we have a cloud story to help them in their individual journey.

 

Core Enhancements

We understand that familiarity and reliability are crucial to our users. That’s why Actian Ingres 12.0 strengthens core capabilities alongside exciting new features. We’ve doubled down on investments in these areas to ensure that Ingres remains a database that delivers new and sustainable value; this commitment keeps it relevant for the long term.

Reliability and security are paramount for our customers. Ingres 12.0 strengthens our ability to prevent brute force and Denial of Service (Dos) cyber-attacks, and DBMS security for user privileges to better protect users, roles, and groups.

We’ve added User Defined Function (UDF) support for Python and Javascript, offering a powerful way to extend the functionality of a database or streamline processes.  The use of containers offers an isolated execution environment to keep the DBMS secure.

The X100 analytics engine attracts attention for its superior performance where users have seen significant performance gains for OLAP related activities through the use of X100 tables by emphasizing their speed and efficiency.

X100 Analytics Table

Most notably, we introduced table and schema cloning in this release. This translates into a huge savings for warehouse-oriented customers and eliminates overhead for storage and latency without data duplication. Imagine a simple SQL-based table clone command that can clone not just one, but many tables in a single executed statement, and opens new possibilities for future data sharing and analytics down the line.

Cloud Enablement

Cloud adoption can be complex, but we’re here to make the journey smooth. Migrations can be challenging, which is why we provide support every step of the way. Ingres 12.0 is more adaptive to meet current and emerging business challenges while helping customers who want to move to the cloud to do so at their own pace.

This release brings a long-awaited backup to cloud capability for Actian Ingres that appeals to most data protection strategies. For many organizations, the ability to backup and restore data as part of an off-site disaster recovery strategy is their first objective. This type of backup strengthens business continuity.

Users already deploy Ingres on Linux using Docker and leverage Kubernetes to simplify orchestration. With Ingres 12.0 we now support disaster recovery using IngresSync, a DR utility formerly only available through Professional Services. IngresSync allows users to set up a read-only standby server. Yet another reason to have more confidence stepping into the cloud knowing you can distribute workloads and have disaster recovery options.

 

Performance Matters

Our development team was granted 5 patents with an additional 3 currently pending. This is the type of innovation that helps to differentiate us in areas of performance optimization. These patents touched advances in User Defined Functions (UDFs), index optimization, and continued differentiation with the in-memory storage, tracking, and merging of changes stored in X100 Positional Delta Trees (PDT). This is a tremendous show of passion for perfection by our amazing developers.

We invested in additional performance testing and standardization on industry TPC-H, TPC-DS, and TPC-C benchmarks, making strides release over release, and even more so, when it comes to complex X100 queries. This release also introduces more patents. Our development team was busy submitting eight in total, with only a few yet to be granted. These types of investments uncover various edge cases and costing scenarios that we can improve so users of any workload type can benefit. Of course, mileage varies.

Customers also benefit from more efficient workload management tailored to their specific business needs. Workload Manager 2.0 offers the capability to establish priority-driven queues, enabling resources to be allocated based on predefined priorities and user roles. During peak workload periods, the system can intelligently handle incoming queries by prioritizing specific queues and users, guaranteeing that important tasks are handled promptly while upholding overall system performance and efficiency.

For example, if business leaders require immediate information for a quarterly report, their queries are prioritized accordingly. Conversely, in situations where real-time transactions are crucial, prioritization is adjusted to maintain system efficiency.

 

Modernize With Confidence

Modernizing applications can be daunting. OpenROAD, a database-centric rapid application development (RAD) tool for developing and deploying business apps, continues to make this process easier with improvements to abf2or and WebGen utilities shipped with the product.

Empowering customers to transform their apps and up-level them for the web and mobile helps them stay current in a rapidly evolving developer space. This area of work can be the most challenging of all but having the ability to convert “green screen” applications to OpenROAD, and then on to web/mobile is a great starting point.

OpenROAD users can expect to see a new gRPC-based architecture for the OpenROAD Server. This architecture helps to reduce administration, enhance concurrency support, and is more lightweight because of its use of HTTP/2 and protocol buffers. Our developers were excited to move forward with this project and see it as a big jump from COM/DCOM.

The new gRPC architecture is also microservices-friendly and able to be packaged into a separate container. Because of this, we’ve got our sights set on containerized deployment of the Server in the cloud. In the meantime, we’ve distributed Docker files with this release so that customers can do some discovery and exploration.

 

Driven by Customer Feedback

Actian Ingres 12.0 can help customers expand their data capabilities footprint, explore new use cases, and reach their modernization goals faster. We’ve focused on enabling customers to strategically grow their business using a trusted database that keeps pace with new and emerging business needs.

We want customer feedback as we continue to innovate. Many of the database enhancements are based on direct customer input. We talked with users across industries about what features and capabilities customers like, and what customers wanted to see added. Their feedback was incorporated into our product roadmap, which ensures that Ingres continues to meet their evolving requirements. Plus, with our commitment to best-in-class support and services, every customer can be assured that we’re here to help them, no matter where customers are on their modernization journey.

Ingres is more than just a database. It’s a trusted enabler to help customers become future-fit and innovate faster without barriers. Whether you’re up leveling your version to 12.0 for the new capabilities and improvements, migrating to the cloud, modernizing applications, or leveraging built-in X100 capabilities for real-time analytics against co-located transactional data, Ingres 12.0 has something for everyone.

Resources

The post Actian Ingres 12.0: Modernize Your Way – Trusted, Reliable, and Adaptable appeared first on Actian.


Read More
Author: Douglas Dailey

Actian Ingres Disaster Recovery

Most production Actian Ingres installations need some degree of disaster recovery (DR). Options range from shipping nightly database checkpoints to off-site storage locations to near real-time replication to a dedicated off-site DR site.   

Actian Ingres enterprise hybrid database that ships with built-in checkpoint and journal shipping features which provide the basic building blocks for constructing low-cost, efficient DR implementations. One such implementation is IngresSync, which utilizes Actian Ingres’ native checkpoint/journal shipping and incremental roll-forward capabilities to implement a cost-effective DR solution. 

ingressync

IngresSync works on the concept of source and target Actian Ingres installations. The source installation is the currently active production environment. The target, or multiple targets if needed,  kept current by an IngresSync job scheduled to execute on a user-defined interval. Each sync operation copies only journals created since the previous sync and applies those transactions to the targets. Checkpoints taken on the source node are automatically copied to and rolled forward on all targets.

Example

Suppose we have an environment where the production installation is hosted on node corp and we need to create two DR sites dreast and drwest.

The DR nodes each need:

  • An Ingres installation at the same version and patch level as corp
  • Passwordless SSH configured to and from the other nodes
  • Ingres/Net VNODE entries to the other nodes

DR nodes for Ingress

To configure this environment, we must first designate the source and target hosts and apply the latest source checkpoint to the targets.

ingresSync --source=corp --target=dreast,drwest --database=corpdb --iid=II --ckpsync --restart

source and target hosts for Ingress

The two target installations are now synched with the source, and the target databases are in incremental rollforward (INCR_RFP) state. This state allows journals to be applied incrementally to keep the targets in sync with the source. Incremental rollforward is performed by:

ingresSync --hosts=corp,dreast,drwest --database=corpdb --iid=II --jnlsync

When executed, this will close the current journal on the source, copy new journals to the targets, and roll forward those journals to the targets. The journal sync step should be configured to execute at regular intervals using the system scheduler, such as cron. Frequent execution results in minimal sync delay between the source and targets.

The target installations at dreast and drwest are now in sync with the source installation at corp. Should the corp environment experience a hardware or software failure, we can designate one of the target nodes as the new source and direct client connections to that node. In this case, we’ll designate drwest as the new source and dreast will remain as a target (DR site).

ingresSync --target=drwest --database=corpdb --iid=II --incremental_done

This takes the drwest corpdb database out of incremental rollforward mode; the database will now execute both read and update transactions and is the new source. The dreast database is still in incremental rollforward mode and will continue to functioning as a DR target node.

drwest for ingress

Since the corp node is no longer available, the journal sync job must be started on either drwest or dreast. The journal sync job can be configured and scheduled to execute on all three nodes using the –strict flag. In this case, the job determines if it executes on the current source node; if so it will execute normally. If executing on a target, the job will simply terminate. This configuration allows synchronization to continue even as node roles change.

Once corp is back online it can be brought back into the configuration as a DR target.

ingresSync --source=drwest --target=corp --database=corpdb --iid=II --ckpsync --restart

dr target for Ingress

At some point, we may need to revert to the original configuration with corp as the source. The steps are:

  • Terminate all database connections to drwest
  • Sync

    corp

     with

    drwest

     to ensure

    corp

     is current
    ingresSync --source=drwest --target=corp --database=corpdb --iid=II
    
    --jnlsync
  • Reassign node roles
    
    ingresSync --target=corp --database=corpdb --iid=II --incremental_done
    
    ingresSync --source=corp --target=drwest --database=corpdb --iid=II
    
    --ckpsync --restart

revert to original corp as source for Ingress

Summary

IngresSync is one mechanism for implementing a DR solution. It is generally appropriate in cases where some degree of delay is acceptable and the target installations have little or no database user activity. Target databases can be used for read only/reporting applications with the stipulation that incremental rollforwards cannot run while there are active database connections. The rollforward process will catch up on the first refresh cycle when there are no active database connections.

The main pros and cons of the alternative methods of delivering disaster recovery for Actian Ingres are outlined below:

Feature Checkpoint Shipping IngresSync Replication
Scope Database Database Table
Granularity Database Journal Transaction
Sync Frequency Checkpoint User Defined Transaction
Target Database Read/Write(1) Read Only Read/Write(2)

 

  1. Target database supports read and write operations but all changes are lost on the next checkpoint refresh.
  2. Target database supports read and write operations but there may be update conflicts that require manual resolution.

Note: IngresSync currently runs on Linux and Microsoft Windows. Windows environments require the base Cygwin package and rsync.

The post Actian Ingres Disaster Recovery appeared first on Actian.


Read More
Author: Emma McGrattan