File: README — Documentation for slubydoo (0.0.4.1)

Notes

SLUBYDOO is a feature set that allows you to work with slony - ruby - postgresql. Slubydoo is not just an API. With Slubydoo you can use migrations to manipulate your database and still use slony for replication. You may be able to get by using Slubydoo with a minimal knowledge of slony. However, I advise you to read up on Slony to see if it truly is a fit for your database schema. Slony is trigger based, so Slubydoo is intended to work with slonys strengths while insulating from finer details. I currently use Slubydoo with Ruby On Rails ActiveRecord, however it is easy to change a couple lines and you are off and running with another ORM.

Yaml Configurations

The principal to recognize first of all is that slony is highly configurable. I have attempted to create a highly configurable feature set that is adaptable to your configurations and choices. There are two configuration files slony_nodes.yml and slony_paths.yml. Here is where you put your database connection information, remote machine connection information and file system path information. Slubydoo will run off of your configurations.

The application_configuration gem is required and allows you to set these configs to your specific systems.

In your application_configuration.yml file add a param db_slony_replication_status to true or false. Then in your app you can refer to this variable as app_config.db_slony_replication_status. This allows you to switch replication on or off which can be useful in development and test modes.

Example app_config/slubydoo/slony_nodes.yml file:

nodes:

-
  node_name: master1
  node_id: 1
  node_schema: public
  node_cluster_name: slony_cluster
  node_host: 127.0.0.1
  node_database_name: master
  node_username: foo
  node_password: password
  node_port: 5432
  node_adapter: postgresql
  node_encoding: unicode
  node_type: master
  node_system_username: foo
  node_system_password: password
  node_slonik_cmd_path: "/usr/local/pgsql/bin/slonik"
  node_slon_cmd_path: "/usr/local/pgsql/bin/slon"
-
  node_name: slave2
  node_id: 2
  node_schema: public
  node_cluster_name: slony_cluster
  node_host: 127.0.0.0
  node_database_name: slave
  node_username: foo
  node_password: password
  node_port: 5432
  node_adapter: postgresql
  node_encoding: unicode
  node_type: slave
  node_system_username: foo
  node_system_password: password
  node_slonik_cmd_path: "/usr/bin/slonik"
  node_slon_cmd_path: "/usr/bin/slon"

Example app_config/slubydoo/slony_paths.yml file:

slubydoo_initialize_yaml_dir_path: “/lib/slubydoo/sluby_snacks/” slubydoo_config_dir_path: “/config/app_config/slubydoo/” slubydoo_node_file_name: “slony_nodes.yml” slubydoo_tables_file_name: “slon_tables.yml” slubydoo_sequences_file_name: “slon_sequences.yml” slubydoo_sets_file_name: “slon_sets.yml” slubydoo_execute_dir_path: “/tmp/” slubydoo_log_file_path: “/tmp/foo.log” slubydoo_slonik_dir_path: “/tmp/” slubydoo_delete_files_on_remote_hosts: false slubydoo_refine_table_search_terms: “” slubydoo_sleep_time: 40 slubydoo_master_slave_process_conditions: “-d 1 -s 20000 -g 50 -t 60000”

Make sure all these paths exist and in the same path locations on both your master and slave databases.

Other Useful Intel

For legacy tables, you have several choices with slubydoo. You can create yaml files according to my specifications (See SlonySet) and slubydoo will create slony sets and tables based on these yamls of your design. This will allow you to design your slony sets according to your databases foreign keys and relationships. The other choice is to automaticaly create one set for each table that has a primary key (default). Slubydoo will search your database catalog and determine the tables with primary keys and which ones have sequences. It’s your choice. There is nothing stopping you from altering it further if you like a different approach. If you want the magic push one button approach where you don’t have to configure anything, slony is NOT for you and neither is slubydoo.

Make sure that you can ssh from the application servers directly to the database machines with just a username, password and hostaddress. Also that you can ssh from the master db to the slave db and vice versa.

I have put sql and connection specific information in the SlonyPreset class. That way you only have to change this file if you want to switch from postgresql specific sql or from ActiveRecord methods for example.

Rake Tasks

rake slubydoo:replication_start Where to begin. This will create slony sets based on either your yaml configs or your current schema (default). It will include tables with primary keys only. If you want to include tables without primary keys you can’t use slony. I put these rake tasks in my app, but you could uncomment them and use them here if you want.

Migrations

See the RDocumentation on how to use slubydoo with migrations. This works nicely and is pretty much the entire reason of why I built this functionality.

#replicate_nodes(rep_action, options = {}) {|if block_given?| …} #basically runs the same migration code on more than one database you wrap your migrations like this: #self.up # replicate_nodes(:alter_table, :rep_table => :table1) do # add_column :table1, :column2, :integer # end #end

Recommendations

Browse through the Slubydoo RDocumentation after reading this.