text:
In the latest edition of the All-Access Podcast with Joe Tutino, the "Voice of the Galaxy" speaks to LA Galaxy Reserve League coach Curt Onalfo on U.S. Open Cup, Reserve League, and the Seattle Sounders.
Check it out below...
I'll be on Access SportsNet: Galaxy tonight with Chris McGee and former U.S. international Clint Mathis at 7 p.m.
Remember to send in your LA Galaxy, MLS, and U.S. National Team questions to myself and Mathis using the #GalaxyInsider hashtag. Also, you can leave a voice message on the new Galaxy line number: 626-7ML-SCUP
CARSON, Calif. – Mike Magee missed out on the LA Galaxy's 1-0 defeat to the New York Red Bulls due to a right ankle sprain, but the LA midfielder is hopeful of participating against Seattle Sounders FC on Sunday.
"I'm feeling good. I trained today. No issues, so I'm ready to go," Magee told reporters on Wednesday. "There was a play in the Philly game and I went to jump for a ball and I planted on [Philadelphia Union defender Sheanon] Williams foot first and I just rolled my ankle and we weren't able to control the swelling before the New York game...it was pretty good roll so I feel lucky that it wasn't worse."
Following training, LA head coach Bruce Arena reiterated Magee's optimism stating that he "was doing fine." If Magee is healthy, he'll be itching to take on the Sounders, who he describes as "dangerous as hell" due to their six game unbeaten streak.
"I think that from the day that they came into MLS, they wanted to call us out…I think that they said that we're the expansion team and made comments to like that. They always seem to compare themselves to our team," said Magee. "They've had a ton of success and they're a really hard to play against. Every game that we play against [one another] is a battle and you kind of get the feeling that it's a little more important than a regular league game."
CARSON, Calif. – Robbie Keane will be joining the Republic of Ireland for their friendlies against England on May 29 and Georgia on June 2 just a day after the Irish FA stated that he will not travel.
On Tuesday, LA Galaxy head coach Bruce Arena stressed that the Galaxy were eager to keep Keane through their June 2 match with the New England Revolution, but in light of an agreement between U.S. Soccer to release U.S. Internationals—like defender Omar Gonzalez— for their upcoming five matches in May and June, the club allowed Keane's release.
"In reflecting over it, if we're required to release U.S. players then how can we not allow other internationals to go? We're allowing U.S. players to play in friendlies, then it creates an awkward situation, but it's fair," said Arena. "In all fairness, it's the right thing to do. In reality, no player should be released: U.S. players or other internationals. We should adhere to FIFA rules.
"The league mandated that we release the players," Arena later added "If our U.S. internationals are going for friendlies then others should. We're on the same team here and it is not one rule for one and one for another."
Although Arena was quick to mention that he's not "losing any sleep at night" over the move, he admitted that coaches may not agree with the decision.
"I don't think coaches agree with that, but that is fine," said Arena. "We have some input, if we have issues, we try to articulate it. Sometimes, it's not heard, but that is fine."
The LA Galaxy may be traveling across the country to take on the Carolina Railhawks in the third round of the U.S. Open Cup on May 29, but if they defeat the Railhawks then they'll get to host their fourth round match at StubHub Center--possibly against Chivas USA.
U.S. Soccer announced on Wednesday that the LA Galaxy will host their fourth round match against the winner of the third round game between Chivas USA and USL Pro side Los Angeles Blues on June 12, provided they get past the Railhawks. The Rojiblancos will take on the Blues on May 28 at Titan Stadium in Fullerton.
If the Galaxy fall to the Railhawks, the winner of the match between Chivas and Blues will travel to North Carolina.
Robbie Keane is joining Ireland for their friendlies against England and Georgia after all.
The Republic of Ireland Football Association announced on Wednesday that Keane and the LA Galaxy had reached an agreement to allow him to join up with the Irish for their friendlies against England at Wembley Stadium on May 29 and Georgia on June 2 in Dublin. Ireland will then take on the Faroe Islands in a World Cup Qualifier on June 7 before closing the international period with a friendly against Spain on June 11 in New York.
"I would like to thank LA Galaxy for reconsidering their decision after further conversations between us which really means a lot to me," Keane said in a statement released by the Irish FA. "We have reached an agreement that will enable me to make it to the games and I look forward to playing my part."
Keane was scheduled to stay with the Galaxy through their June 2 match against the New England Revolution, but will now likely depart after LA's match against Seattle Sounders FC on Sunday.
What are your thoughts on the decision? Expect Ireland to knock off England and Georgia?
Share your thoughts below.
CARSON, Calif. – Much of the talk following the LA Galaxy's 1-0 defeat to the New York Red Bulls focused the defensive breakdown that led to the decisive goal in LA's defeat, but on Tuesday, goalkeeper Carlo Cudicini hit back at those criticisms.
"To be fair, I think this team is getting a lot of critique, a lot of comments about how we're doing," Cudicini said. "I think the defense is doing pretty well. Compare it to the previous two years and, for sure, we've improved. I don't really get all this critique I read and I hear on TV about this defense, really. I'm sorry."
Tim Cahill's goal in stoppage time was the sixth goal that the Galaxy have conceded in the last 15 minutes in 2013, but Cudicini is adamant that the notions of defensive breakdowns or the late goals, do not tell the whole story.
"I don't think they're fair, it's as easy as that," Cudicini said. "How can you critique a defense that is second defense in the league? Every time we concede a goal I read and I hear stuff on TV every time. I don't think it's fair. I don't read the same things when other teams concede goals. Why are we the only team where we have problems on defense?
"If you compare the defense to last year, we improved it and you compare to two years ago then we have the same shutouts and a couple of goals more [conceded] so I don't see the standard that we are not achieving at this moment. I'm talking about statistics, not my point of view, you love statistics, I'm bringing statistics to you."
The statistics back up Cudicini's argument as after 11 games, the Galaxy have conceded 10 goals and sit in a four-way tie with the Columbus Crew, Sporting Kansas City, and the Colorado Rapids for the title of second best defense in the league. However, LA and Columbus are likely to be given the edge as each team has played 11 games compared to 12 and 13 for Colorado and Sporting respectively. Meanwhile, LA has earned four shutouts to date.
The 2013 mark is an improvement from LA's 2012 numbers when LA failed to register a shutout while conceding 16 goals in their first 11 regular season games. In fact, LA's goals allowed numbers are nearly identical to the Galaxy's mark in 2011 when they conceded 11 goals while holding four shutouts.
"What I'm saying is we want to improve? Yes, we want to. We have to improve? Yes we do. We want to get better? Yes, but it's part of a team, part of the process that a team has to go through during the season," Cudicini said.
"Now that we are already 11 games in, we want to get better, try not to concede silly goals and avoid silly situations. But in soccer, in football that happens, it will happen today, it will happen in two games, it will always happen.
"Of course you want to try to get rid of mistakes or situations where you can control better, but personally I don't think this defense is doing as bad as a lot of people are saying."
The LA Galaxy will take on the Carolina Railhawks in the third round of the U.S. Open Cup.
LA earned a second straight trip Cary, North Carolina after the NASL side defeated the PDL's Carolina Dynamo 3-1 at WakeMed Soccer Park on Tuesday. The Railhawks will host the Galaxy at WakeMed on May 29.
It will be the second straight year that the two teams will face off in U.S. Open Cup after the Railhawks defeated the Galaxy 2-1 in the 2012 edition of the tournament.
CARSON, Calif. – Robbie Keane will join up with his Republic of Ireland a little later than previously anticipated as club commitments with the LA Galaxy will stay with the club through June 2.
Keane had been called by Ireland for their upcoming friendlies against England and Georgia, but since those matches fall outside of the FIFA international window, he will remain with the Galaxy until Ireland's World Cup Qualifier against the Faroe Islands on June 7 and their friendly with Spain on June 11.With the World Cup Qualifier not until June 7, Keane will be available for selection for LA's matches against Seattle Sounders FC on May 26 at The Home Depot Center and New England Revolution at Gillette Stadium on June 2.
The LA Galaxy captain has scored two goals and tallied three assists while appearing in five of LA's 11 regular season games as injuries and international commitments have taken their toll on the Irishman.
"We're following FIFA rules. Robbie is an important member of our team," LA head coach Bruce Arena said on Tuesday. "He's missed half the games in the league. These games are important, we're the ones that pay him and he'll be for the important games for Ireland. We wish that we could let him go for the whole [camp], but that's not the way that it works."
Although Keane will not participate in Ireland's friendlies, Arena attests that there is no hard feelings from the Irish Football Association.
"Ireland is very professional. They understand completely," Arena said. "They understand our issues and we all understand what the FIFA rules are and we're following them."
Cue up "Empire State of Mind" by Jay-Z and Alicia Keys -- or maybe "New York, New York" by Frank Sinatra if you feel so inclined -- because MLS finally has a team in New York City.
On Tuesday, MLS announced the creation of New York City Football Club, which will become the league's 20th franchise. The team will officially join the league during the 2015 season and the deal brings together a partnership between Premier League giant Manchester City, MLS, and baseball's New York Yankees.
Following LA Galaxy training on Tuesday, New York native and LA Galaxy head coach Bruce Arena offered his thoughts on the new franchise.
"I think that it's great. That's where I'm from, that part of New York and it's a great spot for a new franchise," Arena said. "It's an area that supports the sport of soccer.The venues that they've discussed in Queens [Flushing Meadows-Corona Park] is a good one, but if that falls through then I'm sure that there will be some other options. I know that Belmont Park [in Long Island] was a possibility for the [NASL's New York] Cosmos, maybe it can be a possibility for an MLS team. If they get a suitable venue, it's going to be fabulous addition to the league."
The primary question that surrounds NYCFC is just where the team will actually be located. The team will off in 2015 in a temporary location as a permanent home is constructed -- Yankee Stadium is being floated as a potential option -- and may stay there for two to three years. But as NYCFC look for a venue, it certainly doesn't hurt to have the clout of the New York Yankees behind them, a team that is dear to Arena's heart.
"When you get the Yankees behind it, there is not a better organization in sports," said Arena, who attended the Yankees game against the Toronto Blue Jays last Thursday. "The Yankees are the Yankees. There's nothing like the Yankees."
What are your thoughts on the new franchise? Planning a trip to New York City around 2015?
Share your thoughts below.


text:
Don't have an account? Create one now
Sorry, this product is out of stock.
Please note, all size information is provided as a guide - if you're unsure or need any further assistance you can call us on 01792 799508 ... we're happy to help!
Spend more than £250 at Tredz and you can spread the cost. Pay monthly over 6-48 months, interest free
If your employer is already running a scheme, you're just three steps away from receiving your new bike and equipment
We accept cycle to work vouchers from all these providers:
We are committed to offering fast and free delivery, whether you're ordering bikes, accessories or clothing. Our standard delivery service is FREE to mainland UK, regardless of the size and value.
Please note: bulky products and bikes shipped to outlying UK regions are excluded from free shipping - Click here for more info.
Simply return the items to us in their original, resaleable condition, and securely packaged, within 365 days of receipt.
For items under £75 and 10kg, you can use the Collect Plus service by printing your label off online and dropping your package off at a local store.
Step one - Repackage your item and include a returns form
Step two - Buy and print a returns label
Step three - Take your item to your local shop, pay your £4.49 and get a tracking receipt

subset: commoncrawl


text:
BDR User Guide
From PostgreSQL wiki
(→bdr_sequence_alloc, bdr_sequence_options, bdr_sequence_setval) |
(→Distributed Sequences) |
Line 306: | Line 306: | ||
Using distributed sequences allows you to avoid the problems with inserts conflicts. | Using distributed sequences allows you to avoid the problems with inserts conflicts. | ||
− | TODO: | + | '''TODO''': All of the following is subject to change and requires periodic review. |
+ | |||
+ | You can get a listing of distributed sequences defined in a database with: | ||
+ | |||
+ | FROM pg_class | ||
+ | INNER JOIN pg_seqam ON (pg_class.relam = pg_seqam.oid) | ||
+ | WHERE pg_seqam.seqamname = 'bdr' AND relkind = 'S'; | ||
+ | |||
+ | (See <tt>[#pg_seqam|pg_seqam]</tt> for information on the new <tt>pg_seqam</tt> catalog table). | ||
+ | |||
+ | New distributed sequences may be created with the `USING` clause to `CREATE SEQUENCE`: | ||
+ | |||
+ | CREATE SEQUENCE test_seq USING bdr; | ||
+ | |||
+ | Once you've created a distributed sequence you may use it with `nextval` like any other sequence. | ||
+ | |||
+ | A few limitations and caveats apply to global sequences at time of writing: | ||
+ | |||
+ | * Only an <tt>INCREMENT</tt> of 1 (the default) is supported. Client applications that expect a different increment must be configured to handle increment 1. An extended variant of <tt>nextval</tt> that takes the number of values to obtain as an argument and returns a set of values is planned as an extension to aid in porting. | ||
+ | |||
+ | * <tt>MINVALUE</tt> and <tt>MAXVALUE</tt> are locked at their defaults and may not be changed. | ||
+ | |||
+ | * <tt>START WITH</tt> may not be specified; however, <tt>setval</tt> may be used to set the start value after the sequence is created. | ||
+ | |||
+ | * The <tt>CACHE</tt> directive is not supported. | ||
+ | |||
+ | * Sequence values are handed out in chunks, so if three different nodes all call <tt>nextval</tt> at the same time they might get values 50, 150 and 250. Thus, at time 't' <tt>nextval</tt> on one node may return a value higher than a <tt>nextval</tt> call at time 't+1' on another node. Within a single node the usual rules for <tt>nextval</tt> still apply. | ||
+ | |||
+ | The details used by BDR to manage global sequences are in the <tt>bdr_sequence_values</tt>, <tt>bdr_sequence_elections</tt> and <tt>bdr_votes</tt> tables in the <tt>public</tt> schema, though these details are subject to change. | ||
=== Configuration === | === Configuration === |
Revision as of 08:44, 27 May 2013
This page is the users and administrators guide for BDR. If you're looking for technical details on the project plan and implementation, see BDR Project.
BDR User Guide
BDR (BiDrectional Replication) is a feature being developed for inclusion in PostgreSQL core that provides greatly enhanced replication capabilities.
BDR allows users to create a geographically distributed multi-master database using Logical Log Streaming Replication (LLSR) transport. BDR is designed to provide both high availability and geographically distributed disaster recovery capabilities.
BDR is not "clustering" as some vendors use the term, in that it doesn't have a distributed lock manager, global transaction co-ordinator, etc. Each member server is separate yet connected, with design choices that allow separation between nodes that would not be possible with global transaction coordination.
Guidance on getting a testing setup established are in #Initial setup. Please read the full documentation if you intend to put BDR into production.
Logical Log Streaming Replication
Logical log streaming replication (LLSR) allows one PostgreSQL master (the "upstream master") to stream a sequence of changes to another read/write PostgreSQL server (the "downstream master"). Data is sent in one direction only over a normal libpq connection.
Multiple LLSR connections can be used to set up bi-directional replication as discussed later in this guide.
Overview of logical replication
In some ways LLSR is similar to "streaming replication" i.e. physical log streaming replication (PLSR) from a user perspective; both replicate changes from one server to another. However, in LLSR the receiving server is also a full master database that can make changes, unlike the read-only replicas offered by PLSR hot standby. Additionally, LLSR is per-database, whereas PLSR is per-cluster and replicates all databases at once. There are many more differences discussed in the relevant sections of this document.
In LLSR the data that is replicated is change data in a special format that allows the changes to be logically reconstructed on the downstream master. The changes are generated by reading transaction log (WAL) data, making change capture on the upstream master much more efficient than trigger based replication, hence why we call this "logical log replication". Changes are passed from upstream to downstream using the libpq protocol, just as with physical log streaming replication.
One connection is required for each PostgreSQL database that is replicated. If two servers are connected, each of which has 50 databases then it would require 50 connections to send changes in one direction, from upstream to downstream. Each database connection must be specified, so it is possible to filter out unwanted databases simply by avoiding configuring replication for those databases.
Setting up replication for new databases is not (yet?) automatic, so additional configuration steps are required after CREATE DATABASE. A restart of the downstream master is also required. The upstream master only needs restarting if the max_logical_slots parameter is too low to allow a new replica to be added. Adding replication for databases that do not exist yet will cause an ERROR, as will dropping a database that is being replicated. Setup is discussed in more detail below.
Changes are processed by the downstream master using bdr plug-ins. This allows flexible handing of replication input, including:
- BDR apply process - applies logical changes to the downstream master. The apply process makes changes directly rather than generating SQL text and then parse/plan/executing SQL.
- Textual output plugin - a demo plugin that generates SQL text (but doesn't apply changes)
- pg_xlogdump - examines physical WAL records and produces textual debugging output. This server program is included in PostgreSQL 9.3.
Replication of DML changes
All changes are replicated: INSERT, UPDATE, DELETE and TRUNCATE.
(TRUNCATE is not yet implemented, but will be implemented before the feature goes to final release).
Actions that generate WAL data but don't represent logical changes do not result in data transfer, e.g. full page writes, VACUUMs, hint bit setting. LLSR avoids much of the overhead from physical WAL, though it has overheads that mean that it doesn't always use less bandwidth than PLSR.
Locks taken by LOCK and SELECT ... FOR UPDATE/SHARE on the upstream master are not replicated to downstream masters. Locks taken automatically by INSERT, UPDATE, DELETE or TRUNCATE *are* taken on the downstream master and may delay replication apply or concurrent transactions - see Lock Conflicts.
TEMPORARY and UNLOGGED tables are not replicated. In contrast to physical standby servers, downstream masters can use temporary and unlogged tables. However, temporary tables remain specific to a particular session so creating a temporary table on the upstream master does not create a similar table on the downstream master.
DELETE and UPDATE statements that affect multiple rows on upstream master will cause a series of row changes on downstream master. These are likely to go at same speed as on origin, as long as an index is defined on the Primary Key of the table on the downstream master. UPDATEs and DELETEs require some form of unique constraint, either PRIMARY KEY or UNIQUE NOT NULL. A warning is issued in the downstream master's logs if the expected constraint is absent. INSERT on upstream master do not require a unique constraint in order to replicate correctly, though such usage would prevent conflict detection between multiple masters, if that was considered important.
UPDATEs that change the value of the Primary Key of a table will be replicated correctly.
The values applied are the final values from the UPDATE on the upstream master, including any modifications from before-row triggers, rules or functions. Any reflexive conditions, such as N = N+ 1 are resolved to their final value. Volatile or stable functions are evaluated on the master side and the resulting values are replicated. Consequently any function side-effects (writing files, network socket activity, updating internal PostgreSQL variables, etc) will not occur on the replicas as the functions are not run again on the replica.
All columns are replicated on each table. Large column values that would be placed in TOAST tables are replicated without problem, avoiding de-compression and re-compression. If we update a row but do not change a TOASTed column value, then that data is not sent downstream.
All data types are handled, not just the built-in datatypes of PostgreSQL core. The only requirement is that user-defined types are installed identically in both upstream and downstream master (see "Limitations").
The current LLSR plugin implementation uses the binary libpq protocol, so it requires that the upstream and downstream master use same CPU architecture and word-length, i.e. "identical servers", as with physical replication. A textual output option will be added later for passing data between non-identical servers, e.g. laptops or mobile devices communicating with a central server.
Changes are accumulated in memory (spilling to disk where required) and then sent to the downstream server at commit time. Aborted transactions are never sent. Application of changes on downstream master is currently single-threaded, though this process is efficiently implemented. Parallel apply is a possible future feature, especially for changes made while holding AccessExclusiveLock.
Changes are applied to the downstream master in the sequence in which they were commited on the upstream master. This is a known-good serialized ordering of changes, so replication serialization failures are not theoretically possible. Such failures are common in systems that use statement based replication (e.g. MySQL) or trigger based replication (e.g. Slony version 2.0). Users should note that this means the original order of locking of tables is not maintained. Although lock order is provably not an issue for the set of locks held on upstream master, additional locking on downstream side could cause lock waits or deadlocking in some cases. (Discussed in further detail later).
Larger transactions spill to disk on the upstream master once they reach a certain size. Currently, large transactions can cause increased latency. Future enhancement will be to stream changes to downstream master once they fill the upstream memory buffer, though this is likely to be implemented in 9.5.
SET statements and parameter settings are not replicated. This has no effect on replication since we only replicate actual changes, not anything at SQL statement level. We always update the correct tables, whatever the setting of search_path. Values are replicated correctly irrespective of the values of bytea_output, TimeZone, DateStyle, etc.
NOTIFY is not supported across log based replication, either physical or logical. NOTIFY and LISTEN will work fine on the upstream master but an upstream NOTIFY will not trigger a downstream LISTENer.
In some cases, additional deadlocks can occur on apply. This causes an automatic retry of the apply of the replaying transaction and is only an issue if the deadlock recurs repeatedly, delaying replication.
From a performance and concurrency perspective the BDR apply process is similar to a normal backend. Frequent conflicts with locks from other transactions when replaying changes can slow things down and thus increase replication delay, so reducing the frequency of such conflicts can be a good way to speed things up. Any lock held by another transaction on the downstream master - LOCK statements, SELECT ... FOR UPDATE/FOR SHARE, or INSERT/UPDATE/DELETE row locks - can delay replication if the replication apply process needs to change the locked table/row.
Table definitions and DDL replication
DML changes are replicated between tables with matching "Schemaname"."Tablename" on both upstream and downstream masters. e.g. changes from upstream's public.mytable will go to downstream's public.mytable while changes to the upstream mychema.mytable will go to the downstream myschema.mytable. This works even when no schema is specified on the original SQL since we identify the changed table from its internal OIDs in WAL records and then map that to whatever internal identifier is used on the downstream node.
This requires careful synchronization of table definitions on each node otherwise ERRORs will be generated by the replication apply process. In general, tables must be an exact match between upstream and downstream masters.
There are no plans to implement working replication between dissimilar table definitions.
Tables must meet the following requirements to be compatible for purposes of LLSR:
- The downstream master must only have constraints (CHECK, UNIQUE, EXCLUSION, FOREIGN KEY, etc) that are also present on the upstream master. Replication may initially work with mismatched constraints but is likely to fail as soon as the downstream master rejects a row the upstream master accepted.
- The table referenced by a FOREIGN KEY on a downstream master must have all the keys present in the upstream master version of the same table.
- Storage parameters must match except for as allowed below
- Inheritance must be the same
- Dropped columns on master must be present on replicas
- Custom types and enum definitions must match exactly
- Composite types and enums must have the same oids on master and replication target
- Extensions defining types used in replicated tables must be of the same version or fully SQL-level compatible and the oids of the types they define must match.
The following differences are permissible between tables on different nodes:
- The table's pg_class oid, the oid of its associated TOAST table, and the oid of the table's rowtype in pg_type may differ;
- Extra or missing non-UNIQUE indexes
- Extra keys in downstream lookup tables for FOREIGN KEY references that are not present on the upstream master
- The table-level storage parameters for fillfactor and autovacuum
- Triggers and rules may differ (they are not executed by replication apply)
Replication of DDL changes between nodes will be possible using event triggers, but is not yet integrated with LLSR (see LLSR Limitations).
Triggers and Rules are NOT executed by apply on downstream side, equivalent to an enforced setting of session_replication_role = origin.
In future it is expected that composite types and enums with non-identical oids will be converted using text output and input functions. This feature is not yet implemented.
LLSR limitations
The current LLSR implementation is subject to some limitations, which are being progressively removed as work progresses.
Data definition compatibility
Table definitions, types, extensions, etc must be near identical between upstream and downstream masters. See Table definitions and DDL replication.
DDL Replication
DDL replication is not yet supported.
Upstream feedback
No feedback from downstream masters to the upstream master is implemented for asynchronous LLSR, so upstream masters must be configured to keep enough WAL. See Configuration.
TRUNCATE is not replicated
TRUNCATE is not yet supported, however workarounds with user-level triggers are possible and a ProcessUtility hook is planned to implement a similar approach globally.
The safest option is to define a user-level BEFORE trigger on each table that RAISEs an ERROR when TRUNCATE is attempted.
A simple truncate-blocking trigger is:
CREATE OR REPLACE FUNCTION deny_truncate() RETURNS trigger AS $$ BEGIN IF tg_op = 'TRUNCATE' THEN RAISE EXCEPTION 'TRUNCATE is not supported on this table. Please use DELETE FROM.'; ELSE RAISE EXCEPTION 'This trigger only supports TRUNCATE'; END IF; END; $$ LANGUAGE plpgsql;
It can be applied to a table with:
CREATE TRIGGER deny_truncate_on_<tablename> BEFORE TRUNCATE ON <tablename> FOR EACH STATEMENT EXECUTE PROCEDURE deny_truncate();
A PL/PgSQL DO block that queries pg_class and loops over it to EXECUTE a dynamic SQL CREATE TRIGGER command for each table that does not already have the trigger can be used to apply the trigger to all tables.
Initial setup
To set up LLSR or BDR you first need a patched PostgreSQL that can support LLSR/BDR, then you need to create one or more LLSR/BDR senders and one or more LLSR/BDR receivers.
Installing the patched PostgreSQL binaries
Currently BDR is only available in builds of the 'bdr' branch on Andres Freund's git repo on git.postgresql.org. PostgreSQL 9.2 and below do not support BDR, and 9.3 requires patches, so this guide will not work for you if you are trying to use a normal install of PostgreSQL.
First you need to clone, configure, compile and install like normal. Clone the sources from git://git.postgresql.org/git/users/andresfreund/postgres.git and checkout the bdr branch.
If you have an existing local PostgreSQL git tree specify it as --reference /path/to/existing/tree to greatly speed your git clone.
mkdir -p $HOME/bdr cd bdr git clone -b bdr git://git.postgresql.org/git/users/andresfreund/postgres.git $HOME/bdr/postgres-bdr-src cd postgres-bdr-src ./configure --prefix=$HOME/bdr/postgres-bdr-bin make install cd contrib/bdr make install
This will put everything in $HOME/bdr, with the source code and build tree in $HOME/bdr/postgres-bdr-src and the installed PostgreSQL in $HOME/bdr/postgres-bdr-bin. This is a convenient setup for testing and development because it doesn't require you to set up new users, wrangle permissions, run anything as root, etc, but it isn't recommended that you deploy this way in production.
To actually use these new binaries you will need to:
export PATH=$HOME/bdr/postgres-bdr-bin/bin:$PATH
before running initdb, postgres, etc. You don't have to use the psql or libpq you compiled but you're likely to get version mismatch warnings if you don't.
Parameter Reference
The following parameters are new or have been changed in PostgreSQL's new logical streaming replication.
To load support for receiving changes on a downstream master, the bdr library must be added to the existing 'shared_preload_libraries' parameter. This loads the bdr library during postmaster start-up and allows it to create the required background worker(s).
Upstream masters don't need to load the bdr library unless they're also operating as a downstream master as is the case in a BDR configuration.
A comma-separated list of upstream master connection names is specified in bdr.connections. These names must be simple alphanumeric strings. They are used when naming the connection in error messages, configuration options and logs, but are otherwise of no special meaning.
A typical two-upstream-master setting might be:
bdr.connections = 'upstream1, upstream2'
Each connection name must have at least a data source name specified using the bdr.<connection_name>.dsn parameter. The DSN syntax is the same as that used by libpq so it is not discussed in further detail here. A dbname for the database to connect to must be specified; all other parts of the DSN are optional.
The local (downstream) database name is assumed to be the same as the name of the upstream database being connected to, though future versions will make this configurable.
For the above two-master setting for bdr.connections the DSNs might look like:
bdr.upstream1.dsn = 'host=10.1.1.2 user=postgres dbname=replicated_db' bdr.upstream2.dsn = 'host=10.1.1.3 user=postgres dbname=replicated_db'
The new parameter max_logical_slots has been added for use on both upstream and downstream masters. This parameter controls the maximum number of logical replication slots - upstream or downstream - that this cluster may have at a time. It must be set at postmaster start time.
As logical replication slots are persistent, slots are consumed even by replicas that are not currently connected. Slot management is discussed in Starting, Stopping and Managing Replication.
max_logical_slots should be set to the sum of the number of logical replication upstream masters this server will have plus the number of logical replication downstream masters will connect to it it.
wal_level = 'logical'
A new setting, 'logical', has been added for the existing wal_level parameter. 'logical' includes everything that the existing hot_standby setting does and adds additional details required for logical changeset decoding to the write-ahead logs.
This additional information is consumed by the upstream-master-side xlog decoding worker. Downstream masters that do not also act as upstream masters do not require wal_level to be increased above the default 'minimal'.
wal_level, except for the new 'logical' setting, is documented in the main PostgreSQL manual.
Logical replication hasn't altered the max_wal_senders parameter, but it is important in upstream masters for logical replication and BDR because every logical sender consumes a max_wal_senders entry.
You should configure max_wal_senders to the sum of the number of physical and logical replicas you want to allow an upstream master to serve. If you intend to use pg_basebackup you should add at least two more senders to allow for its use.
Like max_logical_slots, max_wal_senders entries don't cost a large amount of memory, so you can overestimate fairly safely.
max_wal_senders is documented in the main PostgreSQL documentation.
Like max_wal_senders, the wal_keep_segments parameter isn't directly changed by logical replication but is still important for upstream masters. It is not required on downstream-only masters.
wal_keep_segments should be set to a value that allows for some downtime or unreachable periods for downstream masters and for heavy bursts of write activity on the upstream master.
Keep in mind that enough disk space must be available for the WAL segments, each of which is 16MB. If you run out of disk space the server will halt until disk space is freed and it may be quite difficult to free space when you can no longer start the server.
If you exceed the required wal_keep_segments and "Insufficient WAL segments retained" error will be reported. See Troubleshooting.
wal_keep_segments is documented in the the main PostgreSQL manual.
Setting this parameter to "on" enables commit timestamp tracking, which is used to implement last-UPDATE-wins conflict resolution.
It is also required for use of the pg_get_transaction_committime function.
Function reference
The LLSR/BDR patches add several functions to the PostgreSQL core.
pg_get_transaction_committime(txid integer): Get the timestamp at which the specified transaction, as identified by transaction ID, committed. This function can be useful when monitoring replication lag.
init_logical_replication(slotname name, plugin name, OUT slotname text, OUT xlog_position text) performs the same work as pg_receivellog --init, creating a new logical replication slot. Given the slot name to create and the plugin to use for the slot, it returns the fully qualified resulting slot name and the start position in the transaction logs.
This function is mostly useful for implementers of replication tools based on logical replication's features, and is not typically directly useful to end users. Starting a downstream master will automatically create a slot so you do not generally need this function when you are using BDR.
stop_logical_replication(slotname name) stops logical replication for the named slot, removing its entry from the upstream master. It has the same effect as pg_receivellog --stop, but is callable from SQL.
This function is mainly useful for removing unused slots.
This function is used by the pg_stat_bdr view. You don't need to call it directly.
bdr_sequence_alloc, bdr_sequence_options, bdr_sequence_setval
These functions are internal to BDR's distributed sequence implementation and are invoked via the sequence access methods. You use ordinary sequence manipulation functions like nextval and setval to manage distributed sequences.
Catalog changes
To support distributed sequences, BDR adds an access method abstraction for sequences. It serves a similar purpose to index access methods - it abstracts the implementation of sequence storage from usage of sequences, so the client doesn't need to care whether it's using a distributed sequence, a local sequence, or something else entirely.
This access method is described by the pg_seqam table. Two entries are defined:
postgres=# select * from pg_seqam ; seqamname | seqamalloc | seqamsetval | seqamoptions -----------+----------------------+-----------------------+------------------------ local | sequence_local_alloc | sequence_local_setval | sequence_local_options bdr | bdr_sequence_alloc | bdr_sequence_setval | bdr_sequence_options (2 rows)
local is the traditional local-only sequence access method.
bdr is for distributed sequences. For more information, see the distributed sequences section.
Distributed Sequences
Distributed sequences, or global sequences, are a sequence that is synchronized across all the nodes in a BDR cohort. A distributed sequence is more expensive to access than a purely local sequence, but it produces values that are guaranteed unique across the entire cohort.
Using distributed sequences allows you to avoid the problems with inserts conflicts.
TODO: All of the following is subject to change and requires periodic review.
You can get a listing of distributed sequences defined in a database with:
SELECT * FROM pg_class INNER JOIN pg_seqam ON (pg_class.relam = pg_seqam.oid) WHERE pg_seqam.seqamname = 'bdr' AND relkind = 'S';
(See [#pg_seqam|pg_seqam] for information on the new pg_seqam catalog table).
New distributed sequences may be created with the `USING` clause to `CREATE SEQUENCE`:
CREATE SEQUENCE test_seq USING bdr;
Once you've created a distributed sequence you may use it with `nextval` like any other sequence.
A few limitations and caveats apply to global sequences at time of writing:
- Only an INCREMENT of 1 (the default) is supported. Client applications that expect a different increment must be configured to handle increment 1. An extended variant of nextval that takes the number of values to obtain as an argument and returns a set of values is planned as an extension to aid in porting.
- MINVALUE and MAXVALUE are locked at their defaults and may not be changed.
- START WITH may not be specified; however, setval may be used to set the start value after the sequence is created.
- The CACHE directive is not supported.
- Sequence values are handed out in chunks, so if three different nodes all call nextval at the same time they might get values 50, 150 and 250. Thus, at time 't' nextval on one node may return a value higher than a nextval call at time 't+1' on another node. Within a single node the usual rules for nextval still apply.
The details used by BDR to manage global sequences are in the bdr_sequence_values, bdr_sequence_elections and bdr_votes tables in the public schema, though these details are subject to change.
Details on individual parameters are described in the parameter reference section.
The following configuration is an example of a simple one-way LLSR replication setup - a single upstream master to a single downstream master.
The upstream master (sender)'s postgresql.conf should contain settings like:
wal_level = 'logical' # Include enough info for logical replication max_logical_slots = X # Number of LLSR senders + any receivers max_wal_senders = Y # Y = max_logical_slots plus any physical # streaming requirements wal_keep_segments = 5000 # Master must retain enough WAL segments to let # replicas catch up. Correct value depends on # rate of writes on master, max replica downtime # allowable. 5000 segments requires 78GB # in pg_xlog track_commit_timestamp = on # Not strictly required for LLSR, only for BDR # conflict resolution.
Downstream (receiver) postgresql.conf:
shared_preload_libraries = 'bdr' bdr.connections="name_of_upstream_master" # list of upstream master nodenames bdr.<nodename>.dsn = 'dbname=postgres' # connection string for connection # from downstream to upstream master bdr.<nodename>.local_dbname = 'xxx' # optional parameter to cover the case # where the databasename on upstream # and downstream master differ. # (Not yet implemented) bdr.<nodename>.apply_delay # optional parameter to delay apply of # transactions, time in milliseconds bdr.synchronous_commit = ...; # optional parameter to set the # synchronous_commit parameter the # apply processes will be using max_logical_slots = X # set to the number of remotes
Note that a server can be both sender and receiver, either two servers to each other or more complex configurations like replication chains/trees.
The upstream (sender) pg_hba.conf must be configured to allow the downstream master to connect for replication. Otherwise you'll see errors like the following on the downstream master:
FATAL: could not connect to the primary server: FATAL: no pg_hba.conf entry for replication connection from host "[local]", user "postgres"
A suitable pg_hba.conf entry for a replication connection from the replica server 10.1.4.8 might be:
host replication postgres 10.1.4.8/32 trust
(the user name should match the user name configured in the downstream master's dsn. md5 password authentication is supported.)
For more details on these parameters, see Parameter Reference.
Could not access file "bdr": No such file or directory
If you see the error:
FATAL: could not access file "bdr": No such file or directory
when starting a database set up to receive BDR replication, you probably forgot to install contrib/bdr. See above.
Invalid value for parameter
An error like:
LOG: invalid value for parameter ...
when setting one of these parameters means your server doesn't support logical replication and will need to be patched or updated.
Insufficient WAL segments retained ("requested WAL segment ... has already been removed")
If wal_keep_segments is insufficient to meet the requirements of a replica that has fallen far behind, the master will report errors like:
ERROR: requested WAL segment 00000001000000010000002D has already been removed
Currently the replica errors look like:
WARNING: Starting logical replication LOG: data stream ended LOG: worker process: master (PID 23812) exited with exit code 0 LOG: starting background worker process "master" LOG: master initialized on master, remote dbname=master port=5434 replication=true fallback_application_name=bdr LOG: local sysid 5873181566046043070, remote: 5873181102189050714 LOG: found valid replication identifier 1 LOG: starting up replication at 1 from 1/2D9CA220
but a more explicit error message for this condition is planned.
The only way to recover from this fault is to re-seed the replica database.
This fault could be prevented with feedback from the replica to the master, but this feature is not planned for the first release of BDR. Another alternative considered for future releases is making wal_keep_segments a dynamic parameter that is sized on demand.
Monitoring of maximum replica lag and appropriate adjustment of wal_keep_segments will prevent this fault from arising.
Couldn't find logical slot
An error like:
ERROR: couldn't find logical slot "bdr: 16384:5873181566046043070-1-24596:"
on the upstream master suggests that a downstream master is trying to connect to a logical replication slot that no longer exists. The slot can not be re-created, so it is necessary to re-seed the downstream replica database.
Operational Issues and Debugging
In LLSR there are no user-level (ie SQL visible) ERRORs that have special meaning. Any ERRORs generated are likely to be serious problems of some kind, apart from apply deadlocks, which are automatically re-tried.
The following views are available for monitoring replication activity:
- pg_stat_replication
- pg_stat_logical_decoding (described below)
- pg_stat_bdr (described below)
The following configuration and logging parameters are useful for monitoring replication:
The new pg_stat_logical_decoding view is specific to logical replication. It is based on the underlying pg_stat_get_logical_replication_slots function and has the following structure:
View "pg_catalog.pg_stat_logical_decoding" Column | Type | Modifiers --------------------------+---------+----------- slot_name | text | plugin | text | database | oid | active | boolean | xmin | xid | last_required_checkpoint | text |
It contains one row for every connection from a downstream master to the server being queried (the upstream master). On a standalone PostgreSQL server or a downstream-only master this view will contain no rows.
- slot_name: An internal name for a given logical replication slot (a connection from a downstream master to this upstream master). This slot name is used by the downstream master to uniquely identify its self and is used with the pg_receivellog command when managing logical replication slots. The slot name is composed of the decoding plugin name, the upstream database oid, the downstream system identifier (from pg_control), the downstream slot number, and the downstream database oid.
- plugin: The logical replication plugin being used to decode WAL archives. You'll generally only see bdr_output here.
- database: The oid of the database being replicated by this slot. You can get the database name by joining on pg_database.oid.
- active: Whether this slot currently has an active connection.
- xmin: The lowest upstream master transaction ID this replication slot can "see", like the xmin of a transaction or prepared transaction. xmin should keep on advancing as replication continues. If xmin stops advancing that's a sign that replication has stalled, possibly leading to the accumulation of bloat in the system catalogs. You can turn this txid into the time it was committed with pg_get_transaction_committime for monitoring purposes.
- last_required_checkpoint: The checkpoint identifying the oldest WAL record required to bring this slot up to date with the upstream master. (This column is likely to be removed in a future version).
The pg_stat_bdr view is supplied by the bdr extension. It provides information on a server's connection(s) to its upstream master(s). It is not present on upstream-only masters.
The primary purpose of this view is to report statistics on the progress of LLSR apply on a per-upstream master connection basis.
View structure:
View "public.pg_stat_bdr" Column | Type | Modifiers --------------------+--------+----------- rep_node_id | oid | riremotesysid | name | riremotedb | oid | rilocaldb | oid | nr_commit | bigint | nr_rollback | bigint | nr_insert | bigint | nr_insert_conflict | bigint | nr_update | bigint | nr_update_conflict | bigint | nr_delete | bigint | nr_delete_conflict | bigint | nr_disconnect | bigint |
- rep_node_id: An internal identifier for the replication slot.
- riremotesysid: The remote database system identifier, as reported by the Database system identifier line of pg_controldata /path/to/datadir
- riremotedb: The remote database OID, ie the oid column of the remote server's pg_catalog.pg_database entry for the replicated database. You can get the database name with select datname from pg_database where oid = 12345 (where '12345' is the riremotedb oid).
- rilocaldb : The local database OID, with the same meaning as riremotedb but with oids from the local system.
The rest of the rows are statistics about this upstream master slot:
- nr_commit: Number of commits applied to date from this master
- nr_rollback: Number of rollbacks performed by this apply process due to recoverable errors (deadlock retries, lost races, etc) or unrecoverable errors like mismatched constraint errors.
- nr_insert: Number of INSERTs performed
- nr_insert_conflict: Number of INSERTs that resulted in conflicts.
- nr_update: Number of UPDATEs performed
- nr_update_conflict: Number of UPDATEs that resulted in conflicts.
- nr_delete: Number of deletes performed
- nr_delete_conflict: Number of deletes that resulted in conflicts.
- nr_disconnect: Number of times this apply process has lost its connection to the upstream master since it was started.
This view does not contain any information about how far behind the upstream master this downstream master is. The upstream master's pg_stat_logical_decoding and pg_stat_replication views must be queried to determine replication lag.
Monitoring replication status and lag
As with any replication setup, it is vital to monitor replication status on all BDR nodes to ensure no node is lagging severely behind the others or is stuck.
In the case of BDR a stuck or crashed node will eventually cause disk space and table bloat problems on other masters so stuck nodes should be detected and removed or repaired in a reasonably timely manner. Exactly how urgent this is depends on the workload of the BDR group.
The pg_stat_logical_decoding view described above may be used to verify that a downstream master is connected to its upstream master by querying it on the upstream side - the active boolean column is t if there's a downstream master connected to this upstream.
The xmin column provides an indication of whether replication is advancing; it should increase as replication progresses. You can turn this into the time the transaction was committed on the master by running pg_get_transaction_committime(xmin) on the upstream master. Since txids are different between upstream and downstream masters, running it on a downstream master with a txid from the upstream master as input would result in an error or and incorrect result.
postgres=# select slot_name, plugin, database, active, xmin, pg_get_transaction_committime(xmin) FROM pg_stat_logical_decoding ; -[ RECORD 1 ]-----------------+---------------------------------------- slot_name | bdr: 12910:5882534759278050995-1-12910: plugin | bdr_output database | 12910 active | f xmin | 1827 pg_get_transaction_committime | 2013-05-27 06:14:36.851423+00
Table and index usage statistics
Statistics on table and index usage are updated normally by the downstream master. This is essential for correct function of auto-vacuum. If there are no local writes on the downstream master and stats have not been reset these two views should show matching results between upstream and downstream:
- pg_stat_user_tables
- pg_statio_user_tables
Since indexes are used to apply changes, the identifying indexes on downstream side may appear more heavily used with workloads that perform UPDATEs and DELETEs than non-identifying indexes are.
The built-in index monitoring views are:
- pg_stat_user_indexes
- pg_statio_user_indexes
All these views are discussed in the PostgreSQL documentation on the statistics views.
Starting, stopping and managing replication
Replication is managed with the postgresql.conf settings described in "Parameter Reference" and "Configuration" above, and using the pg_receivellog utility command.
Starting a new LLSR connection
Logical replication is started automatically when a database is configured as a downstream master in postgresql.conf (see Configuration) and the postmaster is started. No explicit action is required to start replication, but replication will not actually work unless the upstream and downstream databases are identical within the requirements set by LLSR in the |Table definitions and DDL replication section.
pg_dump and pg_restore may be used to set up the new replica's database.
Viewing logical replication slots
Examining the state of logical replication is discussed in Monitoring.
Temporarily stopping an LLSR replica
LLSR replicas can be temporarily stopped by shutting down the downstream master's postmaster.
If the replica is not started back up before the upstream master discards the oldest WAL segment required for the downstream master to resume replay, as identified by the last_required_checkpoint column of pg_catalog.pg_stat_logical_decoding then the replica will not resume replay. The error Insufficient WAL segments retained will be reported in the upstream master's logs. The replica must be re-created for replication to continue.
Removing an LLSR replica permanently
To remove a replication connection permanently, remove its entries from the downstream master's postgresql.conf, restart the downstream master, then use pg_receivellog to remove the replication slot on the upstream master.
It is important to remove the replication slot from the upstream master(s) to prevent xid wrap-around problems and issues with table bloat caused by delayed vacuum.
Cleaning up abandoned replication slots
To remove a replication slot that was used for a now-defunct replica, find its slot name from the pg_stat_logical_decoding view on the upstream master then run:
pg_receivellog -p 5434 -h master-hostname -d dbname \ --slot='bdr: 16384:5873181566046043070-1-16384:' --stop
where the argument to '--slot' is the slot name you found from the view.
You may need to do this if you've created and then deleted several replicas so max_logical_slots has filled up with entries for replicas that no longer exist.
Bi-Directional Replication
Bi-Directional replication is built directly on LLSR by configuring two or more servers as both upstream and downstream masters of each other.
All of the Log Level Streaming Replication documentation applies to BDR and should be read before moving on to reading about and configuring BDR.
Bi-Directional Replication Use Cases
Bi-Directional Replication is designed to allow a very wide range of server connection topologies. The simplest to understand would be two servers each sending their changes to the other, which would be produced by making each server the downstream master of the other and so using two connections for each database.
Logical and physical streaming replication are designed to work side-by-side. This means that a master can be replicating using physical streaming replication to a local standby server, while at the same time replicating logical changes to a remote downstream master. Logical replication works alongside cascading replication also, so a physical standby can feed changes to a downstream master, allowing upstream master sending to physical standby sending to downstream master.
Simple multi-master pair
A simple mulit-master "HA Cluster" with two servers:
- Server "Alpha" - Master
- Server "Bravo" - Master
wal_level = 'logical' max_logical_slots = 3 max_wal_senders = 4 wal_keep_segments = 5000 shared_preload_libraries = 'bdr' bdr.connections="bravo" bdr.bravo.dsn = 'dbname=dbtoreplicate' track_commit_timestamp = on
wal_level = 'logical' max_logical_slots = 3 max_wal_senders = 4 wal_keep_segments = 5000 shared_preload_libraries = 'bdr' bdr.connections="alpha" bdr.alpha.dsn = 'dbname=dbtoreplicate' track_commit_timestamp = on
See Configuration for an explanation of these parameters.
HA and Logical Standby
Downstream masters allow users to create temporary tables, so they can be used as reporting servers.
"HA Cluster":
- Server "Alpha" - Current Master
- Server "Bravo" - Physical Standby - unused, apart from as failover target for Alpha - potentially specified in synchronous_standby_names
- Server "Charlie" - "Logical Standby" - downstream master
Very High Availability Multi-Master
A typical configuration for remote multi-master would then be:
- Site 1
- Server "Alpha" - Master - feeds changes to Bravo using physical streaming with sync replication
- Server "Bravo" - Physical Standby - feeds changes to Charlie using logical streaming
- Site 2
- Server "Charlie" - Master - feeds changes to Delta using physical streaming with sync replication
- Server "Delta" - Physical Standby - feeds changes to Alpha using logical streaming
Bandwidth between Site 1 and Site 2 is minimised
3-remote site simple Multi-Master Plex
BDR supports "all to all" connections, so the latency for any change being applied on other masters is minimised. (Note that early designs of multi-master were arranged for circular replication, which has latency issues with larger numbers of nodes)
- Site 1
- Server "Alpha" - Master - feeds changes to Charlie, Echo using logical streaming
- Site 2
- Server "Charlie" - Master - feeds changes to Alpha, Echo using logical streaming replication
- Site 3
- Server "Echo" - Master - feeds changes to Alpha, Charlie using logical streaming replication
If you wanted to test this configuration locally you could run three PostgreSQL instances on different ports. Such a configuration would look like the following if the port numbers were used as node names for the sake of notational clarity:
Config for node_5440:
port = 5440 bdr.connections='node_5441,node_5442' bdr.node_5441.dsn='port=5441 dbname=postgres' bdr.node_5442.dsn='port=5442 dbname=postgres'
Config for node_5441:
port = 5441 bdr.connections='node_5440,node_5442' bdr.node_5440.dsn='port=5440 dbname=postgres' bdr.node_5442.dsn='port=5442 dbname=postgres'
Config for node_5442:
port = 5442 bdr.connections='node_5440,node_5441' bdr.node_5440.dsn='port=5440 dbname=postgres' bdr.node_5441.dsn='port=5441 dbname=postgres'
In a typical real-world configuration each server would be on the same port on a different host instead.
3-remote site simple Multi-Master Circular Replication
Simpler config uses "circular replication". This is simpler but results in higher latency for changes as the number of nodes increases. It's also less resilient to network disruptions and node faults.
- Site 1
- Server "Alpha" - Master - feeds changes to Charlie using logical streaming replication
- Site 2
- Server "Charlie" - Master - feeds changes to Echo using logical streaming replication
- Site 3
- Server "Echo" - Master - feeds changes to Alpha using logical streaming replication
TODO: Regrettably this doesn't actually work yet because we don't cascade logical changes (yet).
Using node names that match port numbers, for clarity
Config for node_5440:
port = 5440 bdr.connections='node_5441' bdr.node_5441.dsn='port=5441 dbname=postgres'
Config for node_5441:
port = 5441 bdr.connections='node_5442' bdr.node_5442.dsn='port=5442 dbname=postgres'
Config for node_5442:
port = 5442 bdr.connections='node_5440' bdr.node_5440.dsn='port=5440 dbname=postgres'
This would usually be done in the real world with databases on different hosts, all running on the same port.
3-remote site Max Availability Multi-Master Plex
- Site 1
- Server "Alpha" - Master - feeds changes to Bravo using physical streaming with sync replication
- Server "Bravo" - Physical Standby - feeds changes to Charlie, Echo using logical streaming
- Site 2
- Server "Charlie" - Master - feeds changes to Delta using physical streaming with sync replication
- Server "Delta" - Physical Standby - feeds changes to Alpha, Echo using logical streaming
- Site 3
- Server "Echo" - Master - feeds changes to Foxtrot using physical streaming with sync replication
- Server "Foxtrot" - Physical Standby - feeds changes to Alpha, Charlie using logical streaming
Bandwidth and latency between sites is minimised.
Config left as an exercise for the reader.
N-site symmetric cluster replication
Symmetric cluster is where all masters are connected to each other.
N=19 has been tested and works fine.
N masters requires N-1 connections to other masters, so practical limits are <100 servers, or less if you have many separate databases.
The amount of work caused by each change is O(N), so there is a much lower practical limit based upon resource limits. A future option to limit to filter rows/tables for replication becomes essential with larger or more heavily updated databases, which is planned.
Complex/Assymetric Replication
Variety of options are possible.
Conflict Avoidance
Distributed Locking
Some clustering systems use distributed lock mechanisms to prevent concurrent access to data. These can perform reasonably when servers are very close but cannot support geographically distributed applications as very low latency is critical for acceptable performance.
Distributed locking is essentially a pessimistic approach, whereas BDR advocates an optimistic approach: avoid conflicts where possible but allow some types of conflict to occur and and resolve them when they arise.
Global Sequences
Many applications require unique values be assigned to database entries. Some applications use GUIDs generated by external programs, some use database-supplied values. This is important with optimistic conflict resolution schemes because uniqueness violations are "divergent errors" and are not easily resolvable.
The SQL standard requires Sequence objects which provide unique values, though these are isolated to a single node. These can then used to supply default values using DEFAULT nextval('mysequence'), as with PostgreSQL's SERIAL pseudo-type.
BDR requires sequences to work together across multiple nodes. This is implemented as a new SequenceAccessMethod API (SeqAM), which allows plugins that provide get/set functions for sequences. Global Sequences are then implemented as a plugin which implements the SeqAM API and communicates across nodes to allow new ranges of values to be stored for each sequence.
Conflict Detection & Resolution
Because local writes can occur on a master, conflict detection and avoidance is a concern for basic LLSR setups as well as full BDR configurations.
Lock Conflicts
Changes from the upstream master are applied on the downstream master by a single apply process. That process needs to RowExclusiveLock on the changing table and be able to write lock the changing tuple(s). Concurrent activity will prevent those changes from being immediately applied because of lock waits. Use the log_lock_waits facility to look for issues with apply blocking on locks.
By concurrent activity on a row, we include
- explicit row level locking (SELECT ... FOR UPDATE/FOR SHARE)
- locking from foreign keys
- implicit locking because of row UPDATEs, INSERTs or DELETEs, either from local activity or apply from other servers
Data Conflicts
Concurrent updates and deletes may also cause data-level conflicts to occur, which then require conflict resolution. It is important that these conflicts are resolved in a consistent and idempotent manner so that all servers end up with identical results.
Concurrent updates are resolved using last-update-wins strategy using timestamps. Should timestamps be identical, the tie is broken using system identifier from pg_control though this may change in a future release.
UPDATEs and INSERTs may cause uniqueness violation errors because of primary keys, unique indexes and exclusion constraints when changes are applied at remote nodes. These are not easily resolvable and represent severe application errors that cause the database contents of multiple servers to diverge from each other. Hence these are known as "divergent conflicts". Currently, replication stops should a divergent conflict occur. The errors causing the conflict can be seen in the error log of the downstream master with the problem.
Updates which cannot locate a row are presumed to be DELETE/UPDATE conflicts. These are accepted as successful operations but in the case of UPDATE the data in the UPDATE is discarded.
All conflicts are resolved at row level. Concurrent updates that touch completely separate columns can result in "false conflicts", where there is conflict in terms of the data, just in terms of the row update. Such conflicts will result in just one of those changes being made, the other discarded according to last update wins. It is not practical to decide when a row should be merged and when a last-update-wins stragegy should be used at the database level; such decision making would require support for application-specific conflict resolution plugins.
Changing unlogged and logged tables in the same transaction can result in apparently strange outcomes since the unlogged tables aren't replicated.
As an example, lets say we have two tables Activity and Customer. There is a Foreign Key from Activity to Customer, constraining us to only record activity rows that have a matching customer row.
- We update a row on Customer table on NodeA. The change from NodeA is applied to NodeB just as we are inserting an activity on NodeB. The inserted activity causes a FK check....


text:
This is big! Hopefully, dynamic clocking is not something incredibly complex (I have no idea). Irony is, this way Linus will probably end up buying one of NVIDIA cards pretty soon.
Phoronix: Clock-For-Clock, Nouveau Can Compete With NVIDIA's Driver
Similar to last week's testing of comparing the open-source vs. closed-source Radeon Linux driver performance from a stock Ubuntu 12.10 installation, the tables have now been turned to look at NVIDIA hardware on this latest Ubuntu Linux release. Benchmarks were done of the stock Nouveau open-source graphics driver, the official NVIDIA proprietary driver, and the proprietary driver when it was underclocked to match the clock frequencies as used by the reverse-engineered Nouveau driver.
This is big! Hopefully, dynamic clocking is not something incredibly complex (I have no idea). Irony is, this way Linus will probably end up buying one of NVIDIA cards pretty soon.
Last edited by mirza; 11-06-2012 at 02:14 PM.
Wow .. This is impressive!
I hope the results scale up with recloking on nouveau(when it becomes available I mean).
Is it possible to manually reclock the card using nouveau to a higher clock and test both on "max performance" possibly?
AFAIK it don't scale. But it indicates bottelnecks in the code and they might be easy to solve compared to compleate redesigne of the whoe thing.
I really hope they can work their way to reclocking soon. This would give nouveau an incredible speed breath. True that performance may not scale linearly, but it may quite be a good indicator. I'm eager to see benches for more advanced games, like Unigine. IMHO they would be much more representative of commercial games that may see the Linux light now that Steam is coming.
This is awesome! It's great to see the open drivers actually win (sorta) in some tests! Hopefully dynamic-clocking (and the related work/bugs it involves) will really help the open NVidia drivers catch up to the closed ones in terms of performance.
BTW, does anyone know if dynamic-clocking is something that plagues the AMD open drivers as well? If so, it would be awesome to see how the open AMD drivers (with all the new source improvements made: 2D tiling, PCIE 2.0, etc.. turned on) compare against the closed AMD drivers at the same clock. Is it possible? Or is this an NVidia specific issue?
Radeon drivers have some issues with dynamic reclocking, but they can work the card to any clock they want just fine. I think the default switching between medium and high profile automatically depending on load, or is mostly on high(max). So I doubt it can cause performance problems in there.
There's not way to raise the clock when running nouveau? So it can be tested on high performance profile.
I don't own a NVIDIA card, but this is great news .
I guess the dynamic clocking will be handled in the kernel for both Nouveau and Radeon, right?
... and when can dynamic clocking be expected for Nouveau and Radeon?
Currently I set power profiles manually via. a service script and desktop shortcuts, hope that changes soon .
So... what does this tell us about the open radeon driver?


text:
Black Dry Erase Board Beer Tap Handle
Create your own custom handle!
Do you have a custom or seasonal brew you want to identify? Now it's easy to identify and promote the beer on tap. Why not have fun with a custom message...imagine the possibilities!
You can re-use the TapBoard tap handle to promote a seasonal or traditional beer or promote special venues or holidays.
Dry Erase Beer Tap Handles save you time and money...simply erase the message and re-use the TapBoard tap handle again and again - brew today and sell tonight! Our new TapBoard tap handle is great for brewpubs, bar owners or the home brewer that wants the ease of an erasable tap handle. Write any custom message you want on this tap with a neon dry erase marker and erase it with soap and water.
Black Dry Erase Board Beer Tap Handle Reviews
Average Customer Rating: | (0) |
(based on 0 reviews) |
No customer reviews available. Be the first to write a review! |
All charges are based on a quantity of 1.
Click "Add to Cart" above to change quantities and make actual ship method selection. |
Top Sellers
Sale Price: $15.95 | Sale Price: $21.99 | Sale Price: $15.95 | Sale Price: $3.50 |


text:
Cookies are not enabled in your browser.
You must have Cookies enabled for the best experience on our site and to make a purchase.
Learn how to enable Cookies in your browser or call 1-800-426-8020 for assistance.
This image is not Zoomable
Built by our guide team for high-output activities from alpine and rock climbing to trail running and cross training. Ultralight Flexion four-way stretch performance shell of nylon/spandex/polyester offers superior flexibility and breathability, and is wind- and water-resistant. StormRepel® durable water-repellent (DWR) finish beads water so it doesn't soak into the fabric. Streamlined design eliminates bulk while allowing full range of motion.
Active: Our most athletic fit. Close to body without restricting mobility. Designed to fit over baselayers and lightweight midlayers.
Need Help? 1-800-426-8020


text:
You must be signed in to access this part of the community.
Forgot your password?
If you haven't already registered, now is a good time to do so. Once you register, you can post to the community, receive email notifications, and more.You won't need to register if you've already created an account on Linksys.com, simply Sign In.Account Benefits:


text:
Book online or call:
Outside the UK call
Monday to Friday 9am - 5pm
Saturday and Sunday - closed
*calls may be recorded
Email us at firstname.lastname@example.com
Towns & Villages
Boat of Garten
Boat of Garten is a peaceful village set amongst heather clad hills and native woodlands in the heart of the Cairngorms National Park.
Towns & Villages
Located on the doorstep of the Cairngorms National Park, Aviemore is a major holiday resort surrounded by stunning scenery.
Towns & Villages
The small but lively village of Carrbridge is surrounded by spectacular scenery and sits at the northern gateway to the Cairngorms National Park.
Towns & Villages
Grantown on Spey
The small town of Grantown-on-Spey on the edge of the spectacular Cairngorms National Park is a great base for exploring the Strathspey area.
Forests & Woodlands
Aviemore and the Cairngorms
Located at the foot of the Cairngorm Mountains, this magnificent forest park is well-known for its Caledonian pinewoods.
Loch Morlich is a fresh water loch surrounded by sandy beaches and home to a water sports centre and yacht club.
Towns & Villages
Kingussie is the capital of Badenoch in the Highlands. It's a lovely lively town beside the River Spey in the midst of the beautiful Cairngorms National Park.
Towns & Villages
Kincraig and its neighbouring communities of Alvie, Insh and Feshiebridge lie at the heart of the Scottish Highlands within the Cairngorm National Park.
Towns & Villages
Newtonmore is a lovely village nestling in the upper reached of the Spey valley within the Cairngorms National Park.
Towns & Villages
Nestled at a height of 1164 ft on the northern slopes of the Cairngorm Mountains, Tomintoul is the highest village in the Highlands.


text:
Find a Doctor
Massoud G. Dezfuli, DO
- 39700 Bob Hope Dr
- Suite 108
- Rancho Mirage, CA 92270
- (760) 834-3545
- P.O. Box 128
- Rancho Mirage CA 92270
- Google Map
Massoud Dezfuli, DO, MS, Board Certified in Infectious Disease, and is an Osteopathic Infection Disease specialist. Dr. Dezfuli is the Antimicrobial Stewardship Program Director, Infectious Disease preventions Director, and was Section Chief of Infectious Disease at Eisenhower Medical Center from 2002 to 2004.
Dr. Dezfuli served his residency at Los Angeles County Hospital + University of Southern California Medical Center (LAC+USC), where he also completed a fellowship in Infectious Disease. Dr. Dezfuli then practiced Emergency Ambulatory medicine at LAC+USC before working in Primary Care. Since 1998, Dr. Dezfuli has maintained a solo practice, covering Infectious Disease, Internal Medicine and Hospitalist Medicine.
Dr. Dezfuli is a member of Osteopathic Physicians and Surgeons of California, the American Osteopathic Association, the American Academy of General Physicians and the American College of Physicians.
- Professional Details
- Infectious Disease*
- English
- Farsi
- 21
- 17
- Professional Education
- Western University of Health Sciences
- Los Angeles County Univ. of So. Cal Medical Center
- Los Angeles County Univ. of So. Cal Medical Center
- Los Angeles County Univ. of So. Cal Medical Center
- Board Certification
- American Board of Internal Medicine
- American Board of IM/Infectious Diseases
- Publication Date: May 06, 2015
- Back


text:
The countryside of Umbria, where Brunello Cucinelli calls home, was the inspiration for the sublimely luxurious and colorful cashmere that made him famous. Today the company operates from a restored 14th century castle in Solomeo, Italy (in fact, he restored the entire village). The line has expanded beyond the initial coveted cashmere to include designs for men and women.
Brunello Cucinelli Shoes
15 items |
- 30
- 120


text:
I read the title and thought Steam was coming to ARM.
Phoronix: ARM & Steam Continue Exciting Linux Enthusiasts
With November coming to a close, here's some statistics on the most popular content on Phoronix this month...
I read the title and thought Steam was coming to ARM.
Wow, I had no idea you might be taking a step aside. While some people may find your journalistic style somewhat abrasive or sensationalist, I've found your posts usually have a fair degree of personality to enhance and elaborate on the points of the articles you post. You just don't get quite the same perspective anywhere else, and I think it has real value.
Even though I've been reading Phoronix for a few years now, I never really thought seriously about subscribing. But hearing news like that kinda' brings it home how much I've gained from this site's perspective, and how much I've learned.
It really is a sad news...
Michael, may be find a few people who you can trust and let them crete news perhaps? 'Outsource, open source' the page. :P
It really is sad for me.
I heard from a reliable source that Michael is dying of cancer and he's submitted his site to be a proud partner of a Unix promoting company.
R.I.P. Michael.
The email:
Subject: Charity Assistance
Hello Friend.
As you read this, I don't want you to feel sorry for me because i believe everyone will die someday. My name is Michael,
I have been diagnosed with Esophageal cancer . It has defiled all forms of medical treatment, and right now I have only about a few months to live, according to medical experts.I have not particularly lived my life so well, as I never really cared for anyone(not even myself)but my business. Though I am very rich, I was never generous, I was always hostile to people and only focused on my business asthat was the only thing I cared for. But now I regret all this as I now know that there is more to life than just wanting to have or make all the moneyin the world.
I believe when God gives me a second chance to come to this world I would live my life a different way from how I have lived it. Now that God has called me, I have willed and given most of my property and assets to my immediate and extended family members as well as a few close friends.
I want God to be merciful to me and accept my soul so, I have decided to give alms to charity ganizations, as I want this to be one of the last good deeds I do on earth.
Now that my health has deteriorated so badly, I cannot do this myself anymore. I once asked members of my family to close one of my accounts and distribute the money which I have there to charity organization in Bulgaria and Pakistan, they refused and kept the money to themselves. Hence, I do not trust them anymore, as they seem not to be contended with what I have left for them.
The last of my money which no one knows of is the huge cash deposit of twenty million united states dollars that I have with a finance/Security Company abroad. I will want you to help me collect this deposit and dispatched it to charity organizations. I have set aside 10 % for you and for your time. God be with you.
Last edited by mark45; 12-01-2012 at 05:28 AM.
I guess it was a joke. It's pretty much word for word from this scam.
Maybe that's what shows up in your statistics of page hits because they are the only 2 things you wrote about lately?
The link is to SCO's home page, so I'm assuming it's a joke.
I hope that you've found someone who will take over the site's daily publishing operations in the same spirit as you've left it. Your website is one of my most frequent hits on the internet because of the news topics, and succinctness of the reviews/articles. I also wish you luck in your next endeavour. Hopefully we'll still see your face around here.
Phoronix needs better or alternative color design
And at least several own projects or competitions, for the site itself.
The news were very good and phoromatic is genial thing, thanks for what you did and best of luck! Prost!
My sarcasm-o-meter is broken now, you own me a new one! The XL model please!


text:
Special Meeting Annotated AgendaFebruary 9, 2010
Click on the linked agenda item titles below for background materials/reports. Adopted Resolutions and Ordinances (second reading) are available via Records Online (http://www.CityofBerkeley.info/ContentDisplay.aspx?id=4222) as soon as they are finalized.
Resolutions and Ordinances are subject to amendment, rescission or repeal, or readoption in whole or in part. Additional research may be necessary to verify the completeness of the legislative history. To research the Berkeley Municipal Code, visit: http://www.CityofBerkeley.info/BMC
These documents are presented in Adobe Acrobat PDF*, and will open in a new browser window. Some files may exceed 1MB in size. All items are available for review at the City Clerk Department, (510) 981-6900.
*To read PDF files, download a free copy of Adobe Acrobat Reader. If you are unable to access .pdf documents online, please contact us via email (email@example.com), telephone (510) 981-6900, or TDD (510) 981-6903 so that we can provide an alternate format.
District 1 – Linda Maio
District 5 – Laurie Capitelli
District 2 – Darryl Moore
District 6 – Susan Wengraf
District 3 – Max Anderson
District 7 – Kriss Worthington
District 4 – Jesse Arreguin
District 8 – Gordon Wozniak
Preliminary Matters
Roll Call 5:02 p.m.. Councilmember Moore present at 5:06 p.m. Councilmember Anderson present at 5:08 p.m. Councilmember Arreguin present at 5:12 p.m. Councilmember Worthington present at 5:22 p.m.
Public Comment – Items on this agenda only: 6 speakers.
1. FY 2010 Second Quarter Budget Review and Budget Balancing Strategies (PDF)Presentation (PDF)From: City ManagerContact: Tracy Vesely, Budget Manager, 981-7000Action: Presentation made and discussion held.
Adjournment: 6:48 p.m.
CommunicationsCouncil rules limit action on Communications to referral to the City Manager and/or Boards and Commissions for investigation and/or recommendations. All communications submitted to Council are public record. Communications are not published directly to the City's website. Copies of individual communications are available for viewing at the City Clerk Department and through Records Online.


text:
- Model: VH74
- Catalog #: 55031757
RCA VH74 Deluxe A/B Switch
Sold Out Online.
Please note that all prices are subject to change without prior notice. Prices advertised on this site are for online orders only. Prices on some items may differ from those advertised in RadioShack stores. All merchandise may not be available at all stores, and all stores may not participate in all sales promotions. We recommend you contact the store to confirm product availability and price.
Why isn't the price shown here?
Periodically, manufacturers prefer that products be advertised at their suggested retail price. When we choose to sell these items for less than the suggested retail price, we display the sale price in the shopping cart
Online prices and product selection may vary from our retail stores. All prices and offers are subject to change.
Copyright © RadioShack Corporation 2014. All rights reserved.
Additional Information
SWITCHES BETWEEN TV and VCR FCC APPROVED
Ships in 1-2 Business Days
SWITCHES BETWEEN TV and VCR FCC APPROVED
Tech Specs
SWITCHES BETWEEN TV and VCR FCC APPROVED


text:
26 posts
• Page 1 of 2 • 1, 2
Re: Tangehttp://www.bikeforums.net/archive/index.php/t-326429.html
...but I always pronounced it "Tanjee" which I think is wrong according to the thread above, which seems to suggest taan-geh. So we get the leaders we deserve and we elect, we get the companies and the products that we ask for, right? And we have to ask for different things. – Paul Gilding
but really, that's rubbish. We get none of it because the choices are illusory.
Re: Tange
I pronounce it tanj and michy wal. can i join the cool group now?
Re: Tange
I am sure there will be further tests ....
Re: TangeI go between Tahn-geh and Tanj, depends on what I'm vibing at the time.
Re: TangeI always pronounced it tanj cos that's all i had heard but tahn-geh makes sense. And when i first read MICHE i thought "meesh" but then heard my-keh.
My Mercier is Tange, it rides beautifully. That's what i actually thought this thread was going to be about . And from the bikeforums thread "I pronounce it tange" . When man invented the bicycle he reached the peak of his attainments- Elizabeth West.
Re: TangeJust call it molybdenum(Mo) alloy, Tange is actually a brand, same as Reynolds (which is also just a Mo alloy), common name for most Mo alloy's is Chrome Moly (which is not a stainless steel but a 41## series steel), most Mo alloy steels contain between .25 to 8% molybdenum.
Just thought I'd solve any potential arguments as to which was better, Tange (Japanese), Reynolds (British) or Cro-Mo (everywhere else). They are all close enough to being the same, yes there are differing grades, but they rarely use any of the real super duper grade stuff on bikes. http://en.wikipedia.org/wiki/41xx_steel P.S - vaeske, not sure the 'cool' group pronounce it that way. In fact, if I thought it was that way, then it's probably totally 'wrong' & 'un-cool'
Re: Tange
I like Columbus, cos the dove logo is cool. Got a tee, a cycling cap and a panto'd fork because I'm a fashion whore. I love the Vetta to ride, but must confess that a few years back I had a very nice riding frame that was Butted Tange 900. Last edited by BRLVR.v2 on Sun Nov 11, 2012 1:12 pm, edited 1 time in total.
Re: Tange
the cool group is a bit obscure - we probably haven't heard of it.
Re: Tange
Not sure about Tange but I can answer the "Miche" question. It's "mih-Khay" (the first syllable is a short sound, it rhyms with Nih, as in "the knights who say NIH" "mish-ee" would be correct if they were French (like Michelin) but the Miche company is Italian, and in that launguage the "c" is a hard sound when followed by an "h" - just as Bianchi is prounounced "be-Ank-he" not "bee-ann-chee"
Re: Tange
Cheers man
Re: TangeWhen I was speaking with people from Tange, I was saying Tange with the ge as in lounge - they didn't say anything, but may thought I was Eurocool.
For Miche I say misch-e (short e). Help me Raise $5000 in my Adelaide to Darwin charity ride: TourXOz Details and Fundraising
26 posts
• Page 1 of 2 • 1, 2
Who is onlineUsers browsing this forum: Baidu [Spider], barefoot, Bing [Bot], fatherofmany, morini |
Popular Bike Shops
> FREE BNA Stickers |